[jacorb-bugs] [Bug 984] JacORB unusable with Java Webstart in Java 1.7.0u55

[bugzilla-daemon at jacorb.org]

http://www.jacorb.org/bugzilla/show_bug.cgi?id=984

Nick Cross <jacorb at goots.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #5 from Nick Cross <jacorb at goots.org> ---
Cut n pasting the information from Timothy Astle for reference:

=====

> 
> 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,


=====

> 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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spline.inf.fu-berlin.de/pipermail/jacorb-bugs/attachments/20140515/c515245d/attachment-0001.html>