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 <[email protected]> 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/
