Doubt on WebSphere Classloader mode and policy

[Rr Kumaran]

Hi All,

I am using WSAD 5.1.2 and WebSphere 5.0 Test Environment. I am deploying a ear file with below structure :


a.ear
-|-------- b.war (web module)
-|-------- c.jar (ejb module)
-|-------- d.jar, e.jar (utilitiy jars)

I am using d.jar, e.jar in b.war. Now if I set below settings in my websphere 5.0 test environment then d.jar, e.jar are not recognized and hence I get classnotfound exception

a.ear Classloader mode: PARENT_FIRST
a.ear WAR classloader policy: APPLICATION
b.war Classloader mode : PARENT_LAST


But if I keept d.jar and e.jar in b.war\WEB-INF\lib then above settings I can successfully run the application but I dont want to follow this approach.

So what is the ideal settings in this scenario to deploy this a.ear successfully ?




Thanks & Regards,

[JeanLouis Marechaux]

The default settings should be :
a.ear Classloader mode: PARENT_FIRST
a.ear WAR classloader policy: MODULE
b.war Classloader mode : PARENT_FIRST

According to me you should only change these settings if you are facing some problems with the application server, because this is the default J2EE classloading mode.

Now, could you explain what kind of problem you have with your d.jar and e.jar.
You are talking about a classnotfound exception. Can you elaborate a bit.
Which module of your application is trying to load the class when the exception arises ??
Have you double checked the java JAR dependencies (manifest) related to this module ?
[ February 10, 2005: Message edited by: Jean-Louis Marechaux ]

[Rr Kumaran]

Thank you Jean-

Thank you for the prompt response. Can you please explain on what exactly does EAR Classloader mode PARENT_FIRST, PARENT_LAST mean and WAR classloader policy APPLICATION, MODULE mean.

You mean to say that I can still use d.jar and e.jar with below settings :

a.ear Classloader mode: PARENT_FIRST
a.ear WAR classloader policy: MODULE
b.war Classloader mode : PARENT_FIRST



Let me try this again .... I'll get back to you if needed

[JeanLouis Marechaux]

PARENT_FIRST / PARENT_LAST are related to classloader delegation mode.
As you should know, there's some hierarchy in the classloaders (inheritance)


To simplify :

WAR Classloader -----> Application Classloader(ejb, dependencies)----> Bootstrap classloader

where ------> means *inherits*


PARENT_FIRST means when you try to instanciate a class, this class will be searched in the PARENT classloader first (delegation), and loaded from the PARENT classloader if it can be found here.

PARENT_LASt means...the opposite

MODULE vs APPLICATION
Module : each web app (war) has its own class loader whose parent is thge application Classloader (EJB, dependencies...)
Application : the web app is loaded in the application classloader. It does not have its own classloader

You should consider looking upfor *classloader* in the WebSphere infocenter. You'll find better and clearer explanations about classloader policies


Now let's talk aboutr your problem.
Yes, I do believe you should be able to get your application working with the default classloader settings.

The only way to help you is to fully understand your problem. Please let me know which class you are trying to load and from where when the exception arise

[Rr Kumaran]

So what is the advantage of setting "ear WAR classloader policy to MODULE" even when "war Classloader mode is set to PARENT_FIRST or PARENT_LAST" ?

[JeanLouis Marechaux]

Originally posted by R Kumar:
So what is the advantage of setting "ear WAR classloader policy to MODULE" even when "war Classloader mode is set to PARENT_FIRST or PARENT_LAST" ?

The WAR will have it's owns class loader(WCL), but it will inherits the Application classloader(ACL). (remember WCL----> ACL).
With PARENT_FIRST, each time you load a new class from the web application, WebSphere tries to find it from the parent classloader first (ACL) before trying to load it from the local classloader (WCL)

MODULE does not mean the WCL is independant from other classloaders. It means the web app has its class loader (WCL)with an inheritance relationship with the application class loader (ACL) : WCL ----> ACL

[Rr Kumaran]

Jean- Your response speed is impressive. That clears.

