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 <enrid...@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 <enrid...@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 <enrid...@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.westentha...@gmail.com
| Bodenlehenstraße 11                             ++43-699-11108907
| A-5500 Bischofshofen

Reply via email to