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:
>> 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
>> 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)
>> So, the underlying issue might be related to a change in initialisation or
deployment from RESTEasy 1.x to 2.x.
JBoss, a division of Red Hat