Basically, I am deploying AXIS 1.2 RC2 as web module(say b.war) inside WSAD 5.1.2. All required axis and jibx jars are placed under WEB-INF\classes\lib.

I dont know why below settings do not work

a.ear Classloader mode: PARENT_FIRST
a.ear WAR classloader policy: MODULE
b.war Classloader mode : PARENT_FIRST

and I keep to getting exception in websphere 5.0 saying that it is unable to load and instantiate axis servlet but if I do below settings then axis works fine and I can see the list of all deployed axis web services.

a.ear Classloader mode: PARENT_FIRST
a.ear WAR classloader policy: APPLICATION
b.war Classloader mode : PARENT_LAST

[JeanLouis Marechaux]

Originally posted by R Kumar:

a.ear Classloader mode: PARENT_FIRST
a.ear WAR classloader policy: MODULE
b.war Classloader mode : PARENT_FIRST

With this settings, Websphere should :
1- looks up for Axis classes in the parent classloader first (EJB + JAR dependencied)
2- If it does find them in the parent classloader, then looks up in WEB-INF/classes and WEB-INF/lib

So if axis.jar is located in WEB-INF/lib, I don't see why it could fail to find it. What is the exact exception ? can you post it ?
Besides, are you sure axis.jar is not elsewhere in your application ?

[Rr Kumaran]

a.ear
-|-------- b.war (web module)
-|-------- c.jar (ejb module)
-|-------- d.jar, e.jar (utilitiy jars)

say I removed d.jar and e.jar utility jars at ear level and kept them under b.war\WEB-INF\lib and b.war\WEB-INF\lib finally has below set of jars :

axis-ant.jar, axis.jar, bcel.jar, commons-discovery.jar, commons-logging.jar, jaxrpc.jar, jibx-bind.jar, jibx-extras.jar, jibx-run.jar, log4j-1.2.8.jar, saaj.jar, wsdl4j.jar, xerces.jar, xercesImpl.jar, xml-apis.jar, xpp3-later.jar, xpp3.jar

Now with below settings

a.ear Classloader mode: PARENT_FIRST
a.ear WAR classloader policy: MODULE
b.war Classloader mode : PARENT_FIRST

I am getting below error :

[2/9/05 10:32:22:528 IST] 4f7efc70 WebGroup E SRVE0020E: [Servlet Error]-[AdminServlet]: Failed to load servlet: java.lang.ExceptionInInitializerError: org.apache.commons.discovery.DiscoveryException: Class com.ibm.ws.commons.logging.TrLogFactory does not implement org.apache.commons.logging.LogFactory
at org.apache.commons.discovery.tools.ClassUtils.verifyAncestory(ClassUtils.java:134)
at org.apache.commons.discovery.tools.SPInterface.verifyAncestory(SPInterface.java:155)
at org.apache.commons.discovery.tools.SPInterface.newInstance(SPInterface.java:149)
at org.apache.commons.discovery.tools.DiscoverClass.newInstance(DiscoverClass.java:533)
at org.apache.commons.discovery.tools.DiscoverSingleton.find(DiscoverSingleton.java:372)
at org.apache.commons.discovery.tools.DiscoverSingleton.find(DiscoverSingleton.java:332)
at org.apache.axis.components.logger.LogFactory$1.run(LogFactory.java:45)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.axis.components.logger.LogFactory.getLogFactory(LogFactory.java:41)
at org.apache.axis.components.logger.LogFactory.<clinit>(LogFactory.java:33)
at org.apache.axis.transport.http.AxisServlet.<clinit>(AxisServlet.java:70)
at java.lang.Class.forName1(Native Method)
at java.lang.Class.forName(Class.java(Compiled Code))
at org.apache.axis.transport.http.AxisServletBase.class$(AxisServletBase.java:57)
at org.apache.axis.transport.http.AxisServletBase.<clinit>(AxisServletBase.java:56)
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:262)
at java.beans.Beans.instantiate(Beans.java:233)
at java.beans.Beans.instantiate(Beans.java:77)
at com.ibm.ws.webcontainer.webapp.WebAppServletManager.loadServlet(WebAppServletManager.java:188)
at com.ibm.ws.webcontainer.webapp.WebAppServletManager.loadAutoLoadServlets(WebAppServletManager.java:542)
at com.ibm.ws.webcontainer.webapp.WebApp.loadServletManager(WebApp.java:1270)
at com.ibm.ws.webcontainer.webapp.WebApp.init(WebApp.java:277)
at com.ibm.ws.webcontainer.srt.WebGroup.loadWebApp(WebGroup.java:396)
at com.ibm.ws.webcontainer.srt.WebGroup.init(WebGroup.java:216)
at com.ibm.ws.webcontainer.WebContainer.addWebApplication(WebContainer.java:984)
at com.ibm.ws.runtime.component.WebContainerImpl.install(WebContainerImpl.java:136)
at com.ibm.ws.runtime.component.WebContainerImpl.start(WebContainerImpl.java:356)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:415)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:787)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:351)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:575)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:268)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:246)
at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:543)
at com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:418)
at com.ibm.ws.runtime.component.ApplicationServerImpl.start(ApplicationServerImpl.java:117)
at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:543)
at com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:418)
at com.ibm.ws.runtime.component.ServerImpl.start(ServerImpl.java:183)
at com.ibm.ws.runtime.WsServer.start(WsServer.java:128)
at com.ibm.ws.runtime.WsServer.main(WsServer.java:225)
at java.lang.reflect.Method.invoke(Native Method)
at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:94)
at com.ibm.etools.websphere.tools.runner.api.ServerRunnerV5$1.run(ServerRunnerV5.java:97)

