avro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ta-Chung Tsai <tach...@gmail.com>
Subject Re: Schema <clinit> verify error in Tomcat 6
Date Mon, 04 Oct 2010 01:39:13 GMT
Thank you guys. The verification error was gone when I upgrade to Jersey
1.4.

However, I encountered another error when deployed on Tomcat6 as follows.
But I do have avro-tools-1.4.0.jar in the app's WEB-INF/lib folder, which
contains org.slf4j.LoggerFactory.
It seems class loader cannot locate it. Do I still miss something?

13047     java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
13048     at org.apache.avro.ipc.Requestor.<clinit>(Requestor.java:48)
13049     at
main.com.trendmicro.wrs.region_ptn.RegionFilterQueryResource.getQueryResult(Unknown
Source)
13050     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
13051     at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
13052     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
13053     at java.lang.reflect.Method.invoke(Method.java:597)
13054     at
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:187)
13055     at
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:70)
13056     at
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:279)
13057     at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
13058     at
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:86)
13059     at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
13060     at
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:74)
13061     at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1357)
13062     at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1289)
13063     at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1239)
13064     at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1229)
13065     at
com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:420)
13066     at
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:497)
13067     at
com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:855)
13068     at
com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:828)
13069     at
com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:789)
13070     at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
13071     at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
13072     at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
13073     at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
13074     at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
13075     at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
13076     at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
13077     at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
13078     at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
13079     at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
13080     at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
13081     at java.lang.Thread.run(Thread.java:619)
13082 Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory
13083     at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1484)
13084     at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329)
13085     ... 34 more

---
Terry

On Fri, Oct 1, 2010 at 5:41 AM, Tatu Saloranta <tsaloranta@gmail.com> wrote:

> On Thu, Sep 30, 2010 at 1:46 PM, Scott Carey <scott@richrelevance.com>
> wrote:
> > On Sep 30, 2010, at 10:14 AM, Tatu Saloranta wrote:
> >
> ...
> > Avro is using Jackson 1.4.2 right now.  So I think Jersey is using 1.1.x
> or before and its version is earlier in the classpath.  Would making sure
> Avro and its Jackson 1.4.2 jar being first in the classpath work?  Or does
> the incompatibility go both ways?
>
> From what I have heard, I think it is safe to upgrade, as I have not
> heard of issues with that.
>
> Theoretically go both ways, since it is difference between method
> signatures. But it depends on whether ObjectMapper.configure() methods
> are being called or not; which Jersey might not be doing. And
> especially earlier versions do not, since it only used to rely on core
> (non-mapper) part.
>
> > The latest jersey-json jar (1.4) depends on jackson 1.5.5.  However, as
> late as jersey-json 1.3, they were still on Jackson 1.1.
>
> Right I think jersey-json only uses core pieces; and for it any 1.x
> version should be fine.
>
> > So it looks like at the minimum, upgrading to Jersey 1.4 should help
> Ta-Chung.  Assuming he is using jersey-json.
>
> Yes I think this is correct.
>
> -+ Tatu +-
>

Mime
View raw message