SourceForge.net
2005-04-14 14:32:13 UTC
Feature Requests item #1183082, was opened at 2005-04-14 09:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1183082&group_id=54559
Category: enhancement
Group: None
Status: Open
Priority: 5
Submitted By: Skidyid (skidyid)
Assigned to: Jim Alateras (jalateras)
Summary: Weblogic conflict
Initial Comment:
I encountered a problem with Weblogic Server 8.1. and
OpenJMS, since they both use antlr, and WLS has
native antlr classes in weblogic.jar. This is a problem
with classLoading. The antlr code that is used by
OpenJMS.jar (in my EAR, loaded by the EJB level
classloader), is found on the systemClasspath, and the
class antlr.ASTFactory does a Class.forName
(<OpenJMS class name>) in one of its methods.
Class.forName uses the classLoader of the current file
(ASTFactory loaded by the system classLoader) and all
classLoader's above that to try to find OpenJMS.jar
classes. Obviously they cannot be found since they are
in a lower classLoader. I tried then putting antlr.jar.
OpenJMS.jar, and Castor.jar into the jre/lib/ext
directory. But this brought up more dependencies.
Solution to OpenJMS/Antlr problem:
What we had to do was create a class in the OpenJMS
package called:
org.exolab.jms.selector.parser.ASTFactory that extends
the antlr.ASTFactory. We copied the 4 methods that
were doing Class.forName calls into our OpenJMS
version of the class. This would cause those methods
to use the ClassLoader that loaded the OpenJMS verion
of ASTFactory and not the ClassLoader that loaded the
Antlr version. Then we changed the class
org.exolab.jms.selector.parser.SelectorParser to not
import the antlr version but instead use the OpenJMS
version.
I have attached ASTFactory. SelectorParser is the
other class that would need to be changed.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1183082&group_id=54559
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1183082&group_id=54559
Category: enhancement
Group: None
Status: Open
Priority: 5
Submitted By: Skidyid (skidyid)
Assigned to: Jim Alateras (jalateras)
Summary: Weblogic conflict
Initial Comment:
I encountered a problem with Weblogic Server 8.1. and
OpenJMS, since they both use antlr, and WLS has
native antlr classes in weblogic.jar. This is a problem
with classLoading. The antlr code that is used by
OpenJMS.jar (in my EAR, loaded by the EJB level
classloader), is found on the systemClasspath, and the
class antlr.ASTFactory does a Class.forName
(<OpenJMS class name>) in one of its methods.
Class.forName uses the classLoader of the current file
(ASTFactory loaded by the system classLoader) and all
classLoader's above that to try to find OpenJMS.jar
classes. Obviously they cannot be found since they are
in a lower classLoader. I tried then putting antlr.jar.
OpenJMS.jar, and Castor.jar into the jre/lib/ext
directory. But this brought up more dependencies.
Solution to OpenJMS/Antlr problem:
What we had to do was create a class in the OpenJMS
package called:
org.exolab.jms.selector.parser.ASTFactory that extends
the antlr.ASTFactory. We copied the 4 methods that
were doing Class.forName calls into our OpenJMS
version of the class. This would cause those methods
to use the ClassLoader that loaded the OpenJMS verion
of ASTFactory and not the ClassLoader that loaded the
Antlr version. Then we changed the class
org.exolab.jms.selector.parser.SelectorParser to not
import the antlr version but instead use the OpenJMS
version.
I have attached ASTFactory. SelectorParser is the
other class that would need to be changed.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1183082&group_id=54559