http://www.jacorb.org/bugzilla/show_bug.cgi?id=984
--- Comment #11 from Nick Cross <jacorb at goots.org> ---
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spline.inf.fu-berlin.de/pipermail/jacorb-bugs/attachments/20140620/a29d24ff/attachment.html>