Hi Andy, Upgrading to the latest and greatest Jena versions fixed my problems.
Dunno if you still want to see my query? Both simple and complex queries works nicely again. Thanks for pointing me to this new release. Regards, Minto Op 18-9-2013 21:13, Andy Seaborne schreef: > Minto, > > What's the query that provokes this? > > This looks like JENA-471 which is fixed in 2.11.0 (which was released > today!) > > Andy > > > > > On 18/09/13 14:14, Minto van der Sluis wrote: >> 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
