You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by enridaga <en...@apache.org> on 2013/11/10 20:11:51 UTC
SLF4J 1.6.1 and Jena 2.6.3 incompatibiliy
Hi all,
Working on STANBOL-1174, I am having the following exception from a
stanbol-reasoners JAX-RS resource (cropped stack trace):
10.11.2013 17:55:05.757 *WARN* [qtp362287566-27]
org.eclipse.jetty.servlet.ServletHandler /reasoners/rdfs/classify
org.glassfish.jersey.server.ContainerException:
java.lang.NoClassDefFoundError: org/slf4j/spi/LocationAwareLogger
at
org.glassfish.jersey.servlet.internal.ResponseWriter.rethrow(ResponseWriter.java:230
...
at org.apache.jena.riot.web.HttpOp.ensureClient(HttpOp.java:1044)
...
at com.hp.hpl.jena.rdf.model.impl.ModelCom.read(ModelCom.java:229)
...
at
org.apache.stanbol.reasoners.web.input.provider.impl.UrlInputProvider.getInput(UrlInputProvider.java:105)
...
After a short inspection, I found that the dependency com.hp.hpl.jena-2.6.3
depends on slf4j-1.5.8 [1] which is incompatible with slf4j-1.6.1 [2],
which we use as reference version [3].
Clerezza trunk is using Jena 2.11, so maybe our situation is temporary?
Should we migrate to a more recent version of Jena soon?
If we cannot do it soon, does anybody know a temporary fix?
Cheers,
Enrico
[1] http://repo1.maven.org/maven2/com/hp/hpl/jena/jena/2.6.3/jena-2.6.3.pom
[2]
http://upstream-tracker.org/java/compat_reports/slf4j/1.5.11_to_1.6.0/bin_compat_report.html
[3] http://svn.apache.org/repos/asf/stanbol/trunk/parent/pom.xml
--
------------------------------------------------------------------------------
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
Re: SLF4J 1.6.1 and Jena 2.6.3 incompatibiliy
Posted by Reto Bachmann-Gmür <re...@apache.org>.
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,
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,
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
Re: SLF4J 1.6.1 and Jena 2.6.3 incompatibiliy
Posted by Reto Bachmann-Gmür <re...@wymiwyg.com>.
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.
Cheers,
Reto
Re: SLF4J 1.6.1 and Jena 2.6.3 incompatibiliy
Posted by enridaga <en...@apache.org>.
Hi Rupert,
actually you may be right and I may be deviated by finding the
documentation I mentioned in the earlier emails.
Will look into this.
thank you,
Enrico
On 19 November 2013 13:41, Rupert Westenthaler <
rupert.westenthaler@gmail.com> wrote:
> Hi Enrico
>
> The stack suggests that Jena RIOT calls the apache HTTP client. The
> HTTP client Apache uses commons logging for logging. In this case not
> the original one, but the adapter for SLF4J - log4j-over-slf4j) - see
> LogFactory.getLog(..) calling SLF4JLogFactory.
>
> So IMO this is caused by the version of the "slf4j-api" being
> incompatible with the version of the "log4j-over-slf4j". So to solve
> this you will need to find out how the outdated "log4j-over-slf4j"
> comes into your classpath and replace it with one that is compatible
> to the "slf4j-api" used by the OSGI environment.
>
> best
> Rupert
>
> On Tue, Nov 19, 2013 at 11:56 AM, enridaga <en...@apache.org> wrote:
> > Unfortunately option 2) is less easy as expected. While the code compiles
> > (even without tests because of some formatters missing in 1.5.8),
> changing
> > the version at runtime is less straightforward, since the version used at
> > runtime by Felix is 1.6.6 and this is surely a constraint.
> >
> > (Again, I am not sure that the problem is related to slf4j version
> > conflict, it is just the only hypothesis I have at the moment)
> >
> > Just as reference, here is a longer stacktrace of my exception:
> >
> > Caused by: java.lang.NoClassDefFoundError:
> org/slf4j/spi/LocationAwareLogger
> > at
> >
> org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:157)
> > at
> >
> org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:132)
> > at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:272)
> > at
> >
> org.apache.http.impl.client.AbstractHttpClient.<init>(AbstractHttpClient.java:187)
> > at
> >
> org.apache.http.impl.client.DefaultHttpClient.<init>(DefaultHttpClient.java:127)
> > at
> >
> org.apache.http.impl.client.SystemDefaultHttpClient.<init>(SystemDefaultHttpClient.java:113)
> > at org.apache.jena.riot.web.HttpOp.ensureClient(HttpOp.java:1044)
> > at org.apache.jena.riot.web.HttpOp.exec(HttpOp.java:1008)
> > at org.apache.jena.riot.web.HttpOp.execHttpGet(HttpOp.java:291)
> > at org.apache.jena.riot.web.HttpOp.execHttpGet(HttpOp.java:326)
> > at org.apache.jena.riot.stream.LocatorURL.open(LocatorURL.java:46)
> > at
> >
> org.apache.jena.riot.stream.StreamManager.openNoMapOrNull(StreamManager.java:138)
> > at org.apache.jena.riot.stream.StreamManager.open(StreamManager.java:99)
> > at org.apache.jena.riot.RDFDataMgr.open(RDFDataMgr.java:783)
> > at org.apache.jena.riot.RDFDataMgr.open(RDFDataMgr.java:772)
> > at org.apache.jena.riot.RDFDataMgr.parse(RDFDataMgr.java:676)
> > at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:211)
> > at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:184)
> > at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:122)
> > at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:113)
> > at
> org.apache.jena.riot.adapters.RDFReaderRIOT.read(RDFReaderRIOT.java:77)
> > at com.hp.hpl.jena.rdf.model.impl.ModelCom.read(ModelCom.java:229)
> > at
> >
> com.hp.hpl.jena.ontology.impl.OntModelImpl.readDelegate(OntModelImpl.java:3107)
> > at
> com.hp.hpl.jena.ontology.impl.OntModelImpl.read(OntModelImpl.java:2198)
> > at
> com.hp.hpl.jena.ontology.impl.OntModelImpl.read(OntModelImpl.java:2122)
> > at
> >
> org.apache.stanbol.reasoners.web.input.provider.impl.UrlInputProvider.getInput(UrlInputProvider.java:105)
> > at
> >
> org.apache.stanbol.reasoners.web.input.impl.SimpleInputManager$1.nextProvider(SimpleInputManager.java:97)
> > at
> >
> org.apache.stanbol.reasoners.web.input.impl.SimpleInputManager$1.hasNext(SimpleInputManager.java:123)
> > at
> >
> org.apache.stanbol.reasoners.web.utils.ReasoningServiceExecutor.execute(ReasoningServiceExecutor.java:320)
> > at
> >
> org.apache.stanbol.reasoners.web.utils.ReasoningServiceExecutor.call(ReasoningServiceExecutor.java:385)
> > at
> >
> org.apache.stanbol.reasoners.web.resources.ReasoningServiceTaskResource.processRealTimeRequest(ReasoningServiceTaskResource.java:348)
> > at
> >
> org.apache.stanbol.reasoners.web.resources.ReasoningServiceTaskResource.processRequest(ReasoningServiceTaskResource.java:274)
> > at
> >
> org.apache.stanbol.reasoners.web.resources.ReasoningServiceTaskResource.get(ReasoningServiceTaskResource.java:295)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:597)
> > at
> >
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> > at
> >
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:140)
> > at
> >
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:158)
> > at
> >
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
> > at
> >
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:101)
> > at
> >
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:353)
> > at
> >
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:343)
> > at
> >
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
> > at
> org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:237)
> > ... 62 more
> >
> >
> >
> >
> > On 19 November 2013 10:01, enridaga <en...@apache.org> wrote:
> >
> >> Hi again,
> >> 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.
> >> 2) Downgrade slf4j to 1.5.8 and plane the jena upgrade for a future
> >> iteration. Is there a special reason why we need 1.6.1 *now*?
> >>
> >> The first may be more time consuming because would affect probably a
> large
> >> part of the codebase.
> >> I will try to do the second and see what happens.
> >>
> >> Again, if someone else has some ideas on this is welcome.
> >>
> >> Bests,
> >> Enrico
> >>
> >>
> >> On 10 November 2013 19:11, enridaga <en...@apache.org> wrote:
> >>
> >>> Hi all,
> >>>
> >>> Working on STANBOL-1174, I am having the following exception from a
> >>> stanbol-reasoners JAX-RS resource (cropped stack trace):
> >>>
> >>> 10.11.2013 17:55:05.757 *WARN* [qtp362287566-27]
> >>> org.eclipse.jetty.servlet.ServletHandler /reasoners/rdfs/classify
> >>> org.glassfish.jersey.server.ContainerException:
> >>> java.lang.NoClassDefFoundError: org/slf4j/spi/LocationAwareLogger
> >>> at
> >>>
> org.glassfish.jersey.servlet.internal.ResponseWriter.rethrow(ResponseWriter.java:230
> >>> ...
> >>> at org.apache.jena.riot.web.HttpOp.ensureClient(HttpOp.java:1044)
> >>> ...
> >>> at com.hp.hpl.jena.rdf.model.impl.ModelCom.read(ModelCom.java:229)
> >>> ...
> >>> at
> >>>
> org.apache.stanbol.reasoners.web.input.provider.impl.UrlInputProvider.getInput(UrlInputProvider.java:105)
> >>> ...
> >>>
> >>> After a short inspection, I found that the dependency
> >>> com.hp.hpl.jena-2.6.3 depends on slf4j-1.5.8 [1] which is incompatible
> with
> >>> slf4j-1.6.1 [2], which we use as reference version [3].
> >>> Clerezza trunk is using Jena 2.11, so maybe our situation is temporary?
> >>> Should we migrate to a more recent version of Jena soon?
> >>> If we cannot do it soon, does anybody know a temporary fix?
> >>>
> >>> Cheers,
> >>> Enrico
> >>>
> >>>
> >>> [1]
> >>>
> http://repo1.maven.org/maven2/com/hp/hpl/jena/jena/2.6.3/jena-2.6.3.pom
> >>> [2]
> >>>
> http://upstream-tracker.org/java/compat_reports/slf4j/1.5.11_to_1.6.0/bin_compat_report.html
> >>> [3] http://svn.apache.org/repos/asf/stanbol/trunk/parent/pom.xml
> >>>
> >>> --
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> enridaga
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >>
> ------------------------------------------------------------------------------
> >> enridaga
> >>
> >
> >
> >
> > --
> >
> ------------------------------------------------------------------------------
> > enridaga
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
>
--
------------------------------------------------------------------------------
enridaga
Re: SLF4J 1.6.1 and Jena 2.6.3 incompatibiliy
Posted by Rupert Westenthaler <ru...@gmail.com>.
Hi Enrico
The stack suggests that Jena RIOT calls the apache HTTP client. The
HTTP client Apache uses commons logging for logging. In this case not
the original one, but the adapter for SLF4J - log4j-over-slf4j) - see
LogFactory.getLog(..) calling SLF4JLogFactory.
So IMO this is caused by the version of the "slf4j-api" being
incompatible with the version of the "log4j-over-slf4j". So to solve
this you will need to find out how the outdated "log4j-over-slf4j"
comes into your classpath and replace it with one that is compatible
to the "slf4j-api" used by the OSGI environment.
best
Rupert
On Tue, Nov 19, 2013 at 11:56 AM, enridaga <en...@apache.org> wrote:
> Unfortunately option 2) is less easy as expected. While the code compiles
> (even without tests because of some formatters missing in 1.5.8), changing
> the version at runtime is less straightforward, since the version used at
> runtime by Felix is 1.6.6 and this is surely a constraint.
>
> (Again, I am not sure that the problem is related to slf4j version
> conflict, it is just the only hypothesis I have at the moment)
>
> Just as reference, here is a longer stacktrace of my exception:
>
> Caused by: java.lang.NoClassDefFoundError: org/slf4j/spi/LocationAwareLogger
> at
> org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:157)
> at
> org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:132)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:272)
> at
> org.apache.http.impl.client.AbstractHttpClient.<init>(AbstractHttpClient.java:187)
> at
> org.apache.http.impl.client.DefaultHttpClient.<init>(DefaultHttpClient.java:127)
> at
> org.apache.http.impl.client.SystemDefaultHttpClient.<init>(SystemDefaultHttpClient.java:113)
> at org.apache.jena.riot.web.HttpOp.ensureClient(HttpOp.java:1044)
> at org.apache.jena.riot.web.HttpOp.exec(HttpOp.java:1008)
> at org.apache.jena.riot.web.HttpOp.execHttpGet(HttpOp.java:291)
> at org.apache.jena.riot.web.HttpOp.execHttpGet(HttpOp.java:326)
> at org.apache.jena.riot.stream.LocatorURL.open(LocatorURL.java:46)
> at
> org.apache.jena.riot.stream.StreamManager.openNoMapOrNull(StreamManager.java:138)
> at org.apache.jena.riot.stream.StreamManager.open(StreamManager.java:99)
> at org.apache.jena.riot.RDFDataMgr.open(RDFDataMgr.java:783)
> at org.apache.jena.riot.RDFDataMgr.open(RDFDataMgr.java:772)
> at org.apache.jena.riot.RDFDataMgr.parse(RDFDataMgr.java:676)
> at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:211)
> at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:184)
> at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:122)
> at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:113)
> at org.apache.jena.riot.adapters.RDFReaderRIOT.read(RDFReaderRIOT.java:77)
> at com.hp.hpl.jena.rdf.model.impl.ModelCom.read(ModelCom.java:229)
> at
> com.hp.hpl.jena.ontology.impl.OntModelImpl.readDelegate(OntModelImpl.java:3107)
> at com.hp.hpl.jena.ontology.impl.OntModelImpl.read(OntModelImpl.java:2198)
> at com.hp.hpl.jena.ontology.impl.OntModelImpl.read(OntModelImpl.java:2122)
> at
> org.apache.stanbol.reasoners.web.input.provider.impl.UrlInputProvider.getInput(UrlInputProvider.java:105)
> at
> org.apache.stanbol.reasoners.web.input.impl.SimpleInputManager$1.nextProvider(SimpleInputManager.java:97)
> at
> org.apache.stanbol.reasoners.web.input.impl.SimpleInputManager$1.hasNext(SimpleInputManager.java:123)
> at
> org.apache.stanbol.reasoners.web.utils.ReasoningServiceExecutor.execute(ReasoningServiceExecutor.java:320)
> at
> org.apache.stanbol.reasoners.web.utils.ReasoningServiceExecutor.call(ReasoningServiceExecutor.java:385)
> at
> org.apache.stanbol.reasoners.web.resources.ReasoningServiceTaskResource.processRealTimeRequest(ReasoningServiceTaskResource.java:348)
> at
> org.apache.stanbol.reasoners.web.resources.ReasoningServiceTaskResource.processRequest(ReasoningServiceTaskResource.java:274)
> at
> org.apache.stanbol.reasoners.web.resources.ReasoningServiceTaskResource.get(ReasoningServiceTaskResource.java:295)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:140)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:158)
> at
> org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:101)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:353)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:343)
> at
> org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
> at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:237)
> ... 62 more
>
>
>
>
> On 19 November 2013 10:01, enridaga <en...@apache.org> wrote:
>
>> Hi again,
>> 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.
>> 2) Downgrade slf4j to 1.5.8 and plane the jena upgrade for a future
>> iteration. Is there a special reason why we need 1.6.1 *now*?
>>
>> The first may be more time consuming because would affect probably a large
>> part of the codebase.
>> I will try to do the second and see what happens.
>>
>> Again, if someone else has some ideas on this is welcome.
>>
>> Bests,
>> Enrico
>>
>>
>> On 10 November 2013 19:11, enridaga <en...@apache.org> wrote:
>>
>>> Hi all,
>>>
>>> Working on STANBOL-1174, I am having the following exception from a
>>> stanbol-reasoners JAX-RS resource (cropped stack trace):
>>>
>>> 10.11.2013 17:55:05.757 *WARN* [qtp362287566-27]
>>> org.eclipse.jetty.servlet.ServletHandler /reasoners/rdfs/classify
>>> org.glassfish.jersey.server.ContainerException:
>>> java.lang.NoClassDefFoundError: org/slf4j/spi/LocationAwareLogger
>>> at
>>> org.glassfish.jersey.servlet.internal.ResponseWriter.rethrow(ResponseWriter.java:230
>>> ...
>>> at org.apache.jena.riot.web.HttpOp.ensureClient(HttpOp.java:1044)
>>> ...
>>> at com.hp.hpl.jena.rdf.model.impl.ModelCom.read(ModelCom.java:229)
>>> ...
>>> at
>>> org.apache.stanbol.reasoners.web.input.provider.impl.UrlInputProvider.getInput(UrlInputProvider.java:105)
>>> ...
>>>
>>> After a short inspection, I found that the dependency
>>> com.hp.hpl.jena-2.6.3 depends on slf4j-1.5.8 [1] which is incompatible with
>>> slf4j-1.6.1 [2], which we use as reference version [3].
>>> Clerezza trunk is using Jena 2.11, so maybe our situation is temporary?
>>> Should we migrate to a more recent version of Jena soon?
>>> If we cannot do it soon, does anybody know a temporary fix?
>>>
>>> Cheers,
>>> Enrico
>>>
>>>
>>> [1]
>>> http://repo1.maven.org/maven2/com/hp/hpl/jena/jena/2.6.3/jena-2.6.3.pom
>>> [2]
>>> http://upstream-tracker.org/java/compat_reports/slf4j/1.5.11_to_1.6.0/bin_compat_report.html
>>> [3] http://svn.apache.org/repos/asf/stanbol/trunk/parent/pom.xml
>>>
>>> --
>>>
>>> ------------------------------------------------------------------------------
>>> enridaga
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> ------------------------------------------------------------------------------
>> enridaga
>>
>
>
>
> --
> ------------------------------------------------------------------------------
> enridaga
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
Re: SLF4J 1.6.1 and Jena 2.6.3 incompatibiliy
Posted by enridaga <en...@apache.org>.
Unfortunately option 2) is less easy as expected. While the code compiles
(even without tests because of some formatters missing in 1.5.8), changing
the version at runtime is less straightforward, since the version used at
runtime by Felix is 1.6.6 and this is surely a constraint.
(Again, I am not sure that the problem is related to slf4j version
conflict, it is just the only hypothesis I have at the moment)
Just as reference, here is a longer stacktrace of my exception:
Caused by: java.lang.NoClassDefFoundError: org/slf4j/spi/LocationAwareLogger
at
org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:157)
at
org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:132)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:272)
at
org.apache.http.impl.client.AbstractHttpClient.<init>(AbstractHttpClient.java:187)
at
org.apache.http.impl.client.DefaultHttpClient.<init>(DefaultHttpClient.java:127)
at
org.apache.http.impl.client.SystemDefaultHttpClient.<init>(SystemDefaultHttpClient.java:113)
at org.apache.jena.riot.web.HttpOp.ensureClient(HttpOp.java:1044)
at org.apache.jena.riot.web.HttpOp.exec(HttpOp.java:1008)
at org.apache.jena.riot.web.HttpOp.execHttpGet(HttpOp.java:291)
at org.apache.jena.riot.web.HttpOp.execHttpGet(HttpOp.java:326)
at org.apache.jena.riot.stream.LocatorURL.open(LocatorURL.java:46)
at
org.apache.jena.riot.stream.StreamManager.openNoMapOrNull(StreamManager.java:138)
at org.apache.jena.riot.stream.StreamManager.open(StreamManager.java:99)
at org.apache.jena.riot.RDFDataMgr.open(RDFDataMgr.java:783)
at org.apache.jena.riot.RDFDataMgr.open(RDFDataMgr.java:772)
at org.apache.jena.riot.RDFDataMgr.parse(RDFDataMgr.java:676)
at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:211)
at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:184)
at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:122)
at org.apache.jena.riot.RDFDataMgr.read(RDFDataMgr.java:113)
at org.apache.jena.riot.adapters.RDFReaderRIOT.read(RDFReaderRIOT.java:77)
at com.hp.hpl.jena.rdf.model.impl.ModelCom.read(ModelCom.java:229)
at
com.hp.hpl.jena.ontology.impl.OntModelImpl.readDelegate(OntModelImpl.java:3107)
at com.hp.hpl.jena.ontology.impl.OntModelImpl.read(OntModelImpl.java:2198)
at com.hp.hpl.jena.ontology.impl.OntModelImpl.read(OntModelImpl.java:2122)
at
org.apache.stanbol.reasoners.web.input.provider.impl.UrlInputProvider.getInput(UrlInputProvider.java:105)
at
org.apache.stanbol.reasoners.web.input.impl.SimpleInputManager$1.nextProvider(SimpleInputManager.java:97)
at
org.apache.stanbol.reasoners.web.input.impl.SimpleInputManager$1.hasNext(SimpleInputManager.java:123)
at
org.apache.stanbol.reasoners.web.utils.ReasoningServiceExecutor.execute(ReasoningServiceExecutor.java:320)
at
org.apache.stanbol.reasoners.web.utils.ReasoningServiceExecutor.call(ReasoningServiceExecutor.java:385)
at
org.apache.stanbol.reasoners.web.resources.ReasoningServiceTaskResource.processRealTimeRequest(ReasoningServiceTaskResource.java:348)
at
org.apache.stanbol.reasoners.web.resources.ReasoningServiceTaskResource.processRequest(ReasoningServiceTaskResource.java:274)
at
org.apache.stanbol.reasoners.web.resources.ReasoningServiceTaskResource.get(ReasoningServiceTaskResource.java:295)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:140)
at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:158)
at
org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at
org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:101)
at
org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:353)
at
org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:343)
at
org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:237)
... 62 more
On 19 November 2013 10:01, enridaga <en...@apache.org> wrote:
> Hi again,
> 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.
> 2) Downgrade slf4j to 1.5.8 and plane the jena upgrade for a future
> iteration. Is there a special reason why we need 1.6.1 *now*?
>
> The first may be more time consuming because would affect probably a large
> part of the codebase.
> I will try to do the second and see what happens.
>
> Again, if someone else has some ideas on this is welcome.
>
> Bests,
> Enrico
>
>
> On 10 November 2013 19:11, enridaga <en...@apache.org> wrote:
>
>> Hi all,
>>
>> Working on STANBOL-1174, I am having the following exception from a
>> stanbol-reasoners JAX-RS resource (cropped stack trace):
>>
>> 10.11.2013 17:55:05.757 *WARN* [qtp362287566-27]
>> org.eclipse.jetty.servlet.ServletHandler /reasoners/rdfs/classify
>> org.glassfish.jersey.server.ContainerException:
>> java.lang.NoClassDefFoundError: org/slf4j/spi/LocationAwareLogger
>> at
>> org.glassfish.jersey.servlet.internal.ResponseWriter.rethrow(ResponseWriter.java:230
>> ...
>> at org.apache.jena.riot.web.HttpOp.ensureClient(HttpOp.java:1044)
>> ...
>> at com.hp.hpl.jena.rdf.model.impl.ModelCom.read(ModelCom.java:229)
>> ...
>> at
>> org.apache.stanbol.reasoners.web.input.provider.impl.UrlInputProvider.getInput(UrlInputProvider.java:105)
>> ...
>>
>> After a short inspection, I found that the dependency
>> com.hp.hpl.jena-2.6.3 depends on slf4j-1.5.8 [1] which is incompatible with
>> slf4j-1.6.1 [2], which we use as reference version [3].
>> Clerezza trunk is using Jena 2.11, so maybe our situation is temporary?
>> Should we migrate to a more recent version of Jena soon?
>> If we cannot do it soon, does anybody know a temporary fix?
>>
>> Cheers,
>> Enrico
>>
>>
>> [1]
>> http://repo1.maven.org/maven2/com/hp/hpl/jena/jena/2.6.3/jena-2.6.3.pom
>> [2]
>> http://upstream-tracker.org/java/compat_reports/slf4j/1.5.11_to_1.6.0/bin_compat_report.html
>> [3] http://svn.apache.org/repos/asf/stanbol/trunk/parent/pom.xml
>>
>> --
>>
>> ------------------------------------------------------------------------------
>> enridaga
>>
>>
>>
>>
>
>
> --
>
> ------------------------------------------------------------------------------
> enridaga
>
--
------------------------------------------------------------------------------
enridaga
Re: SLF4J 1.6.1 and Jena 2.6.3 incompatibiliy
Posted by enridaga <en...@apache.org>.
Hi again,
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.
2) Downgrade slf4j to 1.5.8 and plane the jena upgrade for a future
iteration. Is there a special reason why we need 1.6.1 *now*?
The first may be more time consuming because would affect probably a large
part of the codebase.
I will try to do the second and see what happens.
Again, if someone else has some ideas on this is welcome.
Bests,
Enrico
On 10 November 2013 19:11, enridaga <en...@apache.org> wrote:
> Hi all,
>
> Working on STANBOL-1174, I am having the following exception from a
> stanbol-reasoners JAX-RS resource (cropped stack trace):
>
> 10.11.2013 17:55:05.757 *WARN* [qtp362287566-27]
> org.eclipse.jetty.servlet.ServletHandler /reasoners/rdfs/classify
> org.glassfish.jersey.server.ContainerException:
> java.lang.NoClassDefFoundError: org/slf4j/spi/LocationAwareLogger
> at
> org.glassfish.jersey.servlet.internal.ResponseWriter.rethrow(ResponseWriter.java:230
> ...
> at org.apache.jena.riot.web.HttpOp.ensureClient(HttpOp.java:1044)
> ...
> at com.hp.hpl.jena.rdf.model.impl.ModelCom.read(ModelCom.java:229)
> ...
> at
> org.apache.stanbol.reasoners.web.input.provider.impl.UrlInputProvider.getInput(UrlInputProvider.java:105)
> ...
>
> After a short inspection, I found that the dependency
> com.hp.hpl.jena-2.6.3 depends on slf4j-1.5.8 [1] which is incompatible with
> slf4j-1.6.1 [2], which we use as reference version [3].
> Clerezza trunk is using Jena 2.11, so maybe our situation is temporary?
> Should we migrate to a more recent version of Jena soon?
> If we cannot do it soon, does anybody know a temporary fix?
>
> Cheers,
> Enrico
>
>
> [1]
> http://repo1.maven.org/maven2/com/hp/hpl/jena/jena/2.6.3/jena-2.6.3.pom
> [2]
> http://upstream-tracker.org/java/compat_reports/slf4j/1.5.11_to_1.6.0/bin_compat_report.html
> [3] http://svn.apache.org/repos/asf/stanbol/trunk/parent/pom.xml
>
> --
>
> ------------------------------------------------------------------------------
> enridaga
>
>
>
>
--
------------------------------------------------------------------------------
enridaga