Hi Sergey,
Sure, I can open both JIRAs.
As for use cases, the only one I can think of is a stretch, but what if a
user wanted to re-use an async method -- something like this:
@GET
public String getName(@QueryParam int id, @Suspended AsyncResponse ar) {
String result = getNameFromDatabase(id);
if (ar != null) {
ar.resume(result);
}
return result;
}
@PUT
String getAndUpdateName(int id, String newName) {
String result = getName(id, null);
if ( updateDatabaseWithNewName(id, newName) ) {
return "Was " + result + " but now is " + newName;
} else {
throw new DBException("failed to update name ...");
}
}
I'll start work on the first JIRA and patch (changing to warning) now. If
this use case convinces you, we can always add to the patch to keep the
method in the list of candidates.
Thanks for feedback,
Andy
On Tue, Nov 1, 2016 at 4:45 PM, Sergey Beryozkin <[email protected]>
wrote:
> 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/
>
