Re: [Resteasy-developers] Upgrading from 2.3.3 to 3.0.6

[Bill B. <bb...@re...>]

On 3/18/2014 11:34 AM, Sean Dawson wrote:
>
> Hello,
>
> We're attempting to move from 2.3.3 (final) to 3.0.6 (final) and
> experiencing a few issues.  One is an apparent change to the matching
> algorithm - for example, we have...
>
> @Path("path")
> public interface Resource
> {
>   @Path("subresource/{id}")
>   SubResource get(@PathParam("id") String id);
>
>   @PUT
>   @Path("subresource/{id}")
>    String open(@PathParam("id") String id);
> }
>
> public interface SubResource
> {
>   @DELETE
>   String close();
> }
>
> Previously that would work fine.  Now we get an exception / 405 code
> because it finds the PUT (only/instead).  If I comment out the PUT, then
> the DELETE gets called fine.  What is the best way to address this?
>

JAX-RS 2.0 TCK got *REALLY STRICT* on testing the matching algorithm 
unfortunately:

http://bill.burkecentral.com/2013/05/29/the-poor-jax-rs-request-dispatching-algorithm/

See this:

http://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/Migration_from_older_versions.html


The "resteasy.wider.request.matching" context variable set to "true" may 
be able to help you get past this problem.



> Second, a few things have been deprecated like ClientResponseFailure but
> I wasn't able to find much documentation on why and what we should use
> instead.  Where does one find information on these types of changes?
>

JAX-RS 2.0 has a client API now.  I strongly suggest migrating to it as 
we will be removing the Resteasy client API in later versions.

http://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/Migration_from_older_versions.html



> Finally, we're having some issues with our async comet-like calls now -
> they either return immediately or timeout and return Service Unavailable
> - they were working fine previously.  Interestingly, it seems to mostly
> work direct from a browser but when accessed from a gwt app through a
> proxy - that's when we're having the most issues.  I probably need to
> debug this further but if anyone has pointers, it would be appreciated.
> We're using AsynchronousResponse in the method signature and
> AsyncEventConsumer in the body.
>

If you can some up with something that reproduces the problem that would 
be great.

Also, JAX-RS 2.0 has standardized async HTTP too:

javax.ws.rs.container.AsyncResponse
javax.ws.rs.Suspended



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com