Ta-Chung Tsai
2010-09-30, 02:30
Scott Carey
2010-09-30, 16:30
Tatu Saloranta
2010-09-30, 17:14
Scott Carey
2010-09-30, 20:46
Tatu Saloranta
2010-09-30, 21:41
Ta-Chung Tsai
2010-10-04, 01:39
Ta-Chung Tsai
2010-10-04, 04:04
-
Schema <clinit> verify error in Tomcat 6Ta-Chung Tsai 2010-09-30, 02:30
We've developed a web service using Jersey and used Avro HTTPTransceiver as
a RPC to fetch some status from a server.
However, after deploying on Tomcat6, I got the following error, no matter
what protocols I used.
java.lang.VerifyError: (class: org/apache/avro/Schema, method: <clinit>
signature: ()V) Incompatible argument to function
at org.apache.avro.ipc.Requestor.<clinit>(Requestor.java:50)
at main.com.trendmicro.wrs.region_ptn.TestResource.getRes(Unknown Source)
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
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:165)
at
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67)
at
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:276)
at
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:83)
at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133)
at
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:71)
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1171)
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1103)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1053)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1043)
at
com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:406)
at
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:477)
at
com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:833)
at
com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:806)
at
com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:767)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
My test program is as follows:
@Path("/testavro")
public class TestResource {
@GET
@Produces(MediaType.TEXT_PLAIN)
public String getRes()
{
try {
HttpTransceiver client = new HttpTransceiver(new
URL("http://serverURL:10080<http://10.1.112.159:10080/>
"));
Region proxy = (Region) SpecificRequestor.getClient(Region.class, client);
Stat ret = proxy.getTest("id");
return "ok";
} catch (MalformedURLException e) {
return "malformedURL:" + e;
} catch (IOException e) {
return "ioException: " + e;
}
}
}
If I put the same program in main(), it can be executed smoothly without
exception. I am sure the classpath is correct by deleting avro-1.3.3.jar.
The same problem occurs in both avro-1.3.3 and avro-1.4.0.
Do I miss something here?
Terry Tsai
a RPC to fetch some status from a server.
However, after deploying on Tomcat6, I got the following error, no matter
what protocols I used.
java.lang.VerifyError: (class: org/apache/avro/Schema, method: <clinit>
signature: ()V) Incompatible argument to function
at org.apache.avro.ipc.Requestor.<clinit>(Requestor.java:50)
at main.com.trendmicro.wrs.region_ptn.TestResource.getRes(Unknown Source)
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
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:165)
at
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67)
at
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:276)
at
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:83)
at
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133)
at
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:71)
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1171)
at
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1103)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1053)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1043)
at
com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:406)
at
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:477)
at
com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:833)
at
com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:806)
at
com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:767)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
My test program is as follows:
@Path("/testavro")
public class TestResource {
@GET
@Produces(MediaType.TEXT_PLAIN)
public String getRes()
{
try {
HttpTransceiver client = new HttpTransceiver(new
URL("http://serverURL:10080<http://10.1.112.159:10080/>
"));
Region proxy = (Region) SpecificRequestor.getClient(Region.class, client);
Stat ret = proxy.getTest("id");
return "ok";
} catch (MalformedURLException e) {
return "malformedURL:" + e;
} catch (IOException e) {
return "ioException: " + e;
}
}
}
If I put the same program in main(), it can be executed smoothly without
exception. I am sure the classpath is correct by deleting avro-1.3.3.jar.
The same problem occurs in both avro-1.3.3 and avro-1.4.0.
Do I miss something here?
Terry Tsai
+
Ta-Chung Tsai 2010-09-30, 02:30
-
Re: Schema <clinit> verify error in Tomcat 6Scott Carey 2010-09-30, 16:30
I think Jersey uses the Jackson JSON library, like Avro does. The Schema class is the first class in the chain that references jackson classes. If the version of Jackson that Jersey uses is old enough, that might be the problem. Its version likely comes first in the classpath. Some of the 1.0.x Jackson versions are known to be incompatible with later Jackson 1.x versions.
The trace below is cryptic, but the first place I would look would be a jar file conflict in a common dependeny.
On Sep 29, 2010, at 7:30 PM, Ta-Chung Tsai wrote:
We've developed a web service using Jersey and used Avro HTTPTransceiver as a RPC to fetch some status from a server.
However, after deploying on Tomcat6, I got the following error, no matter what protocols I used.
java.lang.VerifyError: (class: org/apache/avro/Schema, method: <clinit> signature: ()V) Incompatible argument to function
at org.apache.avro.ipc.Requestor.<clinit>(Requestor.java:50)
at main.com.trendmicro.wrs.region_ptn.TestResource.getRes(Unknown Source)
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 com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:165)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:276)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:83)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:71)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1171)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1103)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1053)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1043)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:406)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:477)
at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:833)
at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:806)
at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:767)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
My test program is as follows:
@Path("/testavro")
public class TestResource {
@GET
@Produces(MediaType.TEXT_PLAIN)
public String getRes()
{
try {
HttpTransceiver client = new HttpTransceiver(new URL("http://serverURL:10080<http://10.1.112.159:10080/>"));
Region proxy = (Region) SpecificRequestor.getClient(Region.class, client);
Stat ret = proxy.getTest("id");
return "ok";
} catch (MalformedURLException e) {
return "malformedURL:" + e;
} catch (IOException e) {
return "ioException: " + e;
}
}
}
If I put the same program in main(), it can be executed smoothly without exception. I am sure the classpath is correct by deleting avro-1.3.3.jar.
The same problem occurs in both avro-1.3.3 and avro-1.4.0.
Do I miss something here?
Terry Tsai
The trace below is cryptic, but the first place I would look would be a jar file conflict in a common dependeny.
On Sep 29, 2010, at 7:30 PM, Ta-Chung Tsai wrote:
We've developed a web service using Jersey and used Avro HTTPTransceiver as a RPC to fetch some status from a server.
However, after deploying on Tomcat6, I got the following error, no matter what protocols I used.
java.lang.VerifyError: (class: org/apache/avro/Schema, method: <clinit> signature: ()V) Incompatible argument to function
at org.apache.avro.ipc.Requestor.<clinit>(Requestor.java:50)
at main.com.trendmicro.wrs.region_ptn.TestResource.getRes(Unknown Source)
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 com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:165)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:276)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:83)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:71)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1171)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1103)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1053)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1043)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:406)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:477)
at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:833)
at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:806)
at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:767)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
My test program is as follows:
@Path("/testavro")
public class TestResource {
@GET
@Produces(MediaType.TEXT_PLAIN)
public String getRes()
{
try {
HttpTransceiver client = new HttpTransceiver(new URL("http://serverURL:10080<http://10.1.112.159:10080/>"));
Region proxy = (Region) SpecificRequestor.getClient(Region.class, client);
Stat ret = proxy.getTest("id");
return "ok";
} catch (MalformedURLException e) {
return "malformedURL:" + e;
} catch (IOException e) {
return "ioException: " + e;
}
}
}
If I put the same program in main(), it can be executed smoothly without exception. I am sure the classpath is correct by deleting avro-1.3.3.jar.
The same problem occurs in both avro-1.3.3 and avro-1.4.0.
Do I miss something here?
Terry Tsai
+
Scott Carey 2010-09-30, 16:30
-
Re: Schema <clinit> verify error in Tomcat 6Tatu Saloranta 2010-09-30, 17:14
On Thu, Sep 30, 2010 at 9:30 AM, Scott Carey <[EMAIL PROTECTED]> wrote:
> I think Jersey uses the Jackson JSON library, like Avro does. The Schema
> class is the first class in the chain that references jackson classes. If
> the version of Jackson that Jersey uses is old enough, that might be the
> problem. Its version likely comes first in the classpath. Some of the
> 1.0.x Jackson versions are known to be incompatible with later Jackson 1.x
> versions.
> The trace below is cryptic, but the first place I would look would be a jar
> file conflict in a common dependeny.
Right: specifically, this is due to unintended binary incompatibility
in Jackson (between version 1.1 and 1.2), casued by changing
configuration method return type from void to "this type". Change was
made to allow chaining of calls, and is source compatible. But it was
not realized at the time that it is not binary compatible... hence
issues.
Solution is simple; code that configures Jackson ObjectMapper needs to
be recompiled. This is not a problem for direct usage, but is
problematic when Jackson is transitive dependency. So in case of Avro
one has to recompile avro lib with never Jackson version, or upgrade
to version that was compiled against later version.
-+ Tatu +-
> I think Jersey uses the Jackson JSON library, like Avro does. The Schema
> class is the first class in the chain that references jackson classes. If
> the version of Jackson that Jersey uses is old enough, that might be the
> problem. Its version likely comes first in the classpath. Some of the
> 1.0.x Jackson versions are known to be incompatible with later Jackson 1.x
> versions.
> The trace below is cryptic, but the first place I would look would be a jar
> file conflict in a common dependeny.
Right: specifically, this is due to unintended binary incompatibility
in Jackson (between version 1.1 and 1.2), casued by changing
configuration method return type from void to "this type". Change was
made to allow chaining of calls, and is source compatible. But it was
not realized at the time that it is not binary compatible... hence
issues.
Solution is simple; code that configures Jackson ObjectMapper needs to
be recompiled. This is not a problem for direct usage, but is
problematic when Jackson is transitive dependency. So in case of Avro
one has to recompile avro lib with never Jackson version, or upgrade
to version that was compiled against later version.
-+ Tatu +-
+
Tatu Saloranta 2010-09-30, 17:14
-
Re: Schema <clinit> verify error in Tomcat 6Scott Carey 2010-09-30, 20:46
On Sep 30, 2010, at 10:14 AM, Tatu Saloranta wrote:
> On Thu, Sep 30, 2010 at 9:30 AM, Scott Carey <[EMAIL PROTECTED]> wrote:
>> I think Jersey uses the Jackson JSON library, like Avro does. The Schema
>> class is the first class in the chain that references jackson classes. If
>> the version of Jackson that Jersey uses is old enough, that might be the
>> problem. Its version likely comes first in the classpath. Some of the
>> 1.0.x Jackson versions are known to be incompatible with later Jackson 1.x
>> versions.
>> The trace below is cryptic, but the first place I would look would be a jar
>> file conflict in a common dependeny.
>
> Right: specifically, this is due to unintended binary incompatibility
> in Jackson (between version 1.1 and 1.2), casued by changing
> configuration method return type from void to "this type". Change was
> made to allow chaining of calls, and is source compatible. But it was
> not realized at the time that it is not binary compatible... hence
> issues.
>
> Solution is simple; code that configures Jackson ObjectMapper needs to
> be recompiled. This is not a problem for direct usage, but is
> problematic when Jackson is transitive dependency. So in case of Avro
> one has to recompile avro lib with never Jackson version, or upgrade
> to version that was compiled against later version.
>
> -+ Tatu +-
Thanks Tatu!
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?
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.
So it looks like at the minimum, upgrading to Jersey 1.4 should help Ta-Chung. Assuming he is using jersey-json.
-Scott
> On Thu, Sep 30, 2010 at 9:30 AM, Scott Carey <[EMAIL PROTECTED]> wrote:
>> I think Jersey uses the Jackson JSON library, like Avro does. The Schema
>> class is the first class in the chain that references jackson classes. If
>> the version of Jackson that Jersey uses is old enough, that might be the
>> problem. Its version likely comes first in the classpath. Some of the
>> 1.0.x Jackson versions are known to be incompatible with later Jackson 1.x
>> versions.
>> The trace below is cryptic, but the first place I would look would be a jar
>> file conflict in a common dependeny.
>
> Right: specifically, this is due to unintended binary incompatibility
> in Jackson (between version 1.1 and 1.2), casued by changing
> configuration method return type from void to "this type". Change was
> made to allow chaining of calls, and is source compatible. But it was
> not realized at the time that it is not binary compatible... hence
> issues.
>
> Solution is simple; code that configures Jackson ObjectMapper needs to
> be recompiled. This is not a problem for direct usage, but is
> problematic when Jackson is transitive dependency. So in case of Avro
> one has to recompile avro lib with never Jackson version, or upgrade
> to version that was compiled against later version.
>
> -+ Tatu +-
Thanks Tatu!
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?
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.
So it looks like at the minimum, upgrading to Jersey 1.4 should help Ta-Chung. Assuming he is using jersey-json.
-Scott
+
Scott Carey 2010-09-30, 20:46
-
Re: Schema <clinit> verify error in Tomcat 6Tatu Saloranta 2010-09-30, 21:41
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 +-
> 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 +-
+
Tatu Saloranta 2010-09-30, 21:41
-
Re: Schema <clinit> verify error in Tomcat 6Ta-Chung Tsai 2010-10-04, 01:39
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:
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:
+
Ta-Chung Tsai 2010-10-04, 01:39
-
Re: Schema <clinit> verify error in Tomcat 6Ta-Chung Tsai 2010-10-04, 04:04
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)
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)
+
Ta-Chung Tsai 2010-10-04, 04:04
