Minto,
What are the versions here because when I look at the Clerezza pom I see
TDB 0.10.0 + ARQ 2.10.0 but the stacktrace does not align at OpVars line
197. I can't ATM see a version where it does throw
ARQInternalErrorException (although, from memory, there was bug
somewhere round here quite some time ago).
Andy
On 17/09/13 13:54, Minto van der Sluis wrote:
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
