geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Re: Is java.endorsed.dirs actually working?
Date Wed, 27 Sep 2006 15:35:14 GMT
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?
Let me give you an indirect answer here by first answering the question 
for 1).  My experiments with the simple test case show that if you set 
java.endorsed.jars, then all of the jar files in the reference 
directories are automatically part of the classpath (or more 
appropriately, the bootclasspath).  They function as if you had 
prepended the jars to the bootclasspath.  The resolved class have the 
"null" classloader.

The endorsed dir is set for 2) and 3) by setting the system property in 
the surefire plugin definition. 

     <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
          <includes>
            <include 
implementation="java.lang.String">**/org/apache/yoko/*Test.java</include>
          </includes>
          <systemProperties>
            <property>
              <name>java.endorsed.dirs</name>
              <value>${basedir}/target/endorsed</value>
            </property>
          </systemProperties>
        </configuration>
      </plugin>

The jar files are copied to the endorsed dir using the dependency plugin:

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-dependency-plugin</artifactId>
        <executions>
          <execution>
            <phase>generate-sources</phase>
            <goals>
              <goal>copy</goal>
            </goals>
            <configuration>
              <artifactItems>
                <artifactItem>
                  <groupId>org.apache.yoko</groupId>
                  <artifactId>yoko-spec-corba</artifactId>
                  <type>jar</type>
                  <overWrite>true</overWrite>
                  
<outputDirectory>${project.build.directory}/endorsed</outputDirectory>
                </artifactItem>
              </artifactItems>
            </configuration>
          </execution>
        </executions>
      </plugin>

The jar files also are ending up on the classpath by virtue of the 
dependencies, but my experiments with 1) suggest this shouldn't be 
necessary, and the classes in the endorsed dir should be picked up instead.


>
> Does 2) involve an actual yoko jar or does it run off of unjarred 
> classes?
A 4 of these are using the same version of the yoko jar file.
>
> 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?
I haven't tried that experiment yet.  I'll try hacking something up.

>
> thanks
> david jencks
>
>
>
>>
>> Rick
>>
>>
>
>


Mime
View raw message