Hi Enrico Puzzling....The OSGi Samurais on the felix mailing list might be able to say more.....
Cheers, Reto On Thu, Dec 5, 2013 at 9:51 PM, enridaga <enrid...@apache.org> wrote: > 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 >
