Re: FYI - ORB classloader change in Java 7u55, Java 8u5 - Suggestions needed

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

_______________________________________________
jacorb-developer maillist  -  [email protected]
https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer