Menu
▾
▴
resteasy-developers
|
From: Sean D. <sea...@gm...> - 2014-03-18 15:34:37
|
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?
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?
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.
Thanks!
|
|
From: Bill B. <bb...@re...> - 2014-03-18 16:37:48
|
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
|
|
From: Sean D. <sea...@gm...> - 2014-03-18 20:13:03
|
Appreciate the response.
On (1 - matching) unfortunately the context param didn't seem to work for
my case - so will need to figure out something else. I did read your blog
post and the migration info but not yet sure what the best way to change
our api would be at this point.
On (2 - client/deprecate), will check the docs again for the new client
apis/interfaces.
On (3 - async), I'm not able to share much of the code related to this and
I haven't come up with a way to reproduce it using something similar.
Essentially though, if all I do is change the RestEasy version in my maven
dependencies from 2.3.3 to 3.0.6, on timeout (5 seconds) I now get a 503 -
service unavailable, instead of previously a 200 ok (this is from firefox
directly to jetty server). If an event comes in to dispatch during the 5
secs, things do work as expected in 3.0.6. We are running under servlet
3.0.
On Tue, Mar 18, 2014 at 12:37 PM, Bill Burke <bb...@re...> wrote:
>
>
>
>
>
> 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
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
|
|
From: Sean D. <sea...@gm...> - 2014-04-01 22:29:20
|
So, on this...
On Tue, Mar 18, 2014 at 4:12 PM, Sean Dawson <sea...@gm...>wrote:
>
> On (3 - async), I'm not able to share much of the code related to this and
> I haven't come up with a way to reproduce it using something similar.
> Essentially though, if all I do is change the RestEasy version in my maven
> dependencies from 2.3.3 to 3.0.6, on timeout (5 seconds) I now get a 503 -
> service unavailable, instead of previously a 200 ok (this is from firefox
> directly to jetty server). If an event comes in to dispatch during the 5
> secs, things do work as expected in 3.0.6. We are running under servlet
> 3.0.
>
>
It looks like the (3.0.7 source code) tests and everything are well aware
that a 503 is returned. It certainly wasn't before so I'm not sure
when/why it changed (probably to follow the spec I suspect). Anyway, we
were using...
@Suspend(5000) AsynchronousResponse response
and if there was nothing to return, the response wouldn't get set (and
eventually timeout returning a 200/ok). But if there was something, then
we'd build it along the lines of... (simplified example type here though)...
response.setResponse(Response.ok(new GenericEntity<String>(data, new
ParameterizedType()
{
@Override
public Type getRawType()
{
return String.class;
}
@Override
public Type getOwnerType()
{
return null;
}
@Override
public Type[] getActualTypeArguments()
{
return new Type[]
{
String.class
};
}
})).build());
Now I'm doing...
@Suspended AsyncResponse response
response.setTimeout(10, TimeUnit.SECONDS);
response.setTimeoutHandler(timeoutHandler);
and...
response.resume(data);
Which seems to mostly work - ie. my timeoutHandler does a resume with empty
data, the timeout is observed, we get a 200/ok, and it returns as soon as
we do have data - the problem is the data is not making it to the client -
it ends up being null even though the server resumes with valid data. This
is with gwt, RestyGwt, etc. If I just have the server and go directly
against it from the Firefox RestEasy client, then either I get errors for
not having a MessageBodyWriter for text/html, or if everything is set to
application/json it just never returns on the resume (either on timeout or
on data - ie. client just hangs), or after trying some variations I get a
500 Server Error with no more information in the client or the (development
environment) server (no exceptions, etc).
Any ideas/pointers?
|
|
From: Bill B. <bb...@re...> - 2014-04-02 00:07:35
|
What does your web.xml look like? Are you using HttpServlet30Dispatcher?
I'm still not understanding the problem. The timeout handler is not
working or the resume is not working?
On 4/1/2014 6:29 PM, Sean Dawson wrote:
> So, on this...
>
> On Tue, Mar 18, 2014 at 4:12 PM, Sean Dawson <sea...@gm...
> <mailto:sea...@gm...>> wrote:
>
> On (3 - async), I'm not able to share much of the code related to
> this and I haven't come up with a way to reproduce it using
> something similar. Essentially though, if all I do is change the
> RestEasy version in my maven dependencies from 2.3.3 to 3.0.6, on
> timeout (5 seconds) I now get a 503 - service unavailable, instead
> of previously a 200 ok (this is from firefox directly to jetty
> server). If an event comes in to dispatch during the 5 secs, things
> do work as expected in 3.0.6. We are running under servlet 3.0.
>
> It looks like the (3.0.7 source code) tests and everything are well
> aware that a 503 is returned. It certainly wasn't before so I'm not
> sure when/why it changed (probably to follow the spec I suspect).
> Anyway, we were using...
>
> @Suspend(5000) AsynchronousResponse response
> and if there was nothing to return, the response wouldn't get set (and
> eventually timeout returning a 200/ok). But if there was something,
> then we'd build it along the lines of... (simplified example type here
> though)...
> response.setResponse(Response.ok(new GenericEntity<String>(data, new
> ParameterizedType()
> {
> @Override
> public Type getRawType()
> {
> return String.class;
> }
> @Override
> public Type getOwnerType()
> {
> return null;
> }
> @Override
> public Type[] getActualTypeArguments()
> {
> return new Type[]
> {
> String.class
> };
> }
> })).build());
> Now I'm doing...
> @Suspended AsyncResponse response
> response.setTimeout(10, TimeUnit.SECONDS);
> response.setTimeoutHandler(timeoutHandler);
> and...
> response.resume(data);
> Which seems to mostly work - ie. my timeoutHandler does a resume with
> empty data, the timeout is observed, we get a 200/ok, and it returns as
> soon as we do have data - the problem is the data is not making it to
> the client - it ends up being null even though the server resumes with
> valid data. This is with gwt, RestyGwt, etc. If I just have the server
> and go directly against it from the Firefox RestEasy client, then either
> I get errors for not having a MessageBodyWriter for text/html, or if
> everything is set to application/json it just never returns on the
> resume (either on timeout or on data - ie. client just hangs), or after
> trying some variations I get a 500 Server Error with no more information
> in the client or the (development environment) server (no exceptions, etc).
> Any ideas/pointers?
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
Thanks for helping keep SourceForge clean.
X