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 > > >