<html>
<head>
<base href="http://www.jacorb.org/bugzilla/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:jacorb@goots.org" title="Nick Cross <jacorb@goots.org>"> <span class="fn">Nick Cross</span></a>
</span> changed
<a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - JacORB unusable with Java Webstart in Java 1.7.0u55"
href="http://www.jacorb.org/bugzilla/show_bug.cgi?id=984">bug 984</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>ASSIGNED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - JacORB unusable with Java Webstart in Java 1.7.0u55"
href="http://www.jacorb.org/bugzilla/show_bug.cgi?id=984#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - JacORB unusable with Java Webstart in Java 1.7.0u55"
href="http://www.jacorb.org/bugzilla/show_bug.cgi?id=984">bug 984</a>
from <span class="vcard"><a class="email" href="mailto:jacorb@goots.org" title="Nick Cross <jacorb@goots.org>"> <span class="fn">Nick Cross</span></a>
</span></b>
<pre>Cut n pasting the information from Timothy Astle for reference:
=====
<span class="quote">>
> <a href="http://hg.openjdk.java.net/jdk7u/jdk7u60/corba/rev/a8d27c3fc4e4">http://hg.openjdk.java.net/jdk7u/jdk7u60/corba/rev/a8d27c3fc4e4</a>
>
> 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:
> * <a href="https://java.net/jira/browse/GLASSFISH-21047">https://java.net/jira/browse/GLASSFISH-21047</a>
> *
> <a href="http://stackoverflow.com/questions/23225144/java-7u55-eclipse-system-fragment-classloader">http://stackoverflow.com/questions/23225144/java-7u55-eclipse-system-fragment-classloader</a>
>
> 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:
> <a href="http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html">http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html</a>
>
> 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 (<a href="http://bugs.java.com">http://bugs.java.com</a>). 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 (<a href="http://www.jacorb.org/TomcatHowto.html">http://www.jacorb.org/TomcatHowto.html</a>), but I didn't
> seem to have any problems just bundling it into the WAR itself.
>
> Any tips would be appreciated,</span >
=====
<span class="quote">> 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</span ></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>