cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Non-void return types for async methods
Date Tue, 01 Nov 2016 21:45:38 GMT
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 (
>> ),
>> 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

View raw message