Hi Andy,
It's a local change with:
jena-core 2.10.1
jena-arq 2.10.1
jena-tdb 0.10.1
jena-iri 0.9.6
These changes are with lean OSGI wrappers around the jena jar files. One
wrapper per jar using the Apache ServiceMix style of wrapping.
Looking at Jena sources I was thinking that it might be related to
dynamic class loading (using classloader forName). During my quest of
finding out which classes are binding loaded dynamically I stubles
across https://issues.apache.org/jira/browse/JENA-328. This issues seems
to be related to my initial problem (DataTypeFactory class cast exception).
Still I like to invest some more time in the ServiceMix style wrappers
since it looks cleaner and less bulky than what Clerezza currently has.
Currently I am looking into which classes have all been loaded (using
https://code.google.com/p/tamiflex/ ). Unfortunately it doesn't tell
which classes could NOT be loaded.
Regards,
MInto
Op 18-9-2013 12:00, Andy Seaborne schreef:
> 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
>>>>>
>>>>>
>>>
>>>
>>
>>
>
>
>
--
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV
Mobiel: +31 (0) 626 014541
