Well, you did say that setting the context classloader did fix the commons-logging problem. Next is a new, axis related problem. Can you give us the stacktrace of the exception you are seeing there?
regards, Karl On Wed, Oct 22, 2008 at 6:40 PM, Per-Erik Svensson <[EMAIL PROTECTED]> wrote: > Hi all, > > Has anyone found a solution to this problem? > > Regards, > Per-Erik Svensson > > -----Ursprungligt meddelande----- > Från: Per-Erik Svensson [mailto:[EMAIL PROTECTED] > Skickat: den 17 oktober 2008 13:44 > Till: [email protected] > Ämne: SV: commons-logging and Axis problems > > Very kind of you! I tried with Felix 1.2.1 but the problem remains. It is > probably just me doing something wrong. At least that's my approach when > using frameworks - either I make a mistake, or it all works as expected. :-) > > Regards, > Per-Erik > > -----Ursprungligt meddelande----- > Från: Karl Pauls [mailto:[EMAIL PROTECTED] > Skickat: den 17 oktober 2008 12:19 > Till: [email protected] > Ämne: Re: commons-logging and Axis problems > > Great, thanks. I can take a look into it during the weekend (no time > today). However, do me a favour and try running your example with > Felix 1.2.1 (or better, the current trunk - but that would need more > work because we have some api changes for embedding). We did fix some > bugs in this area since 1.0.4. > > regards, > > Karl > > On Fri, Oct 17, 2008 at 12:14 PM, Per-Erik Svensson > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I've put a .zip together and made it available at >> http://www.2conciliate.se/tmp/Felix.zip. (I wasn't sure if the mailing > list >> permits attachments.) >> >> To answer your question I'm using Felix version 1.0.4. >> >> License note: All non-Apache licensed code is proprietary and must not be >> redistributed (or else my boss will eat my non-existent cat). >> >> Regards >> Per-Erik >> >> -----Ursprungligt meddelande----- >> Från: Karl Pauls [mailto:[EMAIL PROTECTED] >> Skickat: den 17 oktober 2008 10:46 >> Till: [email protected] >> Ämne: Re: commons-logging and Axis problems >> >> can you make your bundle and test case available to us? Furthermore, >> which version of Felix are you using? >> >> regards, >> >> Karl >> >> On Fri, Oct 17, 2008 at 10:35 AM, Per-Erik Svensson >> <[EMAIL PROTECTED]> wrote: >>> Hi and thanks for the respons, >>> >>> Well, your first solution seems to help with the immediate exception but > I >>> do however get other exceptions down the Axis chain (not connected with >>> logging though). The new exceptions have to do with different class >> loaders >>> loading the interface org.apache.axis.attachments and the implementing >> class >>> org.apache.axis.attachments.AttachmentsImpl (bootloader and felix >>> classloader respectively). >>> >>> Your second solution makes no difference. >>> >>> I've also tried to use a bundleized version of commons-logging (from >>> Knopflerfish) and this gives almost the same result as your first > solution >>> although instead of a ClassCastException on AttechmentsImpl and >> Attachments, >>> I now get it on org.apache.axis.transport.http.HTTPSender (felix loader) >> and >>> org.apache.axis.Handler (bootloader). I feel this is strange since I'm > not >>> doing anything at all with the class loaders and yet the interfaces are >>> visible inside my bundle. >>> >>> Some new info also: >>> >>> 1. I've broken out all interesting parts into a new project to make it >>> easier to "debug". In this new project everything works just fine. I then >>> tried to include axis into the host ("main app", host of Felix) > classpath, >>> together with all the libs that axis depend upon (wsdl, jaxrpc and so > on). >>> Now, I get the HTTPSender--Handler ClassCastException. >>> >>> 2. I am using FileInstall to install and start new bundles. So, the host >> of >>> felix starts FileInstall by adding it to the list of host activators that >> is >>> sent to Felix' ctor. I do not think that this has any impact but I am not >>> that good on class loading so I'm just putting it out there in case I've >>> misunderstood something. All other bundles are thus started with the help >> of >>> FileInstall. As a further side note, FileInstall is included into the > host >>> class path (as a library) and started with >>> >>> FileInstall fi = new FileInstall(); >>> List list = new ArrayList(); >>> AutoActivator auto = new AutoActivator(); >>> >>> list.add(auto); >>> list.add(fi); >>> >>> felix = new Felix(configProps, list); >>> felix.start(); >>> >>> Can this be the source of felix classpath pollution? That I'm starting a >>> bundle (FileInstall) that is a library of the host? FileInstall (as a >> class) >>> is definitely loaded by a host classloader. If so, how am I supposed to >>> create host activators? I feel lost... :-) >>> >>> Thanks again for the replies! >>> >>> Regards >>> Per-Erik >>> >>> -----Ursprungligt meddelande----- >>> Från: Karl Pauls [mailto:[EMAIL PROTECTED] >>> Skickat: den 16 oktober 2008 10:39 >>> Till: [email protected] >>> Ämne: Re: commons-logging and Axis problems >>> >>> try setting the context classloader to the classloader of your bundle >>> before you make calls that use axis. >>> >>> ClassLoader tccl = Thread.currentThread().getContextClassLoader(); >>> try >>> { >>> >>> >> > Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader( >>> )); >>> // do stuff >>> } >>> finally >>> { >>> Thread.currentThread().setContextClassLoader(tccl); >>> } >>> >>> Alternatively, try to set the context classloader to null before you >>> create and start felix. >>> >>> Let us know whether that helps. >>> >>> regards, >>> >>> Karl >>> >>> On Thu, Oct 16, 2008 at 1:53 AM, Per-Erik Svensson >>> <[EMAIL PROTECTED]> wrote: >>>> Hi, >>>> >>>> >>>> >>>> I am using Felix (embedded-style) to create a small plug-in system to > our >>>> application. I have built a bundle using Apache Axis to connect to a >>>> webservice. The bundle registers with the main application (which of >>> course >>>> has started up Felix) and upon request from the main app calls the >>>> webservice and returns the results to the main app. (Basically.) The >>>> manifest of the bundle looks like this: >>>> >>>> >>>> >>>> Bundle-Name: A name >>>> >>>> Bundle-Description: A description >>>> >>>> Bundle-Vendor: 2c8 >>>> >>>> Bundle-Version: 1.0.0 >>>> >>>> Bundle-Activator: se.xxx.model.DocumentServiceImpl >>>> >>>> Import-Package: org.w3c.dom, javax.naming, javax.xml.parsers, >> org.xml.sax, >>>> se.conciliate.extensions.documentservice, org.osgi.framework >>>> >>>> Bundle-Classpath: ., jaxrpc.jar, axis.jar, commons-logging-1.0.4.jar, >>>> commons-discovery-0.2.jar >>>> >>>> >>>> >>>> Now, when the call from the main app tracks its way down to >>>> DocumentServiceImpl .someMethod(), an exception is thrown from Axis: >>>> >>>> >>>> >>>> java.lang.ExceptionInInitializerError >>>> >>>> at org.apache.axis.client.Service.getAxisClient(Service.java:104) >>>> >>>> at org.apache.axis.client.Service.<init>(Service.java:113) >>>> >>>> a couple of "at se.ourclasses." followed by >>>> >>>> >>>> >>>> Caused by: org.apache.commons.logging.LogConfigurationException: >>>> org.apache.commons.logging.LogConfigurationException: >>>> org.apache.commons.logging.LogConfigurationException: Invalid class >> loader >>>> hierarchy. You have more than one version of >>>> 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused >> by >>>> <same exception again*2>) >>>> >>>> >>>> >>>> This is the interesting parts of the stack trace (I think?). Apparently >>>> commons-logging does not like to have more than one instance of >>>> org.apache.commons.logging.Log visible on the class path. Problem is, > I'm >>>> not using it - Axis is. I've read about PaxLogging but I'm not sure how >> to >>>> make Axis use another logging facility. If anyone could help me to set > up >>> my >>>> (relatively small) bundle so that it can make the webservice calls it >>> needs >>>> to, I'd be very grateful! Or rather, if anyone could guide me through > how >>> to >>>> set up a bundle, that uses libraries, that need commons-logging. >>>> >>>> >>>> >>>> I should maybe mention also, that we use Axis for other purposes in our >>> main >>>> app. This must be where the other instance of >>> org.apache.commons.logging.Log >>>> is made visible?? (I don't export this from the system bundle however so >> I >>>> don't get how this can interfere. Isn't the osgi framework supposed to >>>> guarantee that a bundle only get exposed to one instance of each class, >> no >>>> matter how badly I as a developer screw things up?) >>>> >>>> >>>> >>>> Since commons-logging is used by many other Apache distributions this >> must >>>> be a somewhat frequent problem. I have not managed to find a solution >>> though >>>> so I hope that this isn't already answered in a thousand other places. >> All >>>> I've managed to find is that commons-logging is not suited to >> "bundleize". >>>> >>>> >>>> >>>> Please be kind if I've misunderstood something badly. I'm new to both >>> Felix >>>> and Axis (and don't know much about logging either). ;-) >>>> >>>> >>>> >>>> Regards, >>>> >>>> Per-Erik Svensson >>>> >>>> >>> >>> >>> >>> -- >>> Karl Pauls >>> [EMAIL PROTECTED] >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> >> -- >> Karl Pauls >> [EMAIL PROTECTED] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > Karl Pauls > [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Karl Pauls [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
