Hi, I just did some more analysis... I monitored the class loading from the jvm output (using the divine -verbose:class option). When I call a service, these classes from commons logging are loaded:
[Loaded org.apache.commons.logging.Log from slinginstall:jcl-over-slf4j-1.6.6.jar] [Loaded org.apache.commons.logging.impl.NoOpLog from slinginstall:jcl-over-slf4j-1.6.6.jar] [Loaded org.apache.commons.logging.impl.SimpleLog$1 from slinginstall:jcl-over-slf4j-1.6.6.jar] [Loaded org.apache.commons.logging.impl.SimpleLog from slinginstall:jcl-over-slf4j-1.6.6.jar] [Loaded org.apache.commons.logging.impl.SLF4JLocationAwareLog from slinginstall:jcl-over-slf4j-1.6.6.jar] [Loaded org.apache.commons.logging.impl.SLF4JLog from slinginstall:jcl-over-slf4j-1.6.6.jar] [Loaded org.apache.commons.logging.LogFactory from slinginstall:jcl-over-slf4j-1.6.6.jar] [Loaded org.apache.commons.logging.impl.SLF4JLogFactory from slinginstall:jcl-over-slf4j-1.6.6.jar] [Loaded org.apache.commons.logging.LogConfigurationException from slinginstall:jcl-over-slf4j-1.6.6.jar] But then these are loaded the first time I refer to RIOT in my code, i.e. doing model.read(url) : [Loaded org.apache.commons.logging.LogFactory from slinginstall:org.apache.jena.tdb-0.4-SNAPSHOT.jar] [Loaded org.apache.commons.logging.impl.SLF4JLogFactory from slinginstall:org.apache.jena.tdb-0.4-SNAPSHOT.jar] [Loaded org.apache.commons.logging.Log from slinginstall:org.apache.jena.tdb-0.4-SNAPSHOT.jar] [Loaded org.apache.commons.logging.impl.SLF4JLocationAwareLog from slinginstall:org.apache.jena.tdb-0.4-SNAPSHOT.jar] [Loaded org.apache.commons.logging.impl.SLF4JLog from slinginstall:org.apache.jena.tdb-0.4-SNAPSHOT.jar] I am not really an osgi samurai, but as far as I know the code is executed from the reasoners.web class loader, so I don’t understand why these classes are loaded *again* from the clerezza/tdb bundle (without this being visible from the osgi console!). Why my class loader does not simply receive the OSGi shared versions? FWIW org.apache.jena.tdb-0.4-SNAPSHOT does not export org.apache.commons.logging. The only way I was able to make it work is to not use RIOT to read from remotely, but implement my own http resolver. But more than this, I want to understand how this stuff is behaving like that! Bests, Enrico On 5 December 2013 20:47, enridaga <enrid...@apache.org> wrote: > Hi Reto, all, > > > On 2 December 2013 12:06, Reto Bachmann-Gmür <r...@apache.org> wrote: > >> Hi Enrico >> >> Just to make sure I understand: You upgraded to the latest clerezza.ext >> jena bundles and are having the same exception you had in the first place? >> > I am just working at stanbol trunk, the reasoners/web artifact do not > explicitly refer to clerezza.ext, the osgi bundle imports jena (it has a > ugly * in the actual version in svn, but cleaning it up doesn't improve). > > Cheers > Enrico > > >> Cheers, >> Reto >> >> >> On Wed, Nov 20, 2013 at 12:30 AM, enridaga <enrid...@apache.org> wrote: >> >>> Hi, >>> I write down some notes even if I don't see much progress... >>> >>> I followed the stack trace step by step looking at bundles that provide >>> the packages (from the Felix Packages tool), here is the sequence: >>> >>> org.apache.commons.logging.impl.SLF4JLogFactory => >>> org.slf4j:jcl.over.slf4j 1.6.6 >>> org.apache.http => org.apache.httpcomponents:httpcore-nio >>> org.apache.jena => org.apache.clerezza.ext:org.apache.jena.tdb >>> com.hp.hpl.jena => org.apache.clerezza.ext:org.apache.jena.tdb >>> org.apache.stanbol.reasoners.web => I know this... >>> >>> then org.apache.stanbol.reasoners.web when there is the code I know that >>> is calling a method from Jena to load a resource from http. >>> But this only shows where packages should be kept from, not which is >>> actually the origin of the ones loaded in the current classpath, that deal >>> to the exception. >>> >>> I also noticed that has a set of jars embedded in the classpath, >>> including jcl-over-slf4j-1.6.4.jar , but this is not exported so I can't >>> see how it should affect my classpath. >>> >>> I am stuck here, for the moment. >>> >>> Enrico >>> >>> >>> >>> >>> >>> On 19 November 2013 20:59, enridaga <enrid...@apache.org> wrote: >>> >>>> Hi Reto, >>>> >>>> >>>> On 19 November 2013 20:50, Reto Bachmann-Gmür <r...@wymiwyg.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> FWIW, it looks like we have two options here: >>>>> >>>>>> 1) Upgrade jena to 2.11.0 . This would be something to do at some >>>>>> point. >>>>>> Unfortunately this implies switch the dependencies to the >>>>>> org.apache.* one. >>>>>> Package names should be the same - not 100% sure. >>>>>> >>>>> In Clerezza the switch was quite painless. Also in fusepool we are >>>>> using jena 2.11 and tdb 1.0 and had no issues with the Stanbol components >>>>> used. >>>>> >>>> This is promising. I would fix the problem with the Reasoners services >>>> first, then we may want to discuss the upgrade of Jena, of course. >>>> >>>> Enrico >>>> >>>> >>>>> Cheers, >>>>> Reto >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> ------------------------------------------------------------------------------ >>>> enridaga >>>> >>> >>> >>> >>> -- >>> >>> ------------------------------------------------------------------------------ >>> enridaga >>> >> >> > > > -- > > ------------------------------------------------------------------------------ > enridaga > -- ------------------------------------------------------------------------------ enridaga
