Hi Minto, Reto,
IMO this is most likely not caused by incompatible version.
All XML related framework do use the context ClassLoader to
instantiate implementations of interfaces. The problem here is that
OSGI does not have any control over this ClassLoader. Meaning that the
Context Classloader is NOT the bundle ClassLoader. As long a the
context ClassLoader does not provide XML related stuff this is not a
problem as in such cases all such frameworks fall back to the "normal"
classloader. But if you run an embedded OSGI environment or your OSGI
environment runs within some Web-/Application container you will end
up in situations where the implementations loaded via the
ContextClassloader are no longer compatible with the Interfaces loaded
via the Bundle ClassLoader.
In such cases the implementation (e.g. the
"org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl") does not
implement the interface (e.g. javax.xml.datatype.DatatypeFactory) even
if there would be compatible versions of the API.
When I was working on the o.a.stanbol.commons.solr modules I needed to
solve a lot of those problems. The best solution is to use the XML
implementations provided by the JVM. To achieve this you need to add
requires packages to the framework fragment. This is the only
possibility to ensure that the context ClassLoader will provide
compatible (the exact same) classes as the Bundle ClassLoader.
If this is not possible (e.g. because the JVM does not provide
required packages) you will need to follow up such exceptions and
replace the ContextClassLoader with the BundleClassLoader with code
fragments like
ClassLoader classLoader = updateContextClassLoader();
try {
//your code
} finally {
Thread.currentThread().setContextClassLoader(classLoader);
}
private ClassLoader updateContextClassLoader() {
ClassLoader classLoader =
Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(CoreContainer.class.getClassLoader());
return classLoader;
}
However note that this is also not a perfect solution. Just search for
"OSGI Context ClassLoader" and you will find a lot more information
about this mess
best
Rupert
On Mon, Sep 16, 2013 at 4:03 PM, Reto Bachmann-Gmür <[email protected]> wrote:
> Having something leaner would be very much appreciated. Not sure what's
> causing the huge amount of dependencies.
>
> Cheers,
> Reto
>
>
> On Mon, Sep 16, 2013 at 3:55 PM, Minto van der Sluis <[email protected]> wrote:
>
>> Hi,
>>
>> Hmm, didn't work out as planned.
>>
>> Looking at the ext.* bundles I noticed something else. Why is the
>> wrapped bundle about 9M is since when the wrapped jar file only is about
>> 0.6M. Seems like too many dependencies are embedded inside. Is this
>> really needed? Looking inside the generated bundled I see stuff that is
>> wrapped elsewhere.
>>
>> Can't we be more like ServiceMix for ext.* bundles? See
>> http://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk/
>>
>> I will give it a try.
>>
>> Regards,
>>
>> Minto
>>
>>
>> Op 12-9-2013 8:21, Minto van der Sluis schreef:
>> > Then I will give it a try later today when meeting season is over.
>> >
>> > Regards,
>> >
>> > Minto
>> >
>> > Op 12-9-2013 7:16, Reto Bachmann-Gmür schreef:
>> >> On Wed, Sep 11, 2013 at 6:15 PM, Minto van der Sluis <[email protected]>
>> wrote:
>> >>
>> >>> Hi Folks,
>> >>>
>> >>> Anyone a clue how to solve the following error?
>> >>>
>> >>> ...
>> >>> Caused by: java.lang.ClassCastException:
>> >>> org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl cannot be cast to
>> >>> javax.xml.datatype.DatatypeFactory
>> >>> at javax.xml.datatype.DatatypeFactory.newInstance(Unknown
>> >>> Source)[:2.2.0]
>> >>> at
>> >>> com.hp.hpl.jena.tdb.store.DateTimeNode.<clinit>(DateTimeNode.java:83)
>> >>>
>> >>>
>> >>> It appear there are 3 bundles in my environment containing that class:
>> >>>
>> >>> karaf@root>osgi:find-class DatatypeFactoryImpl
>> >>>
>> >>> Apache ServiceMix :: Bundles :: saaj-impl (145)
>> >>>
>> >>>
>> com/sun/org/apache/xerces/internal/jaxp/datatype/DatatypeFactoryImpl.class
>> >>>
>> >>> Apache ServiceMix :: Bundles :: xercesImpl (146)
>> >>> org/apache/xerces/jaxp/datatype/DatatypeFactoryImpl.class
>> >>>
>> >>> Clerezza Ext - Jena TDB OSGi Bundle (199)
>> >>> org/apache/xerces/jaxp/datatype/DatatypeFactoryImpl.class
>> >>>
>> >>> The strange this is that everything worked well until I upgraded Karaf
>> >>> (2.3.0 --> 2.3.2) and CXF (2.7.3 --> 2.7.6). Downgrading Karaf again is
>> >>> not an option since I need a fix in the latest version. Downgrading CXF
>> >>> again yields the same result.
>> >>>
>> >>> Is it an option for ext:org.apache.jena.tdb bundle to use and external
>> >>> xerces bundle (from ServiceMix) instead of embedding xerces inside this
>> >>> clerezza bundle?
>> >>>
>> >> If this works (i.e. the servicemix bundle exports all xerces packages
>> >> needed by jena) this sound like the perfect solution.
>> >>
>> >> Cheers,
>> >> Reto
>> >>
>> >
>>
>>
>> --
>> ir. ing. Minto van der Sluis
>> Software innovator / renovator
>> Xup BV
>>
>> Mobiel: +31 (0) 626 014541
>>
>>
--
| Rupert Westenthaler [email protected]
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
