Thanks Rupert for you detailed insight.
But I am wondering if 2 bundles A and B both embed the same class C.
Then my understanding of OSGI is that A.C and B.C are not compatible
because both are loaded by different class loaders. Couldn't this be
solved by having A and B import C and adding a bundle D to export C.
This is exactly what I am trying to achieve by making the Clerezza jena
based ext bundles leaner.
Thus far I managed to create lean bundles the Apache ServiceMix way for
the following Jena components:
jena-core
jena-arq
jena-iri
jena-tdb
Using these in my environment enables me to start Karaf en store XML/RDF
in a tdb triple store. A few additional tests showed that both simple
queries and retrieving all triples in a graph worked well. So far so good.
Unfortunately trying a more complex query resulted in a jena
ARQInternalErrorException. See the stacktrace below. Unfortunately the
exception and the jena source code leaves me clueless about the exact
cause. I suspect it is caused by dynamically loading classes not
available to the jena-arq bundle. I could add them if only I knew what
is missing.
Anyone a clue? I think about cross-posting part of this on the jena
mailing list as well.
Regards,
Minto
Stacktrace:
=========
2013-09-17 14:34:41,142 | ERROR | l Console Thread |
AnnotationStoreServiceImpl | .impl.AnnotationStoreServiceImpl 310
| 206 - astore-engine-impl - 0.7.1.35 | failure
com.hp.hpl.jena.sparql.ARQInternalErrorException
at
com.hp.hpl.jena.sparql.algebra.OpVars$OpVarsPattern.visit(OpVars.java:197)
at com.hp.hpl.jena.sparql.algebra.op.OpProject.visit(OpProject.java:48)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:86)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visitModifer(OpVisitorByType.java:42)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:154)
at com.hp.hpl.jena.sparql.algebra.op.OpProject.visit(OpProject.java:48)
at com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:43)
at com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:33)
at com.hp.hpl.jena.sparql.algebra.OpVars.mentionedVars(OpVars.java:70)
at com.hp.hpl.jena.sparql.algebra.OpVars.mentionedVars(OpVars.java:62)
at
com.hp.hpl.jena.sparql.algebra.AlgebraQuad$Pusher.visit(AlgebraQuad.java:93)
at com.hp.hpl.jena.sparql.algebra.op.OpGraph.visit(OpGraph.java:46)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.before(OpWalker.java:64)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:84)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:110)
at com.hp.hpl.jena.sparql.algebra.op.OpGraph.visit(OpGraph.java:46)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visitN(OpWalker.java:113)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:78)
at
com.hp.hpl.jena.sparql.algebra.op.OpSequence.visit(OpSequence.java:75)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:85)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visitModifer(OpVisitorByType.java:42)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:154)
at com.hp.hpl.jena.sparql.algebra.op.OpProject.visit(OpProject.java:48)
at
com.hp.hpl.jena.sparql.algebra.OpWalker$WalkerVisitor.visit1(OpWalker.java:85)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visitModifer(OpVisitorByType.java:42)
at
com.hp.hpl.jena.sparql.algebra.OpVisitorByType.visit(OpVisitorByType.java:166)
at com.hp.hpl.jena.sparql.algebra.op.OpSlice.visit(OpSlice.java:50)
at com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:43)
at com.hp.hpl.jena.sparql.algebra.OpWalker.walk(OpWalker.java:38)
at
com.hp.hpl.jena.sparql.algebra.Transformer.applyTransformation(Transformer.java:156)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transformation(Transformer.java:149)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transformation(Transformer.java:138)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transformation(Transformer.java:132)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transform(Transformer.java:57)
at
com.hp.hpl.jena.sparql.algebra.Transformer.transformSkipService(Transformer.java:87)
at
com.hp.hpl.jena.sparql.algebra.AlgebraQuad.quadize(AlgebraQuad.java:56)
at com.hp.hpl.jena.sparql.algebra.Algebra.toQuadForm(Algebra.java:89)
at
com.hp.hpl.jena.tdb.solver.QueryEngineTDB.modifyOp(QueryEngineTDB.java:92)
at
com.hp.hpl.jena.sparql.engine.QueryEngineBase.createPlan(QueryEngineBase.java:94)
at
com.hp.hpl.jena.sparql.engine.QueryEngineBase.getPlan(QueryEngineBase.java:87)
at
com.hp.hpl.jena.tdb.solver.QueryEngineTDB$QueryEngineFactoryTDB.create(QueryEngineTDB.java:174)
at
com.hp.hpl.jena.sparql.engine.QueryExecutionBase.getPlan(QueryExecutionBase.java:554)
at
com.hp.hpl.jena.sparql.engine.QueryExecutionBase.startQueryIterator(QueryExecutionBase.java:498)
at
com.hp.hpl.jena.sparql.engine.QueryExecutionBase.execResultSet(QueryExecutionBase.java:539)
at
com.hp.hpl.jena.sparql.engine.QueryExecutionBase.execSelect(QueryExecutionBase.java:197)
at
org.apache.clerezza.rdf.jena.tdb.storage.BaseTdbTcProvider.executeSparqlQuery(BaseTdbTcProvider.java:52)
at
org.apache.clerezza.rdf.jena.tdb.storage.SingleTdbDatasetTcProvider.executeSparqlQuery(SingleTdbDatasetTcProvider.java:81)
at
org.apache.clerezza.rdf.core.access.TcManager.executeSparqlQuery(TcManager.java:324)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)[:1.7.0_17]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_17]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_17]
at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_17]
at
org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:54)[10:org.apache.aries.proxy.impl:1.0.1]
at
org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:119)[10:org.apache.aries.proxy.impl:1.0.1]
at
org.apache.clerezza.rdf.core.access.$TcManager1609931491.executeSparqlQuery(Unknown
Source)[180:org.apache.clerezza.rdf.core:0.14.0.SNAPSHOT]
at
nl.overheid.stelsel.digimelding.astore.storage.clerezza.ClerezzaStorageProvider.query(ClerezzaStorageProvider.java:245)[208:astore-storage-clerezza:0.7.1.35]
at Proxy389e09fd_5ff3_480f_9651_e555d38ae923.query(Unknown Source)[:]
at
nl.overheid.stelsel.digimelding.astore.impl.managers.StorageManager.query(StorageManager.java:172)[206:astore-engine-impl:0.7.1.35]
at
nl.overheid.stelsel.digimelding.astore.impl.managers.StorageManager.namedQuery(StorageManager.java:156)[206:astore-engine-impl:0.7.1.35]
at
nl.overheid.stelsel.digimelding.astore.impl.AnnotationStoreServiceImpl.internalNamedQuery(AnnotationStoreServiceImpl.java:293)[206:astore-engine-impl:0.7.1.35]
at
nl.overheid.stelsel.digimelding.astore.impl.AnnotationStoreServiceImpl.namedQuery(AnnotationStoreServiceImpl.java:163)[206:astore-engine-impl:0.7.1.35]
at
nl.overheid.stelsel.digimelding.astore.impl.AnnotationStoreServiceImpl.namedQuery(AnnotationStoreServiceImpl.java:153)[206:astore-engine-impl:0.7.1.35]
at Proxyd9d54baf_dd67_46cc_8a1a_858502a9f987.namedQuery(Unknown
Source)[:]
at
nl.overheid.stelsel.digimelding.astore.core.commands.NamedQueryAnnotationCommand.executeCommand(NamedQueryAnnotationCommand.java:87)[207:astore-engine-commands:0.7.1.35]
at
nl.overheid.stelsel.digimelding.astore.core.commands.NamedQueryAnnotationCommand.doExecute(NamedQueryAnnotationCommand.java:48)[207:astore-engine-commands:0.7.1.35]
at
org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[14:org.apache.karaf.shell.console:2.3.2]
at
org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[14:org.apache.karaf.shell.console:2.3.2]
at
org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[14:org.apache.karaf.shell.console:2.3.2]
at
org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:474)[14:org.apache.karaf.shell.console:2.3.2]
at
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:400)[14:org.apache.karaf.shell.console:2.3.2]
at
org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[14:org.apache.karaf.shell.console:2.3.2]
at
org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[14:org.apache.karaf.shell.console:2.3.2]
at
org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[14:org.apache.karaf.shell.console:2.3.2]
at
org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)[14:org.apache.karaf.shell.console:2.3.2]
at
org.apache.karaf.shell.console.jline.Console.run(Console.java:173)[14:org.apache.karaf.shell.console:2.3.2]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_17]
Op 17-9-2013 9:49, Rupert Westenthaler schreef:
> 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
>>>
>>>
>
>
--
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV
Mobiel: +31 (0) 626 014541
