-Djava.endorsed.dirs is interpreted during the construction of the bootstrap classpath. Setting it in a Java class does not have an effect for the current JVM. Daemon.java would have to spawn a new process and start another JVM passing the property.
Heinz On 9/27/06, Rick McGuire <[EMAIL PROTECTED]> wrote:
Ok, I've got it working 4-for-4 now, and I was right, it IS broken in Geronimo right now. The missing piece is the -Djava.endorsed.dirs on the commandline. It appears that setting this value in Daemon.java won't work. It needs to be set on the commandline. Rick David Jencks wrote: > > 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. > > I have often wondered if our endorsed dir actually worked also... it's > always seemed somewhat unlikely :-) > > How is the endorsed dir set for 2) and 3), and how does the yoko jar > get onto the classpath? > > Does 2) involve an actual yoko jar or does it run off of unjarred > classes? > > Is anything different in esp. 4) if you set the endorsed dir on the > command line rather than letting geronimo set it after the jvm has > started more? > > thanks > david jencks > > > >> >> Rick >> >> > >
