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: users@felix.apache.org
Ä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]

Reply via email to