You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Reto Bachmann-Gmür <re...@apache.org> on 2013/12/02 13:06:27 UTC
Re: SLF4J 1.6.1 and Jena 2.6.3 incompatibiliy
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?
Cheers,
Reto
On Wed, Nov 20, 2013 at 12:30 AM, enridaga <en...@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 <en...@apache.org> wrote:
>
>> Hi Reto,
>>
>>
>> On 19 November 2013 20:50, Reto Bachmann-Gmür <re...@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
>
Re: SLF4J 1.6.1 and Jena 2.6.3 incompatibiliy
Posted by enridaga <en...@apache.org>.
Hi Reto,
I'll drop an email there, then...
On 5 December 2013 21:00, Reto Bachmann-Gmür <re...@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 <en...@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 <en...@apache.org> wrote:
>>
>> > Hi Reto, all,
>> >
>> >
>> > On 2 December 2013 12:06, Reto Bachmann-Gmür <re...@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 <en...@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 <en...@apache.org> wrote:
>> >>>
>> >>>> Hi Reto,
>> >>>>
>> >>>>
>> >>>> On 19 November 2013 20:50, Reto Bachmann-Gmür <re...@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
Re: SLF4J 1.6.1 and Jena 2.6.3 incompatibiliy
Posted by Reto Bachmann-Gmür <re...@wymiwyg.com>.
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 <en...@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 <en...@apache.org> wrote:
>
> > Hi Reto, all,
> >
> >
> > On 2 December 2013 12:06, Reto Bachmann-Gmür <re...@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 <en...@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 <en...@apache.org> wrote:
> >>>
> >>>> Hi Reto,
> >>>>
> >>>>
> >>>> On 19 November 2013 20:50, Reto Bachmann-Gmür <re...@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
>
Re: SLF4J 1.6.1 and Jena 2.6.3 incompatibiliy
Posted by enridaga <en...@apache.org>.
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 <en...@apache.org> wrote:
> Hi Reto, all,
>
>
> On 2 December 2013 12:06, Reto Bachmann-Gmür <re...@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 <en...@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 <en...@apache.org> wrote:
>>>
>>>> Hi Reto,
>>>>
>>>>
>>>> On 19 November 2013 20:50, Reto Bachmann-Gmür <re...@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
Re: SLF4J 1.6.1 and Jena 2.6.3 incompatibiliy
Posted by enridaga <en...@apache.org>.
Hi Reto, all,
On 2 December 2013 12:06, Reto Bachmann-Gmür <re...@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 <en...@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 <en...@apache.org> wrote:
>>
>>> Hi Reto,
>>>
>>>
>>> On 19 November 2013 20:50, Reto Bachmann-Gmür <re...@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