[JeanLouis Marechaux]

Interesting......

Well, according to the exception, it sounds like:
- Axis classes are loaded properly
- Discovery classes are loaded properly, which is normal 'cause both are in the \lib

But the discovery classes generates an exception related to commons-logging..... never seen that before.
Which version of commons-discovery.jar are you using ??

[Jayadev Pulaparty]

Originally posted by Jean-Louis Marechaux:

MODULE does not mean the WCL is independant from other classloaders. It means the web app has its class loader (WCL)with an inheritance relationship with the application class loader (ACL) : WCL ----> ACL

Jean. This is a very interesting thread. I'm enjoying it.

Quick question from my side. What is the relevance of MODULE WCL when the delegation mode is PARENT_FIRST?? The only thing that i can see is that it is used to load the module-specific classes "only if it can't find them in the parent classloader hierarchy". I guess its all about the scope and visibility of the respective classes.

Please clarify.

[JeanLouis Marechaux]

Originally posted by Jayadev Pulaparty:


Jean. This is a very interesting thread. I'm enjoying it.

Quick question from my side. What is the relevance of MODULE WCL when the delegation mode is PARENT_FIRST?? The only thing that i can see is that it is used to load the module-specific classes "only if it can't find them in the parent classloader hierarchy". I guess its all about the scope and visibility of the respective classes.

Please clarify.

Yes, you're right, but in addition, the MODULE setting provide isolation between Web Applications. If your EAR file contains several Web App (WARs), you probably won't be satisfied if they share the same WCL. With the MODULE setting, each web App has its own classloader isolated from others.

I wonder if someday my real complet first name (Jean-Louis, with an hyphen ) will be used in the JR. Maybe I'll try to suppress the hyphen...

:roll:

[Jayadev Pulaparty]

Jean-Louis:

On a similar note, which classloader is responsible for loading the shared libraries??

Thanks.

[JeanLouis Marechaux]

Originally posted by Jayadev Pulaparty:
Jean-Louis:

On a similar note, which classloader is responsible for loading the shared libraries??

Thanks.

If you are talking about the jar files in the EAR, the answer is the Application classloader (the same that for EJBs)

btw, thanks for my firstname

[Jayadev Pulaparty]

I was talking about the shared libraries that you can provide thru websphere admin console (under environment). We provide them at three possible scopes, cell, node and server.

[JeanLouis Marechaux]

Originally posted by Jayadev Pulaparty:
I was talking about the shared libraries that you can provide thru websphere admin console (under environment). We provide them at three possible scopes, cell, node and server.

