axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Galpin <cgal...@lhsw.com>
Subject Re: archive lib directory and 3rd party libraries (axis2/tomcat 6)
Date Mon, 25 Jan 2010 17:22:53 GMT
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 <cgalpin@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
> 


Mime
View raw message