incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nolan, Edell" <Edell.No...@iona.com>
Subject RE: Difference between Java 1.4.2 vs. Java 1.5
Date Wed, 27 Sep 2006 17:59:06 GMT
Thanks for the update and glad you got it working.

Edell. 

-----Original Message-----
From: Rick McGuire [mailto:rickmcg@gmail.com] 
Sent: 27 September 2006 18:32
To: yoko-dev@incubator.apache.org
Subject: Re: Difference between Java 1.4.2 vs. Java 1.5

I finally got my openejb2 test working.  I got fooled by a subtle bit of
redirection being done by the Yoko unit tests.  Our tests launch child
processes for the client and server portions of the tests, and the unit
test infrastructure ensures they're launched with the same value for
java.endorsed.dirs as the base test case harness.  The
java.endorsed.dirs property doesn't work unless it has been specified on
the java command line.  All it took was adding

                        
<argLine>-Djava.endorsed.dirs=${project.build.directory}/endorsed</argLi
ne>

to my surefire plugin definition.  Man, this was an ugly one to figure
out :-)

Rick


Darren Middleman wrote:
> I'm not sure why the endorsed dirs property is not solving this but 
> yes, this is something that will only occur on JDK 1.5.
> The reason is because in Java 1.4, the JDK did not include an 
> implementation of the IORInterceptor_3_0 class, so the version 
> included with Yoko is the only one it would use.
> Unfortunately, Sun
> added an implementation of IORInterceptor_3_0 to JDK 1.5 which differs

> from both the CORBA spec and the Yoko implementation (they use an 
> integer parameter as an ID where as it should be a String).  So this 
> is why you are seeing the error now when you've moved to JDK 1.5.
>
> I would agree with Balaji and his recommendations.  See if trying to 
> use endorsed.dirs or Xbootclasspath outside of Maven clears things up.

> I know that we have been using the Xbootclasspath options in the 
> READMEs for the samples and I don't recall seeing this issue during 
> the testing of the demos when this option was used.
>
> Darren
>
>
>
> On 9/25/06, Mosur Ravi, Balaji <bravi@iona.com> wrote:
>>
>> Hi rick,
>>
>> I can't explain why it is failing in 1.5 & not in 1.4.2 but in 1.5 
>> the java.endorsed.dirs setting is definitely not picked up.
>>
>> Can you run this outside of maven & confirm if it runs with 1.5 with 
>> the java.endorsed.dirs setting or the Xbootclasspath option...?
>>
>>
>> - Balaji
>>
>>
>> -----Original Message-----
>> From: Rick McGuire [mailto:rickmcg@gmail.com]
>> Sent: Monday, September 25, 2006 1:06 PM
>> To: yoko-dev@incubator.apache.org
>> Subject: Difference between Java 1.4.2 vs. Java 1.5
>>
>> I have a small module I've built for the openejb2 Yoko ORB adapter.
>> This is a fairly simple module, with not much code.  There are a 
>> couple of test cases that get run during the build, and I've 
>> configure the surefile plugin to used endorsed.dir.  Everything is 
>> working great under
>>
>> Java 1.4.2.
>>
>> Today, I tried building with Java 1.5 for the first time, and I'm 
>> getting a test case failure:
>>
>>   <testcase time="1.515" name="testCORBABean"/>
>>   <testcase time="0.047" name="testOrb">
>>     <error type="java.lang.NoSuchMethodError"
>> message="org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manag
>> er_
>> state_changed(Ljava/lang/String;S)V">java.lang.NoSuchMethodError:
>> org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_
>> cha
>> nged(Ljava/lang/String;S)V
>>     at
>> org.apache.yoko.orb.OB.PIManager.adapterManagerStateChange(PIManager.
>> jav
>> a:531)
>>     at
>> org.apache.yoko.orb.OBPortableServer.POAManager_impl.activate(POAMana
>> ger
>> _impl.java:212)
>>     at
>> org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.initialize
>> (Tr
>> ansientNameService.java:128)
>>     at
>> org.apache.yoko.orb.CosNaming.tnaming.TransientNameService.run(Transi
>> ent
>> NameService.java:113)
>>     at
>> org.openejb.corba.yoko.ORBConfigAdapter.createNameService(ORBConfigAd
>> apt
>> er.java:149)
>>     at org.openejb.corba.NameService.doStart(NameService.java:162)
>>     at
>> org.openejb.corba.yoko.NameServiceTest.setUp(NameServiceTest.java:58)
>>     at junit.framework.TestCase.runBare(TestCase.java:125)
>>     at junit.framework.TestResult$1.protect(TestResult.java:106)
>>     at junit.framework.TestResult.runProtected(TestResult.java:124)
>>     at junit.framework.TestResult.run(TestResult.java:109)
>>     at junit.framework.TestCase.run(TestCase.java:118)
>>     at junit.framework.TestSuite.runTest(TestSuite.java:208)
>>     at junit.framework.TestSuite.run(TestSuite.java:203)
>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>     at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
>> jav
>> a:39)
>>     at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>> sor
>> Impl.java:25)
>>     at java.lang.reflect.Method.invoke(Method.java:585)
>>     at
>> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.jav
>> a:2
>> 10)
>>     at
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes
>> tSe
>> t(AbstractDirectoryTestSuite.java:135)
>>     at
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
>> str
>> actDirectoryTestSuite.java:122)
>>     at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>     at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
>> jav
>> a:39)
>>     at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>> sor
>> Impl.java:25)
>>     at java.lang.reflect.Method.invoke(Method.java:585)
>>     at
>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su
>> ref
>> ireBooter.java:225)
>>     at
>> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j
>> ava
>> :747)
>> </error>
>>   </testcase>
>>
>>
>> Which looks like the failure I got before I started using the 
>> endorsed dir.  I'm not sure I understand what's different between 
>> 1.4.2 and 1.5 that would cause this error.  Strangely, the first set 
>> of test cases ran
>>
>> OK, and I would have thought that should have give the same error if 
>> there was a problem with endorsed.dir.
>>
>> Any ideas on what might be going wrong here?
>>
>> Rick
>>
>>
>




Mime
View raw message