Ok, sorry for my misunderstanding....
The shared libraries.... well, it depends.
If they are associated to a specific application, then the Application Class Loader (ACL)is responsible for loading them.
If they are at the Node or Server sevel, a specific ClassLoader (parent of the ACL) will load them


I would discourage the use of shared libraries when possible as I believe it is not J2EE compliant, thus not portable. Nevertheless, it could be an appropriate solution sometimes

[Jayadev Pulaparty]

Thank you.

[Rr Kumaran]

JeanLouis-

I am using axis-1_2RC2-bin\axis-1_2RC2\lib\commons-discovery.jar and axis-1_2RC2-bin\axis-1_2RC2\lib\commons-logging.jar

[JeanLouis Marechaux]

I don't understand the problem.

The exception :
java.lang.ExceptionInInitializerError: org.apache.commons.discovery.DiscoveryException: Class com.ibm.ws.commons.logging.TrLogFactory does not implement org.apache.commons.logging.LogFactory
at org.apache.commons.discovery.tools.ClassUtils.verifyAncestory(ClassUtils.java:134)


Actually TrLogFactory extends org.apache.commons.logging.LogFactory
So it should work.
Why discovery is complaining about that ??


... still trying to find out....
[ February 10, 2005: Message edited by: Jean-Louis Marechaux ]

[Jayadev Pulaparty]

Originally posted by Jean-Louis Marechaux:

The exception :
java.lang.ExceptionInInitializerError: org.apache.commons.discovery.DiscoveryException: Class com.ibm.ws.commons.logging.TrLogFactory does not implement org.apache.commons.logging.LogFactory
at org.apache.commons.discovery.tools.ClassUtils.verifyAncestory(ClassUtils.java:134)


Actually TrLogFactory extends org.apache.commons.logging.LogFactory
So it should work.
Why discovery is complaining about that ??

[ February 10, 2005: Message edited by: Jean-Louis Marechaux ]

Is it possible that there is a version incompatibility (w.r.t the functionality delivered) in the jars. May be LogFactory class has changed in a new version and TrLogFactory (relatively older version) is still not an updated version w.r.t the parent class changes.

Thanks.

[JeanLouis Marechaux]

From commons-discovery :

  
 public static void verifyAncestory(Class spi, Class impl)
        throws DiscoveryException
    {
        if (spi == null) {
            throw new DiscoveryException("No interface defined!");
        }
 
        if (impl == null) {
            throw new DiscoveryException("No implementation defined for " + spi.getName());
        }
 
        if (!spi.isAssignableFrom(impl)) {
            throw new DiscoveryException("Class " + impl.getName() +
                                         " does not implement " + spi.getName());
        }
    }

I can't figure out how it could trigger an exception.
R Kumar, have you tried your code on a real websphere (I mean not a WTE ??)
Besides, can you also try it with WTE 5.1 instead of 5.0 ??


Kyle, Roland ?? are your around there ?? any idea ??
[ February 10, 2005: Message edited by: Jean-Louis Marechaux ]

[Jayadev Pulaparty]

Originally posted by Jayadev Pulaparty:


Is it possible that there is a version incompatibility (w.r.t the functionality delivered) in the jars. May be LogFactory class has changed in a new version and TrLogFactory (relatively older version) is still not an updated version w.r.t the parent class changes.

Jean-Louis:

Can we rule out the above-quoted possibility??

[JeanLouis Marechaux]

I don't know Jayadev. Frankly, I don't know.

Of course, R Kumar's problem could be due to some version incompatibility, but it can also be due to a combination of other factors (config, settings) it will be difficult to pinpoint here

I someone have any idea, feel free to contribute !
[ February 10, 2005: Message edited by: Jean-Louis Marechaux ]

[Rr Kumaran]

Guys-

I am impressed by your sincere help. Let me try again from scratch to reproduce the same problem ...

[manoj pillai]

Kumar,
Try removing the xerces jars from your WAR and use the ones from WAS lib instead. I have run into similar issues in the past with WAS and xerces. One little thing - Setting WAR classloader policy with Application visibility doesnt seem to make sense as there is no WAR specific class loader in this case - EAR class loader policy would be applied for all module within the application.

