This is strange, as I did a quick check, and I see both things: * the code that takes RPF out from servlet context - ServletContainerDispatcher * the code that puts it into servlet context - ResteasyBootstrap should be loaded by war's classloader, hence your local RE should be used. But this was a quick check ... On May 25, 2010, at 10:52 AM, Galder Zamarreno wrote: > Hi, > > Last week I was testing deploying a war file with RESTEasy on 1.2.1.GA in the war archive's WEB-INF/lib directory and I was getting a CCE like the one below. > > 12:39:58,448 ERROR [[/infinispan-server-rest]] Exception starting filter Resteasy: java.lang.ClassCastException: org.jboss.resteasy.spi.ResteasyProviderFactory cannot be cast to org.jboss.resteasy.spi.ResteasyProviderFactory > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:55) [:] > at org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.init(FilterDispatcher.java:39) [:] > at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:462) [:] > at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3286) [:] > at org.apache.catalina.core.StandardContext.start(StandardContext.java:3887) [:] > > AS ships with a different version of RESTEasy library which would explain this issue (latest AS ships 2.0-beta-2). However, AFAIR in the past WEB-INF/lib was deployed under a different classloader and hence this shouldn't be a problem, should it? > > FilterDispatcher is a class that's only in REST 2.0, so somehow tomcat's ApplicationFilterConfig loads a 2.0 filter class (this is probably configured in some web.xml somewhere) but when this 2.0 class tries to load ResteasyProviderFactory, this is loaded from the war's lib directory (1.x). > > providerFactory = (ResteasyProviderFactory) servletContext.getAttribute(ResteasyProviderFactory.class.getName()); > > So, the underlying issue might be related to a change in initialisation or deployment from RESTEasy 1.x to 2.x.

All I see is that you add a metadata for your RE filter. The rest should be standard JBossWeb/Tomcat behavior on top of metadata. Don't see how 2.0 class could crawl in. But it looks like it does manage to do so. :-) On May 25, 2010, at 3:14 PM, Bill Burke wrote: > It could be just that the deployer is screwing up and adding a resteasy filter from 2.0 within the deployment when it should not be doing that. > > Ales Justin wrote: >> This is strange, as I did a quick check, and I see both things: >> * the code that takes RPF out from servlet context - ServletContainerDispatcher >> * the code that puts it into servlet context - ResteasyBootstrap >> should be loaded by war's classloader, hence your local RE should be used. >> But this was a quick check ... >> On May 25, 2010, at 10:52 AM, Galder Zamarreno wrote: >>> Hi, >>> >>> Last week I was testing deploying a war file with RESTEasy on 1.2.1.GA in the war archive's WEB-INF/lib directory and I was getting a CCE like the one below. >>> >>> 12:39:58,448 ERROR [[/infinispan-server-rest]] Exception starting filter Resteasy: java.lang.ClassCastException: org.jboss.resteasy.spi.ResteasyProviderFactory cannot be cast to org.jboss.resteasy.spi.ResteasyProviderFactory >>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:55) [:] >>> at org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.init(FilterDispatcher.java:39) [:] >>> at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:462) [:] >>> at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3286) [:] >>> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3887) [:] >>> >>> AS ships with a different version of RESTEasy library which would explain this issue (latest AS ships 2.0-beta-2). However, AFAIR in the past WEB-INF/lib was deployed under a different classloader and hence this shouldn't be a problem, should it? >>> >>> FilterDispatcher is a class that's only in REST 2.0, so somehow tomcat's ApplicationFilterConfig loads a 2.0 filter class (this is probably configured in some web.xml somewhere) but when this 2.0 class tries to load ResteasyProviderFactory, this is loaded from the war's lib directory (1.x). >>> providerFactory = (ResteasyProviderFactory) servletContext.getAttribute(ResteasyProviderFactory.class.getName()); >>> >>> So, the underlying issue might be related to a change in initialisation or deployment from RESTEasy 1.x to 2.x. > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com