Hi Reto, I'll drop an email there, then...
On 5 December 2013 21:00, Reto Bachmann-Gmür <r...@wymiwyg.com> wrote: > 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 >> > > -- ------------------------------------------------------------------------------ enridaga
