geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Is java.endorsed.dirs actually working?
Date Thu, 28 Sep 2006 18:18:57 GMT
There is a lot of text here and I'm a bit confused.  FWIU, to use the  
trick we used in bootstrap you need the following:

1) add your endorsed jars to the manifest class path
2) no code accessed during the boot process can reference an endorsed  
package
3) modify the endorsed system property
4) use reflection to load a class that accesses the endorsed class  
(this may have to happen in a child class loader)

I have high confidence in this process due to the tck passing.   
Additionally, I received a customer complaint that we were overriding  
the xml processor on Java5 with the older spec version included with  
Geronimo.  Now it may turn out that this magic only works with the  
xml specs, but I'd be very surprised.

-dain

On Sep 27, 2006, at 8:11 AM, Rick McGuire wrote:

> I've been wrestling with a Yoko ORB problem when running under Java  
> 5.  When running on 1.4.2, the Yoko ORB works fine because the  
> native JVM doesn't include an implementation of  
> org.omg.PortableInterceptor.IORInterceptor_3_0.  Because there's no  
> conflict, the yoko version is getting loaded.
> With Sun's Java 5 impl, there is a version of  
> org.omg.PortableInterceptor.IORInterceptor_3_0 that's incompatible  
> with the CORBA standard (and also the Yoko implementation).  The  
> Sun version is getting picked up, cause ORB initialization  
> failures.  This is occurring even though the yoko-spec-corba jar  
> has been copied into lib/endorsed.
>
> I decided to try an experiment using the jetty-j2ee Geronimo  
> assembly.  I deleted the Xerces jars from the lib/endorsed  
> directory.  I did this to convince myself that the  
> java.endorsed.dirs mechanism was working correctly and the problem  
> was due to me missing something with the yoko cofiguration.  I  
> expected Geronimo to "fall over" during launch because of the  
> missing jars.  To my surprise, it didn't.
> I instrumented one of the yoko classes, and add it load the  
> IORInterceptor_3_0 class and org.w3c.dom.Element and dump the  
> package information for these classes.  The Package information  
> indicates both of these classes are resolving to the JVM native  
> versions rather than the versions in lib/endorsed.  The  
> java.endorsed.dirs appears to be set to the correct value, and the  
> jar files are in the appropriate directory, but the classes don't  
> appear to be getting picked up.
>
> This was just the last experiment for a problem I've been chasing  
> since Monday.  I'm getting extremely inconsistent results from  
> using java.endorsed.dirs.  Right now, I have 4 situations in front  
> of me:
>
> 1)  Simple standalone test case using Yoko ORB.
> 2)  Yoko unit tests using surefire plugin.
> 3)  Openejb Yoko unit tests using surefile plugin (setup was copied  
> from the Yoko unit tests).
> 4)  Full Geronimo assembly using the Yoko ORB.
>
> When running under Java 5, 1) and 2) work ok.  3) fails, even  
> though the surefile tests (in theory) are running exactly the same  
> way as 2).  4) also fails.  1), 3), and 4) all work fine under Java  
> 1.4.2, but there's no conflict with the native IORInterceptor_3_0  
> class is that scenario.  I spent most of yesterday wrestling with  
> scenario 3), and never getting it to work.  Like scenario 4), the  
> jar files are in the target endorsed directory and the  
> java.endorsed.dirs is pointing to the correct location.  Right now,  
> I'm completely stumped, and I'm wondering if this has every really  
> worked in the Geronimo assembly.
>
> Rick
>


Mime
View raw message