Can you provide a test case ? Note this is already being discussed on the jacorb-developer list by Timothy Astle

Created attachment 437 [details]
Differences of ORB.init() in Java 7u51 and 7u55

I do not have a testcase out of the box. Our problem is similar to the one discussed on the mailinglist. But we do not use servlets. Our problem occures when using Java-Webstart. I can give you some more information:

This is the stacktrace we encounter:
org.omg.CORBA.INITIALIZE: can't instantiate default ORB implementation org.jacorb.orb.ORBSingleton
	at org.omg.CORBA.ORB.create_impl_with_systemclassloader(Unknown Source) ~[?:1.7.0_55]
	at org.omg.CORBA.ORB.init(Unknown Source) ~[?:1.7.0_55]
	at org.jacorb.orb.ORBSingleton.configure(ORBSingleton.java:140) ~[jacorb.jar:3.1  (Build August 19 2012 14:54:20)]
	at org.jacorb.orb.ORB.configure(ORB.java:276) ~[jacorb.jar:3.1  (Build August 19 2012 14:54:20)]
	at org.jacorb.orb.ORB.set_parameters(ORB.java:1589) ~[jacorb.jar:3.1  (Build August 19 2012 14:54:20)]
	at org.omg.CORBA.ORB.init(Unknown Source) ~[?:1.7.0_55]
	at ... (our own classes follow here)
	
JacORB contains the class org.omg.CORBA.ORB with the same packagename as ORB contained in the JRE, too. Therefore it depends on classpath-order which implementation the system will use. JacORBs ORBSingleton calls org.omg.CORBA.ORB.init() and gets the JRE-implementation of ORB, as you can see in the third line of the stacktrace. 
The implementation of this method has been changed by Oracle in Java 7u55. A comparision of the two versions (7u51 vs. 7u55) I will provide as screenshot. As you can see there, the new method create_impl_with_systemclassloader(...) is introduced and used. It takes the system-classloader instead of the context-classloader of the current thread, which was taken by the old implementation in create_impl(...) on 7u51. 
In a Webstart-environment only the JNLP-classloader knows the JARs downloaded by Webstart, the system-classloader doesn't. That's the reason why the ORBSingleton-class can't be found and the exception is thrown.

Can you please test using the latest codebase (or latest stable 3.4) ?

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

Add x-ref to stackoverflow : https://stackoverflow.com/questions/23217131/java-7-update-55-jacorb-error-when-running-via-webstart

With JacORB 3.4 it seems to work, but we have other problems, e. g. that server and client can only communicate with each other while running on the same machine. Until now, we have no idea why this happens.

What interfaces are being picked? Please open a separate issue for this.

