[jacorb-developer] FYI - ORB classloader change in Java 7u55, Java 8u5 - Suggestions needed

Sun May 11 03:13:42 CEST 2014

Sure. The change is pretty simple/limited by the looks of it.  It 
affects the JRE's ORB.init(args, props) method.

I think there are probably several ways to work around this:
* People could just create their own init, and not use the one in the 
JRE.Take ownership of the reflection ORB init method.
* Concretely instantiate the JacORB ORB or whatever ORB the person wants 
to use.

I'm going to check out the source on Monday (installed Mercurial on 
Friday) and peek around abitand see.

For the time being, I've had to send out product to JRE compatibility 
notices so that System Administrators don't update their JREs just to 
have our product break.

Tim

On 10/05/2014 4:00 AM, Nick Cross wrote:
>
> Thanks for that Tim ; very informative.
>
> It would be useful I think to put together some test cases to see what 
> scenarios this would be encountered and what workarounds are available 
> until Oracle come up with a solution.
>
> Regards
>
> Nick
>
> On 10/05/14 00:54, Timothy Astle wrote:
>> I've been in contact with the author of the change in the JRE.  He's
>> been very cordial.
>>
>> When I contacted him about the change, this was the first reply:
>>
>> "The loading of a third party singleton ORB has changed. It is loaded by
>> the system loader only, thus requiring that
>> the specified class is on the application's classpath. Thus, when
>> -Dorg.omg.CORBA.ORBSingletonClass is specified
>> then classpath variable needs to be amended, also. A CORBA compliant
>> singleton ORB is essentially a TypeCode factory.
>> Its instantiation is via the no-args ORB.init() method call. As it is a
>> singleton, it should be loaded with appropriate privileges.
>> The same functionality should be available from a full ORB
>> (org.omg.CORBA.ORBClass).
>>
>> As such, it is not a bug per se. But the absence of relevant release
>> note document is a problem.
>> Unfortunately, as this change had generated a number of JBS issues, we
>> noticed that a relevant release note was not created.
>> This is being rectified at present."
>>
>> I then asked for a recommendationbecause I have a simple WAR deployment
>> requirement, and he replied as follows:
>>
>> "I would ask that you bear with us, a while on this, as we address this
>> backward compatibility issue, and look
>> to solve the issues raised.  We were aware that there might be some
>> compatibility issue, and had marked it as a risk,
>> but as  the Singleton ORB is limited in scope, and functionality we
>> anticipated that it would be reasonably OK to
>> proceed with the refactored loading strategy. The anticipation was that
>> deployments could modify the classpath,
>> and that TCCL loading of the full ORB would be sufficient in most cases.
>>
>> In any case, we looking into this ORBSingleton conundrum, and will get
>> back to shortly on this."
>>
>> I might be reading into this, but it seems like they're going to address
>> the problem.
>>
>> If I get any more information, I'll be happy to pass it along.
>>
>> Tim
>>
>>
>>
>>
>> On 09/05/2014 7:48 PM, Ravindra Kumar wrote:
>>> Hi
>>> Apparently i have also encountered the same issue. It is a bug 
>>> definitely.
>>>
>>> thanks
>>> rainvdra
>>>
>>>
>>> On Sat, May 10, 2014 at 12:42 AM, Timothy Astle 
>>> <timothy.astle at caris.com>wrote:
>>>
>>>> http://hg.openjdk.java.net/jdk7u/jdk7u60/corba/rev/a8d27c3fc4e4
>>>>
>>>> The change looks to be introduced into:
>>>> * Java 8 update 5
>>>> * Java 7 update 55
>>>> * Java 6 (looks like it was backported there too)
>>>>
>>>> It appears that people are just starting to encounter this issue as 
>>>> they
>>>> update their JREs:
>>>> * https://java.net/jira/browse/GLASSFISH-21047
>>>> * http://stackoverflow.com/questions/23225144/java-7u55-
>>>> eclipse-system-fragment-classloader
>>>>
>>>> It can affect web applications that are distributing JacORB within 
>>>> the web
>>>> application itself.  Oracle changed the classloader that searches 
>>>> for the
>>>> ORBSingletonClass, so now the implementation class must be on the 
>>>> System
>>>> classpath, not the web application's classpath, else the JRE will 
>>>> not find
>>>> the implementation.  You can see how this applies to servlet 
>>>> containers
>>>> here: http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html
>>>>
>>>> People will most likely see this exception when it is encountered:
>>>>
>>>> Caused by: org.omg.CORBA.INITIALIZE: can't instantiate default ORB
>>>> implementation com.sun.corba.ee.impl.orb.ORBSingleton vmcid: 0x0 minor
>>>> code: 0 completed: No
>>>> at org.omg.CORBA.ORB.create_impl_with_systemclassloader(ORB.java:309)
>>>> at org.omg.CORBA.ORB.init(ORB.java:294)
>>>>
>>>> I was in contact with the committer from Oracle today.  He says 
>>>> this is
>>>> not a bug, but they admit that the documentation on the change was 
>>>> poor and
>>>> they've been getting a fair amount of issues filed about it in 
>>>> their bug
>>>> database (http://bugs.java.com).  I believe they aim on remedying 
>>>> this.
>>>>
>>>> So I'm left with a question to the experienced JacORB developers:
>>>>
>>>> Is there a way that I can distribute JacORB within a WAR file and 
>>>> have it
>>>> work given the breaking change in the JRE?  I was basically just 
>>>> doing this:
>>>>
>>>> Properties props = new Properties();
>>>> props.setProperty("org.omg.CORBA.ORBClass", "org.jacorb.orb.ORB");
>>>> props.setProperty("org.omg.CORBA.ORBSingletonClass",
>>>> "org.jacorb.orb.ORBSingleton");
>>>> org.jacorb.orb.ORB orb = (org.jacorb.orb.ORB) 
>>>> org.omg.CORBA.ORB.init(args,
>>>> props);
>>>>
>>>> I know the JacORB docs always mention supplying the ORB to the
>>>> bootclasspath (http://www.jacorb.org/TomcatHowto.html), but I 
>>>> didn't seem
>>>> to have any problems just bundling it into the WAR itself.
>>>>
>>>> Any tips would be appreciated,
>>>>
>>>> -- 
>>>> Tim Astle
>>>> _______________________________________________
>>>> jacorb-developer maillist  -  jacorb-developer at lists.spline.
>>>> inf.fu-berlin.de
>>>> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer 
>>>>
>>>>
>>> _______________________________________________
>>> jacorb-developer maillist  - 
>>> jacorb-developer at lists.spline.inf.fu-berlin.de
>>> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer
>>>
>>>
>>
>
> _______________________________________________
> jacorb-developer maillist  - 
> jacorb-developer at lists.spline.inf.fu-berlin.de
> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer
>
>

-- 
Tim Astle
Development Manager
Web Technologies

*CARIS* <http://www.caris.com>
115 Waggoners Lane
Fredericton, New Brunswick
Canada    E3B 2L4
Tel: +1.506.458.8533     Fax: +1.506.459.3849
www.caris.com

*CARIS 2014*
June 2-5, 2014 | Brest, France | 2-5 juin, 2014
Join us in France at CARIS 2014 as we focus on Developing the Blue 
Economy. www.caris.com/caris2014/
Venez nous rejoindre en France pour CARIS 2014 et appuyons ensemble 
l'Économie Bleue. www.caris.com/caris2014-fr/

Download your free copy of CARIS Easy View today!
www.caris.com/easyview

_________________________________________________________________________
This email and any files transmitted with it are confidential and 
intended only for the addressee(s). If you are not the intended 
recipient(s) please notify us by email reply. You should not use, 
disclose, distribute or copy this communication if received in error.

Any views or opinions expressed in this email are solely those of the 
author and do not necessarily represent those of the company. No binding 
contract will result from this email until such time as a written 
document is signed on behalf of the company.