My goal is pretty simple: to use ant to build an EAR which contains 1 EJB and 1 jar containing all of the dependencies. This jar, called common.jar for the sake of example has vendor jar files in it as well as other xml files that the EJB depends on and will need to be able to see during runtime....
So far I have everything packaged correctly as an EAR like this:
EARFILE.ear
-EJBFILE.jar
/META-INF
-MANIFEST.MF
-common.jar
/META-INF
-MANIFEST.MF
/lib
-(all vendor jars inside here)
-(All the xml config files are inside the root of the common.jar)
Inside the MANIFEST.MF for the EJBFILE.jar is...
Class-path: ../../common.jar
Inside the MANIFEST.MF for the common.jar is...
Class-path: ../lib/some_common.jar
When I deploy this the appserver (websphere) cannot find the JAR file when I try to start the server. I am getting the ClassDefNotFoundError because the classes inside the EJB cant find the vendor JAR files when I try to start the instance. However I know that common.jar is setup correctly though, else the EJB wouldn't have compiled since it needed to have those vendor jars on the classpath for javac.
So what I want to know is this:
How can I get the runtime to correctly see the Vendor jar files.
Will the EJB be able to see the xml files at run-time? I am concerned about this because these xml files are located outside of the EJB inside of a jar that is just in the EAR, it isn't even a module its just a jar inside the EAR.
Does it even matter when using websphere? From what I gather some containers don't even care what is in the Class-path of MANIFEST.MF.
There are several improvements I can suggest, based on running into similar problems.
First and most importantly, use the appxml attribute of the Ant ear task to specify your deployment descriptor (usually named application.xml); also include references to the vendor JAR files bundled as defined below
I would recommend you not put your vendor JAR files into another JAR - instead, just copy them into the EAR at the same level as EJBFILE.jar
The configuration XML files can go in a sub-directory of the EJBFILE.jar (such as config), and then you can reference them as /config/filename.xml.
The application.xml file will tell WebSphere where to find your JAR files. Classpath traversal in an application server is not the same as that of a compiler, which JBoss has taught me the hard way.
I am using all of the above patterns, and my in-container code (deployed in the EAR) can see all my XML files, as well as find all my dependencies.
Related
I am trying to add some dependencies jar files. But these files when put in lib/endorsed or in WEB_INF/lib.jar results in startup error for jboss instances. I suppose this is happening because flat classloader structure of JBoss. If somebody has implemented the classloader settings in jboss-web.xml
<class-loading>
<loader-repository>com.example:archive=unique-archive-name</loader-repository>
</class-loading>
Can somebody give me a real life example ?
Also where should I place these jar files - lib/endorsed of jboss, or lib folder in deploy folder or in WEB_INF/lib
Duffymo's directive on not putting jars in endorsed is ignored at your peril.
In some additional detail:
Placing libraries in your WEB-INF/lib is a best practice for portability and consistency as it adheres to a standard provision for creating self-sufficient and distributable web archives, but you need to pay close attention to the class-loading declaration you're putting in your jboss-web.xml.
Assume a simple scenario without the class-loading declaration and a fictional example.jar:
If you place example.jar in WEB-INF/lib and it does not also exist in jboss//lib, then example.jar will only be visible to that specific WAR.
If you place example.jar in WEB-INF/lib and it does also exist in jboss//lib, the instance in WEB-INF/lib will essentially be ignored and the WAR will use the JBoss server instance's unified class loader to load the example classes from jboss//lib/example.jar. (The same would apply to any other WARs or EARs in the same server instance, assuming no class-loading overrides.)
The class-loading declaration is necessary in cases (such as) where you have two different versions of example.jar:
- jboss//lib: example1.0.jar
- WEB-INF/lib: example2.0.jar
In this case, JBoss will create a unique and isolated classloader for your WAR which will avoid jboss//lib/example1.0.jar in favour of WEB-INF/lib/example2.0.jar in the context of your WAR.
In summary, if you're only running one WAR in the jboss server instance and/or you have no conflicting JAR issues, ditch the class-loading declaration and put your JARs in jboss//lib. It makes the WAR file more lightweight, overall deployment may be simpler and you will not consume additional memory with extra class versions during hot-deploys.
They belong in the WEB-INF/lib directory of your WAR file. Don't put things in the endorsed folder.
I am majorly confused about where the classpath is. I understand when we create a spring mvc, resources folder, or inside web-inf is considered classpath. And we can use "classpath:" inside xml files to declare the folder. However, where is this classpath exactly? How is it set ? I have been reading about it for a long time, i still couldnt manage to get a real clear image in my head how the classpath is initially determined etc.
For example when we create a war file, and deploy it on a tomcat server, all the resource files can still be read via given paths with "classpath:" in the xml files. How does this work?
Thanks.
Ok, if it's web application, the classpath begins in WEB-INF/classes. Also, jar files in WEB-INF/lib are also on the classpath.
The Classpath is where the JVM will look for class files and other resources. Since you are using Spring MVC, I assume you are deploying a Web application (ie WAR file). This means that the classpath is set by the container which is following the Servlet spec.
The classpath for a WAR file includes the WEB-INF/classes and WEB-INF/lib folders. The Java EE/Servlet container where the WAR file is deployed will also include other common folders in the classpath.
Here is how Tomcat works.
You might also want to try this StackOverflow article/answer
I have a requirement where i need to pack all the common classes of various web services and make them as dependencies(To avoid duplicates for multiple services). The structure of my EAR file is as follows:
META-INF/MANIFEST.MF
META-INF/application.xml
commons-codec-1.2.jar
MyWebService1.war
MyWebService2.war
MyWebService1.jar
MyWebService2.jar
EJB_Bean.jar
Now i have included the dependency jar's under WAR file's Manifest as follows(Not sure if appropriate),
`
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.9.4
Created-By: 1.7.0_51-b13 (Oracle Corporation)
Class-Path: MyWebService1.jar
In the stated structure when i try to deploy the EAR file onto web-logic server, i get java.lang.NoClassDefFoundError, But whereas if i move the dependency jars under WEB-INF/lib folder of my WAR and repack my EAR file, Deployment goes fine as expected.
Is there any way i can include my WAR file dependency libraries outside WAR file or even outside my EAR file is my question. Any help or suggestion would be appreciated.
A simple way to set the libraries of an EAR package is to create a lib folder right under the the EAR root and put your libraries inside.
In this case you will have something like this in your EAR:
META-INF/MANIFEST.MF
META-INF/application.xml
MyWebService1.war
MyWebService2.war
lib/commons-codec-1.2.jar
lib/MyWebService1.jar
lib/MyWebService2.jar
EJB_Bean.jar
In tomcat jar files can be placed inside the lib directory and these jar files gets available to all the applications deployed on that server. In web-logic there must be the similar way to do it. A lib folder from where the web-logic server loads all the jar files.
My first advice would be to use some kind of dependency management such as Maven, Gradle or Ivy - doing that by yourself is very difficult and error prone.
A simpler solution in your case would be to take your "common jars" (especially if they are shared between multiple applications), and add them to the shared library of your webserver. As an example, Tomcat will load all librairies that are placed under tomcat-dir/common/lib directory.
I am using maven build tool.
The following two are my intentions.
1) To move some of the third party library jars out of my war from WEB-INF/lib folder [note: These jars are common between more than 2 war files (or artifacts)]
2) To make the war file small in size.
Is it possible to move those jars out of war and put it into a folder and these jars should be referred in the classpath only by the wars which require it.
I have tried adding the path to the jars in the Class-Path: of MANIFEST.MF of war files but it did not work out. Please help me out.
I assume the jars in question are necessary for compiling the code that make up the web application. If the third-party jars are necessary for compilation but you don't want them in your war file, you have two options:
In the <dependency></dependency> section for the third-party jar, add "<scope>provided</scope>".
Configure the maven war plugin to exclude the jars you don't want in the war. See http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html for the details.
How you get the jar files that you exclude from the war into the web container's classpath depends on your environment. If you are using ear files, the Maven docs above talk about how to get the jars included in the ear file. If you are not using ear files, you will have to come up with your own way to get the jars into the container's lib directory.
I am trying to add some dependencies jar files. But these files when put in lib/endorsed or in WEB_INF/lib.jar results in startup error for jboss instances. I suppose this is happening because flat classloader structure of JBoss. If somebody has implemented the classloader settings in jboss-web.xml
<class-loading>
<loader-repository>com.example:archive=unique-archive-name</loader-repository>
</class-loading>
Can somebody give me a real life example ?
Also where should I place these jar files - lib/endorsed of jboss, or lib folder in deploy folder or in WEB_INF/lib
Duffymo's directive on not putting jars in endorsed is ignored at your peril.
In some additional detail:
Placing libraries in your WEB-INF/lib is a best practice for portability and consistency as it adheres to a standard provision for creating self-sufficient and distributable web archives, but you need to pay close attention to the class-loading declaration you're putting in your jboss-web.xml.
Assume a simple scenario without the class-loading declaration and a fictional example.jar:
If you place example.jar in WEB-INF/lib and it does not also exist in jboss//lib, then example.jar will only be visible to that specific WAR.
If you place example.jar in WEB-INF/lib and it does also exist in jboss//lib, the instance in WEB-INF/lib will essentially be ignored and the WAR will use the JBoss server instance's unified class loader to load the example classes from jboss//lib/example.jar. (The same would apply to any other WARs or EARs in the same server instance, assuming no class-loading overrides.)
The class-loading declaration is necessary in cases (such as) where you have two different versions of example.jar:
- jboss//lib: example1.0.jar
- WEB-INF/lib: example2.0.jar
In this case, JBoss will create a unique and isolated classloader for your WAR which will avoid jboss//lib/example1.0.jar in favour of WEB-INF/lib/example2.0.jar in the context of your WAR.
In summary, if you're only running one WAR in the jboss server instance and/or you have no conflicting JAR issues, ditch the class-loading declaration and put your JARs in jboss//lib. It makes the WAR file more lightweight, overall deployment may be simpler and you will not consume additional memory with extra class versions during hot-deploys.
They belong in the WEB-INF/lib directory of your WAR file. Don't put things in the endorsed folder.