I'm using several jars in my portlets, for instance c3p0. Now I want to avoid to put the jars in every of my portlets lib folders. How can I share one jar file within multiple portlets? And how should I integrate them in the Eclipse IDE? Add an external jar or put them in one dedicated project and include them from there?
Another solution would be to put them under ../liferay-portal-<version>/tomcat-<version>/webapps/ROOT/WEB-INF/lib
If you place them here you can add the JAR as a dependency for your portlet in the portlets liferay-plugin-package.properties (if you're using Liferay Developer Studio or Liferay IDE then there's a nice GUI for this).
Then on deployment Liferay will copy the required JARS from ROOT/WEB-INF/lib to your portlets WEB-INF/lib
This I believe is the Liferay support mechanism for doing it, and doesn't require a restart because the JARs are copied to the portlets classpath on deployment.
One way I can think off is to put all of them in the global path.
For e.g. in Tomcat you could place them at ../liferay-portal-<version>/tomcat-<version>/lib/ext and then when you configure the server-runtime library in eclipse you will have these jars in your build-path.
This link may also help you decide, but it speaks for *-service.jar but I am not sure it would work other jars in any one portlet.
Related
How should I add JAR libraries to a WAR project in Eclipse without facing java.lang.ClassNotFoundException or java.lang.NoClassDefFoundError?
The CLASSPATH environment variable does not seem to work. In some cases we add JAR files to the Build Path property of Eclipse project to make the code compile. We sometimes need to put JAR files inside /WEB-INF/lib folder of the Java EE web application to make the code to run on classes inside that JAR.
I do not exactly understand why CLASSPATH does not work and in which cases we should add JARs to Build Path and when exactly those JARs should be placed in /WEB-INF/lib.
The CLASSPATH environment variable is only used by the java.exe command and even then only when the command is invoked without any of the -cp, -classpath, -jar arguments. The CLASSPATH environment variable is ignored by IDEs like Eclipse, Netbeans and IDEA. See also java.lang.ClassNotFoundException in spite of using CLASSPATH environment variable.
The Build Path is only for libraries which are required to get the project's code to compile. Manually placing JAR in /WEB-INF/lib, or setting the Deployment Assembly, or letting an external build system like Maven place the <dependency> as JAR in /WEB-INF/lib of produced WAR during the build, is only for libraries which are required to get the code to deploy and run on the target environment too. Do note that you're not supposed to create subfolders in /WEB-INF/lib. The JARs have to be placed in the root.
Some libraries are already provided by the target JEE server or servletcontainer, such as JSP, Servlet, EL, etc. So you do not need put JARs of those libraries in /WEB-INF/lib. Moreover, it would only cause classloading trouble. It's sufficient to (indirectly) specify them in Build Path only. In Eclipse, you normally do that by setting the Targeted Runtime accordingly. It will automatically end up in Build Path. You do not need to manually add them to Build Path. See also How do I import the javax.servlet / jakarta.servlet API in my Eclipse project?
Other libraries, usually 3rd party ones like Apache Commons, JDBC drivers and JEE libraries which are not provided by the target servletcontainer (e.g. Tomcat doesn't support many JEE libraries out the box such as JSF, JSTL, CDI, JPA, EJB, etc), need to end up in /WEB-INF/lib. You can just copy and paste the physical JAR files in there. You do not necessarily need to specify it in Build Path. Only perhaps when you already have it as User Library, but you should then use Deployment assembly setting for this instead. See also ClassNotFoundException when using User Libraries in Eclipse build path.
In case you're using Maven, then you need to make absolutely sure that you mark libraries as <scope>provided</scope> if those are already provided by the target runtime, such as JEE, Servlet, EL, etc in case you deploy to WildFly, TomEE, etc. This way they won't end up in /WEB-INF/lib of produced WAR (and potentially cause conflicts with server-bundled libraries), but they will end up in Eclipse's Build Path (and get the project's code to compile). See also How to properly install and configure JSF libraries via Maven?
Those JARs in the build path are referenced for the build (compile) process only. If you export your Web Application they are not included in the final WAR (give it a try).
If you need the JARs at runtime you must place them in WEB-INF/lib or the server classpath. Placing your JARs in the server classpath does only make sense if several WARs share a common code base and have the need to access shared objects (e.g. a Singleton).
If you are using Maven:
Open the project properties, and under Deployment Assembly click Add...
Then select Java Build Path Entries and select Maven Dependencies
Resolved by setting permissions.
Had related issue using PySpark and Oracle jdbc. The error does not state that the file cannot be accessed, just that the class cannot be loaded.
So if anyone still struggles, check the permissions. Some might find it obvious tho'.
I want to give the answer for the folowing link question ClassNotFoundException oracle.jdbc.driver.OracleDriver only in servlet, using Eclipse
Ans: In Myeclipse go to Server-->left click on Myeclipse Tomcat7-->Configure Server Connector-->(Expand)Myeclipse Tomcat7--> Paths-->Prepend to classpath-->Add jar (add oracle14 jar)-->ok
We are planning to build an application which has multiple modules
(say [Common which contains Admin, Registration], License Module,
Stock Module ). We have planned to use Maven as our build tool
Each module acts like a separate folder(war) where in it has MVC layers in it. Main POM should encapsulate all the modules and form a war file.
If a customer doesn't need License Module, i can just unplug the settings and recreate a war file without much effort.
Now i am struggling to find proper example to build a hierarchy(project structure like above)
Could you please guide me on this ?
You can create a parent project then add the child projects as modules. You can easily comment or delete these modules before building the project.
Here is a basic example.
http://www.concretepage.com/build-tools/maven/parent-pom-child-pom-example
You can get a good idea about parent child maven projects from the following thread as well.
Maven: adding a reference to a parent pom project
I am trying to create a fat jar for a multi module java project following the dropwizard documentation that makes use of the maven shade plugin.
https://dropwizard.github.io/dropwizard/getting-started.html#building-fat-jars
In order to do this I created another aggregator project which is just another pom.xml and configured the plugin in this pom.xml
Is there a way I can add my classpath in this configuration? What am I missing?
For all those interested. I fixed the issue by forcing Guava version 12 that the application gets from dropwizard.
I need some utility classes that will be common for three different Liferay portlets so I will develop them in one project that should be shared for my portlets.
I am using Eclipse with Liferay IDE plugin and my question is what kind of project is that one that I need?
I mean is it a simple Java project or any kind of Liferay project?
There are ways you can do this:
Create a simple Java project. Package it as a JAR file. Put the JAR file in global class-path In case of tomcat the global class-path would be ../tomcat-7.0.27/lib/ext/.
Create a simple Java project. Package it as a JAR file. Put the JAR file in the classpath of each and every portlet.
Create a Liferay plugin-portlet using service-builder, put the utility classes in the service package so that the utility classes go in the [name-of-your-project]-service.jar. And then in the portletswhich would need these classes specify the propertyrequired-deployment-contexts=[name-of-your-project]inliferay-plugin-package.properties` of each of the portlet.
Create a Liferay plugin-portlet using service-builder, put the utility classes in the service package so that the utility classes go in the [name-of-your-project]-service.jar and then put the [name-of-your-project]-service.jar in the global class-path and remove it from the WEB-INF/lib of your portlet project so that it does not conflict.
Conclusion
Use 1st-method if the code in utility classes does not depend in anyway on the Liferay API. But this would require a server restart everytime there is a change in the utility classes. Also the Utility classes could be used by Hooks since it is in the global classpath
Use 2nd-method if the code in utility classes does not depend in anyway on the Liferay API. This would not require server restart. But any change in the utility classes would require you to build & deploy all the plugin-portlets which use this jar.
3rd-method: This has the same limitations or features as the 2nd-method, just that you can use Liferay API & your custom service API in the utility classes.
4th-method: This has the same limitations or features as the 1st-method, just that you can use Liferay API & your custom service API in the utility classes.
So here I have listed pros & cons for you to decide for yourself. I would love to know if there are more ways (& much cleaner) to do this in liferay from experts.
So i received a java api from a client and the main code is in main.jar. But the instructions he gave me require me to add these other jars (a.jar, b.jar, etc..) into the classpath whenever I want to use main.jar. These other supporting jars are things like Xerces, jakarta-oro, and a few other publicly available libraries. The problem is i don't know what versions they are, so i'm not sure if there would be issues if i just update the pom.xml file in my app to depend on main.jar and also have dependencies to these other jars as well with the latest versions of them.
Whats the best strategy for using main.jar in my maven application? I'm planning on adding main.jar to our internal maven repository, but what should i do about the xerces, jakarta-oro, and other jars when i dont know what versions they are?
Thanks
If you are lucky the file /META-INF/MANIFEST.MF inside a.jar, b.jar etc. contains an entry "Implementation-Version" or some other useful information which tell you what version they are. If not, you can download the latest release(s) from the project web site and check if they have the same file size as your bundled dependencies.
You may also come to the idea to bundle the dependencies with the main.jar in one big jar, but this may become funny, when you have the dependencies twice in your classpath at some point in the future...
What about just asking the client what version numbers this dependencies have?
If you don't have any information about these third-party libraries, just add them to src/resources/META-INF/lib and commit to SVN. That's the best way, if we're talking about black box approach.