The problem is resolved after adding the jars: slf4j-api-1.6.1.jar, slf4j-simple-1.6.1.jar, and jackson-all-1.6.0.jar. The only strange thing for me is that they should all be included in the avro-tools-1.4.0.jar, but why the classes cannot be found?
Thank you anyway. I finally got the problem resolved. Cheers, Terry On Mon, Oct 4, 2010 at 9:39 AM, Ta-Chung Tsai <[email protected]> wrote: > 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 <[email protected]>wrote: > >> On Thu, Sep 30, 2010 at 1:46 PM, Scott Carey <[email protected]> >> 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 +- >> > >
