I wanted to understand parent-last loading in an application JBoss application server. We have a legacy application deployed in JBoss 4.2.1 GA. For which we are trying the parent-last loading.
I am referring to the this link.
I wanted to learn a parent last loading. So had created simple maven jar package application with maven-jar-plugin and configuration -> addDefaultImplementationEntries = true. I have created 2 jar versions 1.0.0 and 1.0.1 from the same jar creation maven application. The jar has single class TestClass and a simple String return method that returns the version of the jar the class is loaded from.
what I wanted to experience the use of java2ClassLoadingCompliance. I have packaged the version 1.0.0 jar in the server/deploy/MyApplication/WEB-INF/lib (My web application is a simple servlet application that calls the method of the class thus printing the version number from which jar it was called from.) and version 1.0.1 jar in server/lib.
Note : Logically it does not make sense to use an older version of jar in application and overriding it with the newer version present in server lib, but just wanted to experience the class loading.
I have tried the following
Without any jboss-web.xml in the meta-inf folder.
I tried introduction jboss-we.xml in META-INF and doing the same with java2ClassLoadingCompliance = false.
With java2ClassLoadingCompliance = true.
All the time class from the application lib would get loaded by the application.
My jboss-web.xml looks like reference
<jboss-web>
<class-loading java2ClassLoadingCompliance="true">
<loader-repository>
com.example:archive=JBossClassLoadingTestServlet-0.0.1-SNAPSHOT.ear
<loader-repository-config>java2ParentDelegation=true</loader-repository-config>
</loader-repository>
</class-loading>
</jboss-web>
Can someone help me understanding parent-last configuration in JBoss? What is the mistake I am doing here that always class from application lib gets loaded?
I am afraid that your link is not so related to your experiment. It is more related about the EAR deployments, in which there exists multi-module deployments and need multiple versions of the lib to isolate.
In your case, you just override lib in one Jar.
The following is from Servlet Spec:
It is recommended also that the application class loader is implemented so
that classes and resources packaged within the WAR are loaded in preference to
classes and resources residing in container-wide library JARs.
So, JBoss follow the spec and it always loads application lib first.
I didn't find such old version doc, but it should similar as AS7:
In order of highest priority to lowest priority
System Dependencies - These are dependencies that are added to the module automatically by the container, including the Java EE APIs.
User Dependencies - These are dependencies that are added through JBoss-deployment-structure.xml or through the Dependencies: manifest entry.
Local Resource - Class files packaged up inside the deployment itself, e.g. class files from WEB-INF/classes or WEB-INF/lib of a war.
Inter-deployment dependencies - These are dependencies on other deployments in an ear deployment. This can include classes in an ear's lib directory, or classes defined in other EJB jars.
Related:
a similar jetty classloading problem
Related
I have an EAR file with 3 WARs and some common dependencies within lib/ folder. One of those dependencies has an EJB with a scheduled method, but it seems that the server is not recognizing it. No evidence in log, no code executed.
But when I deploy a simple war with the same jar within WEB-INF/lib, it works. I've already tried to package the jar as an ejb-jar with the maven plugin, but no success at all.
Any ideas on what must be going on?
Jars in the lib directory of an EAR are not considered to be EJB jars and their content is not considered at deployment time in that respect. The lib directory only exists to make it easier to provide library jars whose classes are automatically made visible to all the modules in an EAR file.
Your EAR file contains a META-INF/application.xml file that lists out the various modules that it contains. Prior to Java EE 6, only ejb-modules were considered for potential EJBs. Java EE 6 and newer added web-modules to that list. All jars within a web-module's WEB-INF/lib directory are considered to be part of the web-module, even if they contain ejb-jars. Any ejb-jar.xml files found within a web-module are merged together. This applies even if the web-module is deployed as a standalone WAR file.
I'm trying to deploy WAR file into JBoss 7.
I placed the WAR file in the standalone/deployments folder.
while starting the server I’m getting ClassNotFoundError.
I believe Since the jars are not part of the WAR file and not placed in the WEB_INF/lib folder so I need to add them externally.
I read so many tutorials but I just can’t understand how it works.
So my question is how I simply add JAR files to the JBoss classpath.
If you want to add any jars that are not part of WebApp but are still needed to be loaded, one approach would trying to copy the jars at following location:
$JAVA_HOME/jre/lib/ext.
The JBOSS server should point to this java installation and this might resolve your issue.
This might be one way.
JBOSS 7 uses module based loading, hence most of the jars will be loaded if module is included in standalone.xml.
You will need to check in JBoss Release notes if third party modules can be loaded.
Ok I solved it by creating new module and by adding the module dependency in the MANIFEST of my jar.
I have a Spring webapp running in Glassfish 3.1.2. I am just beginning to convert the webapp to OSGi. I undeployed the existing webapp and copied the spring and gemini OSGi jars into the modules directory in the Glassfish installation. I then installed and activated them using the Glassfish OSGi web console (which I understand to be some sort of customised Felix web console) and everything was fine. It didn't do anything but I could install and activate them in the web console which is what I wanted to test.
I then started to redeploy the non-OSGi jars of my existing webapp using the Glassfish Application console to see if the 2 type of jars could coexist, which, given my understanding of OSGi I thought they should be able to. At this point NoClassDefFoundErrors started getting thrown complaining about not being able to find org.apache.commons.logging amongst other classes. These class were present in both the Module directory as the installed OSGi jars and the application classpath. I then deactivated the jars in the console but didn't remove the the OSGi jars but the exceptions continued to be thrown.
I got a classloader print out and found that the jars in the WEB-INF of my webapp weren't getting loaded but I wasn't sure whether this was the problem or a symptom.
I then removed the jars from the uninstalled the OSGi jars and everything started working again and the webapp could be deployed.
Can anyone think of any reason why this might happen? I am guessing that the content of the module directory is on the classpath but if so why? How would I prevent this from causing problems if I want OSGi and non-OSGi jars to work together?
Side Notes
When I viewed the classes getting loaded by the classloader I couldn't see content form the modules folder getting loaded.
I can install and activate the OSGi jars after the the non-OSGi jars are deployed but not the other way round.
( Disclaimer: I do not have specific experience with glassfish, but JBoss and other
strange environments sporting classloader hierarchies)
You have to be carefull with classloader hierarchies in java - the same bytecode equal class will not be equal or asignable to if comes from another classloader, and while loading classes it is important to find dependencies through loading classloader or his parents.
To resolve your situation you will have to carefully examine this hierarchy and check settings for delegation and class resolution ( like parent first / self first ).
JBoss tried to solve this problem by introducing unified classloader which resulted in one big pile of assorted classes and leaks of resources between contexts / webapps in default setting.
I've got the following scenario:
On the one hand, I've got a tomcat instance with a lot of applications that need the activemq-all.jar which contains slf4j libraries, so I've deployed it into the lib directory, it is not optional for me to include this jar file on each app.
On the other hand I need to install a monitor application which I can't control and ships with a different version of slf4j.
Running the last application on another tomcat instance is also not an option.
I would like to configure tomcat's ClassLoader to try and load first the jars on the webapps and then the jars on the lib/ directory.
Is this possible? How can be achieved?
By Default tomcat loads the web app classes first and gives them a higher preference than classes in its own lib directory. You can keep the mentioned jar is the lb folder. Typically i would recommend the catalina_base directory
Load the common jars under the Common class loader. By default, the common class loader looks for jars under:
$CATALINA_BASE/lib
$CATALINA_HOME/lib
Any jars packaged with you web app should take precedence over those found in the Common class loader.
I am using eclipse and added tomcat 6 server. whenever i try to start the server it automatically copies the server api jar into the WEBINF/lib folder and the app does not start
INFO: validateJarFile(/media/01CB9CAC704E03A0/Projects/.metadata/.plugins/org.eclipse.wst.server.core/tmp1/wtpwebapps/myapp/WEB-INF/lib/servlet-api-2.5.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class
I got the same problem and finally got it to work after looking at this among other pages. I am going to list it here in case other people run into the same issue.
In my case, the myeclipse project was created from a maven .pom file which lists the JEE 1.5 files as "provided" scope i.e. these files will be provided by the container (in my case tomcat 6). So if I create a war file using maven and drop it in the webapps dir it just works fine. It gets a little tedious doing that every time you make a change, so I decided to go for exploded deployment and thats when I ran into the same issue.
Since the project file was created from the pom file, these dependencies came in but Eclipse project file does not recognise these as "provided" and not to be deployed. And TOMCAT is not happy when it finds two implementations of the spec:
"Servlet spec 2.3 sec 9.7.2 recommends … The classloader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal J2SE semantics using getResource. It must not allow the WAR to override J2SE or Java servlet API classes. It is further recommended that the loader not allow servlets in the WAR access to the web container’s implementation classes. It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs."
I toyed with the above solution to change my deplyment assembly config but that is not helpful alone since these jars get bundled in if I select the "JARS from the build path"
in the menu project properties/MyEclipse/Web/Deplyment/Configure workspace settings.
And I need to do that cos I have other dependencies jars (not provided by container).
Solution:
I removed these jars from the dependencies in the build path manually.
Instead I added a dependency on User Library - JAVA EE5.
And in the deployment configuration I removed the option of JARS exported from User Libraries of required projects.
YMMV. But in any case if you read the servlet spec definition above and then look at the config in your workspace, you can sort it out.
Hope this helps.
Go to your project properties and look under Deployment Assembly page. This page describes how your app will be packaged for deployment or export. Take a look at entries regarding libraries. You have to figure out which of those entries points to the servlet api jar and remove it. If the entry points to other jars that do need to be packaged, you will need to split it into several separate build path entries, so you can tell Eclipse exactly what does and does not need to be packaged.