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]
