You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@clerezza.apache.org by Minto van der Sluis <mi...@xup.nl> on 2013/09/11 18:15:19 UTC
How to solve ClassCastException
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?
Regards,
Minto
Re: How to solve ClassCastException
Posted by Minto van der Sluis <mi...@xup.nl>.
Hi Rupert,
Thanks again for this insightful info.
See my remarks below.
Regards,
Minto
Op 18-9-2013 8:53, Rupert Westenthaler schreef:
> On Tue, Sep 17, 2013 at 2:54 PM, Minto van der Sluis <mi...@xup.nl> 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.
> Yes, this would be the way how to solve incompatibilities within OSGI.
> However note that your only run into such problems if A and B do
> export C via their public API. Does Jena really do this with Xerxes
> classes? AFAIK those are only used internally by literals to represent
> XML data types.
>
> So while embedding would still be not optimal because of bigger
> bundles and more classes loaded by the JVM you should not be able to
> run into conflicts like that.
I think you have a point here. I will check the exports section in the
bundle.
Still my proceedings might have led me to the origin of my worries. But
I am not sure yet
https://issues.apache.org/jira/browse/JENA-328
I will try to set the DatasetFactory to be used by using right properties as used by the jena code.
>> 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.
>>
> Have you cut of "caused by" parts from the stack trace? Searching for
> ARQInternalErrorException in Google gives some results that do point
> to XML datatype related origins. So IMO it is likely that this is
> caused by a similar issue as the original one. Especially if this was
> happening on a query that involved some typed literal.
No I have not cut of cause by section. This is exactly why the exception
was not very useful to me.
>
> Have you tried to run the JVM with the -verbose:class option. This
> information can be really helpful for debugging issues like that.
>
Yes I have. Eventually I switched to https://code.google.com/p/tamiflex/
Re: How to solve ClassCastException
Posted by Rupert Westenthaler <ru...@gmail.com>.
On Tue, Sep 17, 2013 at 2:54 PM, Minto van der Sluis <mi...@xup.nl> 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.
Yes, this would be the way how to solve incompatibilities within OSGI.
However note that your only run into such problems if A and B do
export C via their public API. Does Jena really do this with Xerxes
classes? AFAIK those are only used internally by literals to represent
XML data types.
So while embedding would still be not optimal because of bigger
bundles and more classes loaded by the JVM you should not be able to
run into conflicts like that.
>
> 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.
>
Have you cut of "caused by" parts from the stack trace? Searching for
ARQInternalErrorException in Google gives some results that do point
to XML datatype related origins. So IMO it is likely that this is
caused by a similar issue as the original one. Especially if this was
happening on a query that involved some typed literal.
Have you tried to run the JVM with the -verbose:class option. This
information can be really helpful for debugging issues like that.
best
Rupert
> 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 <re...@wymiwyg.com> 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 <mi...@xup.nl> 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 <mi...@xup.nl>
>>>> 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
>
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: How to solve ClassCastException
Posted by Reto Bachmann-Gmür <re...@apache.org>.
That's great news! Looking forward to the neat jena modules! I assume this
will also get around the big duplication in our jena and jena-tdb bundles.
Cheers,
Reto
On Thu, Sep 19, 2013 at 11:36 AM, Minto van der Sluis <mi...@xup.nl> wrote:
> 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
> >>>>> <re...@wymiwyg.com> 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 <mi...@xup.nl>
> >>>>>> 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
> >>>>>>>>> <mi...@xup.nl>
> >>>>>>> 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
>
>
Re: How to solve ClassCastException
Posted by Minto van der Sluis <mi...@xup.nl>.
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
>>>>> <re...@wymiwyg.com> 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 <mi...@xup.nl>
>>>>>> 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
>>>>>>>>> <mi...@xup.nl>
>>>>>>> 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
Re: How to solve ClassCastException
Posted by Andy Seaborne <an...@apache.org>.
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
>>>> <re...@wymiwyg.com> 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 <mi...@xup.nl>
>>>>> 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 <mi...@xup.nl>
>>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
Re: How to solve ClassCastException
Posted by Minto van der Sluis <mi...@xup.nl>.
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
>>> <re...@wymiwyg.com> 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 <mi...@xup.nl>
>>>> 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 <mi...@xup.nl>
>>>>> 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
Re: How to solve ClassCastException
Posted by Andy Seaborne <an...@apache.org>.
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 <re...@wymiwyg.com> 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 <mi...@xup.nl> 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 <mi...@xup.nl>
>>>> 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
>>>>
>>>>
>>
>>
>
>
Re: How to solve ClassCastException
Posted by Minto van der Sluis <mi...@xup.nl>.
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 <re...@wymiwyg.com> 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 <mi...@xup.nl> 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 <mi...@xup.nl>
>>> 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
Re: How to solve ClassCastException
Posted by Rupert Westenthaler <ru...@gmail.com>.
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 <re...@wymiwyg.com> 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 <mi...@xup.nl> 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 <mi...@xup.nl>
>> 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 rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: How to solve ClassCastException
Posted by Reto Bachmann-Gmür <re...@wymiwyg.com>.
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 <mi...@xup.nl> 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 <mi...@xup.nl>
> 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
>
>
Re: How to solve ClassCastException
Posted by Minto van der Sluis <mi...@xup.nl>.
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 <mi...@xup.nl> 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
Re: How to solve ClassCastException
Posted by Minto van der Sluis <mi...@xup.nl>.
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 <mi...@xup.nl> 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
Re: How to solve ClassCastException
Posted by Reto Bachmann-Gmür <re...@apache.org>.
On Wed, Sep 11, 2013 at 6:15 PM, Minto van der Sluis <mi...@xup.nl> 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