Charles,
According to the stack trace you posted, the error occurs inside a
thread that is neither managed by the servlet container, nor by Axis2:
13:38:58 DEBUG- Stack trace: org.omg.CORBA.INITIALIZE: can't
instantiate default ORB implementation org.jacorb.orb.ORB vmcid: 0x0
minor code: 0 completed: No
at org.omg.CORBA.ORB.create_impl(ORB.java:297)
at org.omg.CORBA.ORB.init(ORB.java:336)
at client.corba.BaseCORBAApp.initCORBA(BaseCORBAApp.java:134)
at client.corba.BaseCORBAService.startService(BaseCORBAService.java:100)
at
client.project.dcol.publish.corba.WebServiceDataCollectionService.webInit(WebServiceDataCollectionService.java:170)
at
client.project.dcol.GDPI.ServiceBase$ServiceThread.run(ServiceBase.java:318)
at java.lang.Thread.run(Thread.java:619)
How and where is this thread created?
Andreas
On Mon, Jan 25, 2010 at 20:23, Charles Galpin <cgal...@lhsw.com> wrote:
> Thanks Andreas
>
> I added this to both services being loaded, rebuilt and ran, but no change.
>
> The composite class loader was one of the options described in Amil's blog
> and as I understand it, it is supposed to use both the TCCL and the service
> class loader. But I guess I still don't understand the class loading because
> this jar is in all the places the class loaders should be looking so I don't
> see how it matters which one it uses.
>
> I also tried the "EnableChildFirstClassLoading" parameter as well but no help.
>
> Thanks,
> charles
>
> On Jan 25, 2010, at 1:53 PM, Andreas Veithen wrote:
>
>> Try adding the following parameter on the service:
>>
>> <parameter name="ServiceTCCL" locked="false">composite</parameter>
>>
>> Andreas
>>
>> On Mon, Jan 25, 2010 at 18:22, Charles Galpin <cgal...@lhsw.com> wrote:
>>> Hi All
>>> I am still running into problems with this. I previously moved all the jars
>>> I needed into the WEB-INF/lib directory and was able to continue working.
>>> But as I add more services (more .aar files) I am now running into strange
>>> unpredictable differences that I do not understand.
>>> For example, I have two services packaged in their own .aar files and if
>>> deployed independently they run just fine. Simply deploying both together
>>> causes the second one loaded to have mysterious problems like a
>>> java.sql.SQLException "no suitable driver found for jdbc:sqlserver://.."
>>> when the sql3jdbc jar file is in both the .aar and WEB-INF/lib directory and
>>> (and as I said works fine standalone).
>>> Does anyone have any advice on how to get my services to run together
>>> happily? Assume I am not concerned with isolating each service from each
>>> other in terms of security. I read on Amila's blog that some class loading
>>> settings can be modified but it's not clear exactly what ramifications it
>>> will have or if it will even help my problems.
>>> I am not sure if this is causing my problems, but due to wanting to be able
>>> to override the properties file in the .aar file when deployed in different
>>> environments, in the service lifecycle init method I attempt to find the
>>> properties file in the axis classpath before trying the .arr, using first
>>> axisService.getClass().getClassLoader(0.gerResourceAsStream(propsFilename);
>>> and if not found then using
>>> this.getClass().getClassLoader(0.gerResourceAsStream(propsFilename);
>>> Could this be messing up the class loading sequence, and if yes, how can I
>>> achieve the same effect without using the axis class loader first?
>>> thanks,
>>> charles
>>> On Dec 1, 2009, at 2:29 PM, Charles Galpin wrote:
>>>
>>> Hi Sameera
>>> Ok, this is starting to make a little more sense. I was not aware the
>>> WebappClassLoader could not see classes in the .aar. Can this be changed?
>>> I have access to the source of the client.corba.* packages, but they are
>>> just calling org.omg.CORBA.ORB.init which is doing the class loading and
>>> thats from rt.jar in the java distro afaik. The ORB loaded is a configurable
>>> option which is why it uses the class loader.
>>> Here is another exception stack you may find useful. I had run into this
>>> problem as well as various other classes not loading a while ago and made a
>>> few changes until getting my service working, and one of them was to pass
>>> -Djava.library.path="%PATH%;blahblah" in on the commandline when starting
>>> tomcat. Removing this changes the error to a perhaps little more revealing
>>> message (after understanding about the TCCL limitation)
>>> 13:38:58 ERROR- Error initializing CORBA ORB. Unexpected CORBA error.
>>> org.omg.CORBA.INITIALIZE: can't instantiate default ORB implementation
>>> org.jacorb.orb.ORB vmcid: 0x0 minor code: 0 completed: No
>>> 13:38:58 DEBUG- Stack trace: org.omg.CORBA.INITIALIZE: can't instantiate
>>> default ORB implementation org.jacorb.orb.ORB vmcid: 0x0 minor code: 0
>>> completed: No
>>> at org.omg.CORBA.ORB.create_impl(ORB.java:297)
>>> at org.omg.CORBA.ORB.init(ORB.java:336)
>>> at client.corba.BaseCORBAApp.initCORBA(BaseCORBAApp.java:134)
>>> at
>>> client.corba.BaseCORBAService.startService(BaseCORBAService.java:100)
>>> at
>>> client.project.dcol.publish.corba.WebServiceDataCollectionService.webInit(WebServiceDataCollectionService.java:170)
>>> at
>>> client.project.dcol.GDPI.ServiceBase$ServiceThread.run(ServiceBase.java:318)
>>> at java.lang.Thread.run(Thread.java:619)
>>> Caused by: java.lang.ClassNotFoundException: org.jacorb.orb.ORB
>>> at
>>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)
>>> at
>>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
>>> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>>> at java.lang.Class.forName0(Native Method)
>>> at java.lang.Class.forName(Class.java:247)
>>> at org.omg.CORBA.ORB.create_impl(ORB.java:295)
>>> ... 6 more
>>> 13:38:58 ERROR- Aborted due to startup failure.
>>> Aborted due to startup failure: Error initializing CORBA ORB. Unexpected
>>> CORBA error.
>>> Is there any other way to work around this other than putting the libraries
>>> in the axis2/WEB-INF/lib directory? To be clear I have other problems beside
>>> this. A good example is we have a custom log4j appender we use which is in
>>> Shared.jar. This cannot be found either unless it's in axis2/WEB-INF/lib but
>>> your description explains that one too.
>>> thanks,
>>> charles
>>> On Dec 1, 2009, at 1:28 PM, Sameera Jayasoma wrote:
>>>
>>> Hi Charles
>>>
>>> On Tue, Dec 1, 2009 at 11:27 PM, Charles Galpin <cgal...@lhsw.com> wrote:
>>>>
>>>> Hi Sameera
>>>>
>>>> Yes this is what is happening and what is expected. The
>>>> org.omg.CosNotifyFilter.InvalidGrammar class is in jacorb.jar which is in
>>>> the .aar lib directory. What am I missing? Are you saying it should not be
>>>> in the thread context class loader?
>>>
>>> The class BaseCORBAApp is trying to loadInvalidGrammar class from the TCCL
>>> and in this scenario TCCL is set to the WebappClassLoader. Classes in your
>>> aar lib folder cannot be seen by the WebappClassLoader. It can only see the
>>> classes in axis2/WEB-INF/lib folder or in the application classpath
>>> tomcat/lib. That is things work nicely when you put jacob.jar to
>>> axis2/WEB-INF/lib.
>>>
>>> Do you have access to sources of the classes in client.corba.* packages.
>>>
>>> Thanks
>>> sameera
>>>
>>>>
>>>> On Dec 1, 2009, at 12:47 PM, Sameera Jayasoma wrote:
>>>>
>>>>> It seems that "BaseCORBAApp" class is trying to load
>>>>> "org.omg.CosNotifyFilter.InvalidGrammar" from the thread context class
>>>>> loader. That is why you see following lines in the exception log.
>>>>>
>>>>> at
>>>>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)
>>>>> at
>>>>> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
>>>>>
>>>>> This is a usual practice of loading application libraries. If you have
>>>>> access to the source code of client.corba classes, you can verify this.
>>>>>
>>>>> Thanks
>>>>> Sameera
>>>>
>>>>
>>>> Thanks Olindo, but the first error (see the bottom of the trace) is
>>>> java.lang.ClassNotFoundException which I believe is the root cause. I have
>>>> checked and jacorb.jar is not in the path or classpath.
>>>>
>>>> On Dec 1, 2009, at 11:55 AM, Olindo Pindaro wrote:
>>>>
>>>>> The exception isn't "ClassNotFound" but "NoClassDefFoundError", that in
>>>>> my experience is caused by conflit in differente version of library
>>>>> present
>>>>> in compiler path and classloaderpath.
>>>>
>>>> thanks,
>>>> charles
>>>>
>>>
>>>
>>>
>>> --
>>> Sameera Jayasoma
>>> Software Engineer
>>> WSO2 Inc.
>>> Oxygenating the Web Service Platform.
>>> http://wso2.org/
>>>
>>> blog: http://tech.jayasoma.org
>>>
>>>
>>>
>
>
