SourceForge.net
2005-11-12 13:48:41 UTC
Feature Requests item #1183082, was opened at 2005-04-15 00:32
Message generated for change (Comment added) made by tanderson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1183082&group_id=54559
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: enhancement
Group: None
Submitted By: Skidyid (skidyid)
Assigned to: Tim Anderson (tanderson)
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.
----------------------------------------------------------------------
Message:
Logged In: YES
user_id=557161
Changes applied. Will be available in 0.7.7-alpha-2
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-06-08 23:29
Message:
Logged In: YES
user_id=557161
The problem with this approach is that SelectorParser is a
generated class, generated from Selector.g
It may be possible to avoid modifying the generated source
however - anltr.Parser provides a setASTFactory() method which
could potentially be used within the initialize() method in
Selector.g to set the new ASTFactory.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1183082&group_id=54559
Message generated for change (Comment added) made by tanderson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1183082&group_id=54559
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: enhancement
Group: None
Status: Closed
Priority: 5Submitted By: Skidyid (skidyid)
Assigned to: Tim Anderson (tanderson)
Summary: Weblogic ANTLR 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.
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-11-13 00:48Message:
Logged In: YES
user_id=557161
Changes applied. Will be available in 0.7.7-alpha-2
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-06-08 23:29
Message:
Logged In: YES
user_id=557161
The problem with this approach is that SelectorParser is a
generated class, generated from Selector.g
It may be possible to avoid modifying the generated source
however - anltr.Parser provides a setASTFactory() method which
could potentially be used within the initialize() method in
Selector.g to set the new ASTFactory.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474139&aid=1183082&group_id=54559