https://issues.apache.org/bugzilla/show_bug.cgi?id=48847
Summary: Classloaders hierarchy messed up when working with
wlfullclient.jar
Product: Tomcat 6
Version: 6.0.13
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: michal.bunarow...@comarch.com
Project set-up:
- Tomcat 6.0.13 + Weblogic 10.0
- wlfullclient.jar is placed in <TOMCAT_HOME>\lib.
- two web apps are deployed on Tomcat (WebApp1 & WebApp2). The wep apps don't
share any libraries except wlfullclient.jar.
- both web apps are subscribed to weblogic JMS topic.
Bug scenario:
1. a message is generated in the weblogic JMS topic
2. both web apps retrieve the message
3. logic that handles the message in WepApp2 operates on a certain class that
belongs to WebApp2 (let's call the class "XXX" for convenience). Namely, the
logic contains casting:
Object xxxObject = someJndiLookup();
XXX someVariable = (XXX) xxxObject;
4. Casting results in ClassCastException. Debugging shows that xxxObject is an
object of the XXX class and its loaded by WebLogic GenericClassLoader. And the
object is cast to the XXX class loaded by WebApp2ClassLoader.
Reason:
At the application startup, WebLogic GenericClassLoader (that is provided
within wlfullclient.jar) is loaded and it sets WepApp1ClassLoader as its parent
(!).
XXX class is a part of WepApp2 and obviously is loaded by WepApp2ClassLoader.
When Weblogic JMS message comes up, GenericClassLoader has to deal with an
object of the XXX class. According to the Tomcat classloaders delegation model
GenericClassLoader first asks its parent whether the parent knows XXX.
But - surprise! - the parent of GenericClassLoader is WepApp1ClassLoader.
Obviously WepApp1ClassLoader does not know this class, since it belongs to
WebApp2. That's why GenericClassLoader decides to load the class itself.
As a result there are multiple copies of the same class.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