(In reply to Nick Cross from comment #8)
> What interfaces are being picked? Please open a separate issue for this.
No Problem, see Bug 985 for all details.

(In reply to Christian Bindseil from comment #7)
> With JacORB 3.4 it seems to work, but we have other problems, e. g. that
> server and client can only communicate with each other while running on the
> same machine. Until now, we have no idea why this happens.

After solving the issue in communication (see Bug 985) I can confirm that JacORB 3.4 (and a snapshot of 3.5) works in our(!) Environment. Someone other told me bay mail, that for him 3.4 doesn't fix the problem.

So far I have no idea why it is like it is, but we simply changed the JARs, fixed some problems caused by changes in API and redeployed the application in two seperate Webstart-environments: the classloader finds the JacORB classes and does no longer stop in JRE implementations of ORB or ORBSingleton. I've tested with Java 7u55 and 8u05, both in 32 Bit.

Beginning next week we will test our whole system to ensure that there are no new problems.

Latest updates from mailing list:

Timothy Astle:


I found out our problem.  I'm not sure if this will help anyone else out 
or not.

This is how we're initializing the ORB:

/props.setProperty("org.omg.CORBA.ORBClass","org.jacorb.orb.ORB");
props.setProperty("org.omg.CORBA.ORBSingletonClass","org.jacorb.orb.ORBSingleton");
orb = (org.jacorb.orb.ORB)org.omg.CORBA.ORB.init(args, props);/


Below is a snip of the initialization stack traceusing JacORB 3.4:

/Daemon Thread [localhost-startStop-1] (Suspended (breakpoint at line 
303 in org.omg.CORBA.ORB))
     owns: java.lang.Class<T> (org.omg.CORBA.ORB) (id=89)
     owns: java.util.concurrent.ConcurrentHashMap<K,V> (id=77)
     owns: java.util.concurrent.ConcurrentHashMap<K,V> (id=78)
     owns: java.lang.Object  (id=79)
     owns: org.apache.catalina.core.StandardContext (id=40)
org.omg.CORBA.ORB.create_impl_with_systemclassloader(java.lang.String) 
line: 303
*    org.omg.CORBA.ORB.init() line: 294 *
org.jacorb.orb.ORB(org.jacorb.orb.ORBSingleton).configure(org.jacorb.config.Configuration) 
line: 149
org.jacorb.orb.ORB.configure(org.jacorb.config.Configuration) line: 274
org.jacorb.orb.ORB.set_parameters(java.lang.String[], 
java.util.Properties) line: 1820
*    org.omg.CORBA.ORB.init(java.lang.String[], java.util.Properties) 
line: 369 *
com.caris.fusion.core.JDMC_ConnectionContainer.initORB(java.lang.String[], 
java.util.Properties) line: 69
com.caris.piranha.dataaccess.fusion.core.PiranhaFusionImpl.initORB(java.util.Properties) 
line: 208
com.caris.piranha.dataaccess.fusion.core.PiranhaFusionImpl.initializeFusion() 
line: 191
com.caris.piranha.dataaccess.fusion.core.PiranhaFusionImpl.<init>(com.caris.config.ConfigService) 
line: 133
sun.reflect.NativeConstructorAccessorImpl.newInstance0(java.lang.reflect.Constructor, 
java.lang.Object[]) line: not available [native method]
sun.reflect.NativeConstructorAccessorImpl.newInstance(java.lang.Object[]) line: 
57
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(java.lang.Object[]) 
line: 45
java.lang.reflect.Constructor<T>.newInstance(java.lang.Object...) line: 526
org.springframework.beans.BeanUtils.instantiateClass(java.lang.reflect.Constructor<T>, 
java.lang.Object...) line: 126 /

I bolded the two lines of interest.  They are the ORB.init() calls.

You're going to laugh, but the problem was that ourlog4j.properties did 
not have an entry for org.jacorb.orb (or org.jacorb) so it fell into the 
following code.  I bolded the interesting part again.

org.jacorb.orb.ORBSingleton

/protected void configure(Configuration config) throws 
ConfigurationException
{
...
//
//        if (logger.isDebugEnabled())//
//        {//
//logger.debug("BufferManagerFactory: " + bufferManagerFactory);//
//logger.debug("BufferManager: " + bufferManager);//
//logger.debug("jacorb.interop.strict_check_on_tc_creation set to " + 
doStrictCheckOnTypecodeCreation);//
//
//            // This could lead to dual Singleton initialisation so 
only do it as part of debug. A singleton//
//            // will be initialised in org.omg.CORBA.ORBSingleton [a 
JacORB class] and in org.omg.CORBA.ORB//
//            // as well.//
//            if ( ! ( *org.omg.CORBA.ORB.init() *instanceof 
ORBSingleton))//
//            {//
//                logger.debug ("Default Singleton ORB is not a JacORB 
singleton. This is not recommended as it *could* lead to 
classpath/classloader/stub conflicts.");//
//            }//
//        }//
//}/

By simply adding the following entry to your log4j.properties file

/log4j.logger.org.jacorb=ERROR, //YOUR//_APPENDER_HERE/

the problem goes awayif you're using JacORB 3.4.  The problem still 
exists for prior versions.

I had first thought that the problem went away using JacORB 3.4 alone. 
Before Java 7 update 55 was released, I had asked a developer to add our 
missing logging configuration in our nextmajor release branch.  This was 
also the branch where we had updated to JacORB 3.4.  This is why the 
problem was not surfacing on that branch of the product.

Nick, what do you think about that no-args init() call?  It seems a bit 
dangerous because if people don't set up their logger correctly, 
theycould be hosed and not know why.


Tim


=========================

Hugo Roenick

Hi Tim.

I did see that when investigating this problem (and indeed is a little funny). 
It may solve the problem when initialising the orb, but that's not the only place where "ORB.init()" (no-args init) is used. The IDL compilation generate Helper classes that use this no-args init, for instance the "type()" method. So you I believe must have certain that you're not using this method anywhere eles in your program (directly or indirectly).

In our case we do use *Helper.type(), so it's not a solution for us.

Regards,

Hugo


=========================



Hi Hugo and Tim,

I agree that debug logging for the no-init call could be moved out, 
perhaps into a standalone diagnostic class (it is only useful for 
debugging certain scenarios anyway).

Regarding the Helper classes, JacORB does possess a QoS in the IDL 
compiler to generate_helper with different forms i.e. we could make an 
enhancement to generate with a different call e.g. to the JacORB 
ORBSingleton class instead. This may work around the issue. A test case 
to prove this would help 

Thanks

Nick

*** Bug 988 has been marked as a duplicate of this bug. ***

From discussions on the mailing list I think the majority of the cases in JacORB are now resolved for 3.5 And Oracle may well fix the issue in their code.