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

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

--- Comment #11 from Nick Cross <[email protected]> ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.

_______________________________________________
jacorb-bugs mailing list
[email protected]
https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-bugs