[Rr Kumaran]

>>Try removing the xerces jars from your WAR and use the ones from WAS lib >>instead. I have run into similar issues in the past with WAS and xerces.

you mean set add ws.ext.dirs classpath for D:\Program Files\IBM\WebSphere Studio\Application Developer\v5.1.2\runtimes\base_v5\lib\xerces.jar ??




>>One little thing - Setting WAR classloader policy with Application >>visibility doesnt seem to make sense as there is no WAR specific class >>loader in this case - EAR class loader policy would be applied for all >>module within the application.

do you mean the below settings makes sense ?
a.ear Classloader mode: PARENT_FIRST
a.ear WAR classloader policy: APPLICATION
b.war Classloader mode : PARENT_LAST

[manoj pillai]

Yep. Try the xerces from ws.ext dirs. In WSAD you could do it by setting project properties->Java Build Path -> Libraries tab -> Add Variable -> XERCES and XERCESJAR

> a.ear WAR classloader policy: APPLICATION
> b.war Classloader mode : PARENT_LAST

what I meant is setting WAR classloader mode with Application classloader policy will not have any effect as the WAR module will be using the Application Classloader and its classloader mode.
[ February 14, 2005: Message edited by: manoj pillai ]

[samuel li]

I got almost an identical problem as RR Kumar got there. The differences are:
I used WAS portal server 5.1.1 instead of a test environment. I failed to recreate the problem in my test enironment (Rational 6.0, Websphere portal 5.0 test server). BTW, I don't have xerces.jar in my war or ear file. The errow message is identical.
Still struggling to fix it

[samuel li]

I believe following article will surely solve this problem:
http://www-1.ibm.com/support/docview.wss?uid=swg27004610

[samuel li]

Yes. I got it resolved.
I created a file commons-loggging.properties in java source folder, and I put an entry there as following:

org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl

It worked.
There are actually many ways to resolve this issue (see the link I put it in my previous email). This is not the best way. You can have your own way to make it work.

[Cameron McKenzie]

Classloaders just kill me. Cocoon, Struts, Ant....every technology I use seems to want something different from them.

If you're using WebSphere, and want a good description of how the WebSphere Classloaders work, you can check out the letsgetloaded link on my website.

www.technicalfacilitation.com

Here's a better one:

Understanding and Configuring WebSphere Classloaders: What is WebSphere?

-Cameron McKenzie

[ July 03, 2007: Message edited by: Cameron McKenzie ]
[ July 03, 2007: Message edited by: Cameron McKenzie ]

[Peter Reinhardt]

According to me you should only change these settings if you are facing some problems with the application server, because this is the default J2EE classloading mode.

I always had the impression that PARENT_LAST was the class loading mode recommended by the J2EE spec (at least for war files, i.e. WEB-INF/lib). Anybody an idea where it states in the spec what the default mode should be?


Peter

[Rr Kumaran]

Cameron McKenzie - the url you have provided is broken. Is the url working ?

[Rr Kumaran]

a.ear
-|-------- axis.war (web module)
-|-------- c.jar (ejb module)

say I have below set of jars under axis.war\WEB-INF\lib:

axis-ant.jar, axis.jar, bcel.jar, commons-discovery.jar, commons-logging.jar, jaxrpc.jar, jibx-bind.jar, jibx-extras.jar, jibx-run.jar, log4j-1.2.8.jar, saaj.jar, wsdl4j.jar, xerces.jar, xercesImpl.jar, xml-apis.jar, xpp3-later.jar, xpp3.jar

Now with below settings

a.ear Classloader mode: PARENT_FIRST
a.ear WAR classloader policy: APPLICATION
b.war Classloader mode : PARENT_FIRST or PARENT_LAST

I am successfully able to run AXIS 1.2 RC2 Web Module inside a EAR deployed on WSAD 5.1.2's WebSphere 5.0 Test Environment. Actually I faced a JiBX classloading issue if I keep any other settings other than above. I am not even sure why the above setting works for me. Can anyone please clarify ...