IMHO it is always worth looking critically at the spec API, not to be
negative but to see what may not be quite right and can be improved
going forward.
As such, I can only imagine that the reason @Suspended docs say such
method responses must be ignored but do not go further and recommend not
adding them as the candidates is about supporting a "just in case" case
or a case where a test has not been provided with a WARNING being the
last resort warning.
I believe at this stage it is safe and good to ignore such methods
completely unless I'm missing something obvious.
Andy, can you please start with a patch to move from FINE to WARNING and
open another JIRA (minor Bug is probably OK) about such methods being
removed from the list of candidates - we would link it to a JAX-RS 2.1
issue where some extra justifications about the reason why such methods
are still candidates can be sought - please open this JAX-RS 2.1 issue
too or I can open it.
Does this plan work for you ?
Thanks, Sergey
On 01/11/16 16:25, Sergey Beryozkin wrote:
Hi Andy
On 01/11/16 15:50, Andy McCright wrote:
Hi All,
When we moved to 3.1.7 a few months ago, we started seeing a test failure
in one of our system tests. The tester had a JAX-RS resource with the
following method signature:
@GET
@Produces(MediaType.APPLICATION_JSON)
public JSONObject getMessage(@QueryParam("id") int i, @Suspended
AsyncResponse async)
Prior to 3.1.7, this method could be invoked and would return a 200
response with a JSON message. After the upgrade, the same request
results
in a 405 response, and no warning message.
When I read the javadoc text for the @Suspended annotation (
http://docs.oracle.com/javaee/7/api/javax/ws/rs/container/Suspended.html
),
it makes me think that the method should be available (and requests
should
still succeed), but that the return value of the method should be
ignored.
I also think we should be logging a warning rather than a fine message.
Does that sound good? If no objections, I'll plan to open a JIRA and
provide a patch.
I agree it should be a warning instead of a fine message.
However I'm not sure what we will achieve by keeping such method
candidates. The developer who writes this code will expect the value be
returned to the user but the test validating that some value is returned
will fail anyway.
Thus such methods can only add to the cost of the selection process if
they are added to the list of the candidates and will confuse the users
(ex, suspended GET will be still supported but the GET user will
eventually get an empty page...).
Can you see any practical scenarios where keeping such method candidates
can you actually make these methods work ?
Thanks, Sergey
Thanks, Andy
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
