[ openjms-Feature Requests-1183082 ] Weblogic ANTLR conflict

"SourceForge.net" <[email protected]> Sat, 12 Nov 2005 05:48:41 -0800
Newsgroups gmane.comp.java.openjms.devel
Message-ID <[email protected]>
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
>Status: Closed
Priority: 5
Submitted 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:48

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


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php