stanbol-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suat Gonul <>
Subject Re: java.lang.LinkageError for
Date Thu, 08 Nov 2012 12:31:33 GMT
Hi Rupert,

Thanks for your reply.

The problem is that it's not my bundle. It is one of the Apache
Chemistry bundles i.e the OpenCMIS Client Bindings Implementation. So, I
cannot interfere in that. I think I should try to embed Chemistry
dependencies into my own module. If you have any other practical
solution, I would appreciate it.


On 11/8/2012 11:45 AM, Rupert Westenthaler wrote:
> Hi Suat,
> My experience is regarding the Java XML stuff it that there are two
> possibilities that do work
> (1) to embed everything in your bundle and exclude those packages from
> the imported
> (2) to import everything and embed nothing
> You should avoid
> * exporting XML stuff
> * use XML stuff in your interfaces (as this would require to export things)
> With the change from Solr 3.2 to 3.6.1 I decided to switch from (2) to
> (1) and because of that there are now bundles (from the ServiceMix
> project) that provide some of the XML libraries. The XML api, Xerxes
> and Xalan is anyway provided by the JDK. Because of that option (1)
> should be now fine for most of cases.
> The error you encounter seams to be related to two different instances
> of "javax/xml/stream/XMLStreamReader" Class loaded from different
> Classloaders. AFAIK this class is part of the Java XML apis so one
> guess is that your Bundle Classpath does include its own version for
> the Java XML apis. If this is the case you should get rid of the
> embedded dependency.
> An other possibility is that the bootloader instance is initialised by
> using the ContextClassloader and those is a different one as the
> BundleClassloader. If this is the case you need to replace the context
> classloader with the bundle classloader (you can find examples in the
> o.a.stanbol.commons.solr.core module as it needs to do the same when
> instantiating Solr components).
>> As far as I see both "Apache ServiceMix :: Specs :: Stax API 1.0" bundle
>> and our "frameworkfragment" injects the package into
>> the OSGi environment.
> Even that this is not the cause for your problem this is indeed an
> issue. AFAIK bundles that export packages should also import them,
> because then it does not interfere with packages exported by the
> system bundle (as it is the case because of the Stanbol
> frameworkfragment).
> best
> Rupert

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message