This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Websphere and the fly likes Doubt on WebSphere Classloader mode and policy Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Products » Websphere
Bookmark "Doubt on WebSphere Classloader mode and policy" Watch "Doubt on WebSphere Classloader mode and policy" New topic
Author

Doubt on WebSphere Classloader mode and policy

Rr Kumaran
Ranch Hand

Joined: Sep 17, 2001
Posts: 548
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,


RR Kumaran
SCJP 1.4
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
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 ]

/ JeanLouis<br /><i>"software development has been, is, and will remain fundamentally hard" (Grady Booch)</i><br /> <br />Take a look at <a href="http://www.epfwiki.net/wikis/openup/" target="_blank" rel="nofollow">Agile OpenUP</a> in the Eclipse community
Rr Kumaran
Ranch Hand

Joined: Sep 17, 2001
Posts: 548
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
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
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
Ranch Hand

Joined: Sep 17, 2001
Posts: 548
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
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
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
Ranch Hand

Joined: Sep 17, 2001
Posts: 548
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
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
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
Ranch Hand

Joined: Sep 17, 2001
Posts: 548
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
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
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
Ranch Hand

Joined: Mar 25, 2002
Posts: 662
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
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
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
Ranch Hand

Joined: Mar 25, 2002
Posts: 662
Jean-Louis:

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

Thanks.
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
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
Ranch Hand

Joined: Mar 25, 2002
Posts: 662
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
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
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
Ranch Hand

Joined: Mar 25, 2002
Posts: 662
Thank you.
Rr Kumaran
Ranch Hand

Joined: Sep 17, 2001
Posts: 548
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
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
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
Ranch Hand

Joined: Mar 25, 2002
Posts: 662
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
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
From commons-discovery :



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
Ranch Hand

Joined: Mar 25, 2002
Posts: 662
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
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
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
Ranch Hand

Joined: Sep 17, 2001
Posts: 548
Guys-

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

Joined: Sep 16, 2002
Posts: 41
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.


SCJP,SCJD,SCEA,SCMAD,SCDJWS,SCJP5.0
Rr Kumaran
Ranch Hand

Joined: Sep 17, 2001
Posts: 548
>>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
Ranch Hand

Joined: Sep 16, 2002
Posts: 41
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
Greenhorn

Joined: Feb 23, 2005
Posts: 3
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
Greenhorn

Joined: Feb 23, 2005
Posts: 3
I believe following article will surely solve this problem:
http://www-1.ibm.com/support/docview.wss?uid=swg27004610
samuel li
Greenhorn

Joined: Feb 23, 2005
Posts: 3
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
Greenhorn

Joined: Feb 24, 2005
Posts: 12
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 ]

Where is Springfield? <a href="http://www.pickeringisspringfield.com" target="_blank" rel="nofollow">http://www.pickeringisspringfield.com</a><br /> <br />Portlet Tutorials & Java Certification mock exams: <a href="http://www.scja.com" target="_blank" rel="nofollow">http://www.scja.com</a><br /> <br />WebSphere Stuff: <a href="http://www.pulpjava.com" target="_blank" rel="nofollow">http://www.pulpjava.com</a>
Peter Reinhardt
Ranch Hand

Joined: Aug 02, 2002
Posts: 57

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


SCJP 1.2, SCJD, SCEA, IBM 484, Weblogic 7
Rr Kumaran
Ranch Hand

Joined: Sep 17, 2001
Posts: 548
Cameron McKenzie - the url you have provided is broken. Is the url working ?
Rr Kumaran
Ranch Hand

Joined: Sep 17, 2001
Posts: 548
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 ...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Doubt on WebSphere Classloader mode and policy
 
Similar Threads
WebSphere Classloader Constraints with XERCES
AXIS - Xerces Classloading Problems with WebSphere
WebSphere - AXIS 1.2 RC2 classloading settings
How this classloading settings work ?
Configuration problem in EAR file