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

Hugo Roenick hroenick at gmail.com
Wed May 21 14:49:05 CEST 2014 

Hi guys.

As far as I looked form OpenJDK source code, I notice that JRE forces the use of System's Classloader instead of the Thread's Classloader only when trying to instantiate an ORB by ORB.init() (with no parameters). When we instantiate an ORB providing some parameters than the Thread's Classloader is used. 

However, even if we only use the ORB.init() in ours applications, we can't completely escape from the problem because some of the generated source code from IDL compilation, such as the Helper's type method uses. org.omg.CORBA.ORB.init().

Apparently ORACLE already made the announcement about the problem as Tim anticipated us: 
http://www.oracle.com/technetwork/java/javase/7u55-relnotes-2177812.html

Area: other-libs/corba
Synopsis: Enhanced CORBA initializations

The system property org.omg.CORBA.ORBSingletonClass is used to configure the system-wide/singleton ORB. The handling of this system property has changed to require that the system wide/singleton ORB be visible to the system class loader. This is a change from previous releases where the singleton ORB was located using the thread context class loader of the first thread to call the no-argument ORB.init method. The implication of this change is that the system-wide/singleton ORB needs to be deployed on the class path or in the extension directory.

Applications that bundle their own ORB and only configure the propertyorg.omg.CORBA.ORBClass should not be impacted by this change. The per-application ORB will be located via the thread context class loader of the thread calling the 2-argument ORB.init method as before.

See 8025005 (not public).

Our undestanding about this notes is that now we are forced to use the JRE ORB as the singleton one, and can use any other ORB by using the ORB.init(args, props). We are about to test if not setting the "org.omg.CORBA.ORBSingletonClass" property and setting the org.omg.CORBA.ORBClass property works. 

PS: we can find a bug registered in java's database about this problem.
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8042462

Regards,
-- Hugo

On May 10, 2014, at 10:13 PM, Timothy Astle <timothy.astle at caris.com> wrote:


> 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.
> 
> _______________________________________________
> jacorb-developer maillist  -  jacorb-developer at lists.spline.inf.fu-berlin.de
> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer

More information about the jacorb-developer mailing list