Paul,
Thanks. As for the forum, this would the right one. However, we recently completed version 2.0 of JAX-RS, so new features will need to wait until the next release.
-- Santiago
On Jul 19, 2013, at 2:13 PM, Paul Moore <paulkmoore_at_gmail.com> wrote:
> Raised https://java.net/jira/browse/JAX_RS_SPEC-417
>
> Thanks
>
> Paul
>
> On 18 July 2013 16:28, Paul Moore <paulkmoore_at_gmail.com> wrote:
> Santiago,
>
> Many thanks for this, I will raise a JIRA as you suggest. I wanted not to have have missed something obvious!
>
> I was thinking that there might be a more general requirement for delegation of other header values e.g. ETag's, although some have more "resource affinity" than others.
>
> With some thoughts towards a solution I was considering an annotation based approach (e.g. @Header(value="Allow) ) to annotate the delegate methods, but I'm cognisant of the fact that *a* resource may be split across many classes (as with method requests), so there may be a requirement for an equivalent to the Method Router in order to dispatch to the appropriate method.
>
> Anyway, I'll raise a JIRA for the Allow header case and see where we go from there.
>
> With regards to progressing a solution, is this the best forum to continue the discussion?
>
> Many thanks
>
> Paul
>
>
> On 18 July 2013 16:00, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
> Paul,
>
> Seems like a reasonable request to me. I suggest that you file a JIRA [https://java.net/jira/browse/JAX_RS_SPEC] if you haven't done so yet.
>
> Thanks.
>
> -- Santiago
>
> On Jul 17, 2013, at 12:03 PM, Paul Moore <paulkmoore_at_gmail.com> wrote:
>
>> Hi all,
>>
>> I'm after some help with potential discrepancies in the Allow header of a particular resource.
>>
>> I (reasonably) have a resource which "Allows" different methods at different points in its business lifecycle.
>>
>> By way of (contrived) example, imagine a shopping cart which only allows a maximum of 10 items in it. The (cart sub-ordinate) items collection is POST accepting up to the point at which it has 10 items, at which point it is no longer POST accepting. The point here is that the "Allow"able methods on the collection can change with the business state. Accordingly an OPTIONS request should reflect the change in resource state i.e. for this example GET,POST,OPTIONS -> GET,OPTIONS.
>>
>> I understand that:
>> i) I can set the Allow header appropriately in the ResponseBuilder (for a matched method), and
>> ii) I can can create an @OPTIONS annotated method that implements the vagaries of the resource lifecycle, and
>> iii) the "implementor" is responsible for providing generated Allow headers in a) 405 Method Not Allowed exceptions, and b) OPTIONS request where no @OPTIONS annotated method has been provided.
>>
>> In the Jersey implementation, the automatic Allow header is (reasonably) generated by reflection of the annotated methods for the resource. This approach obviously limits the result to *static* annotations.
>>
>> My point here is that whilst the spec provides for customisation of the Allow header for the @OPTIONS request, it does not provide a mechanism to allow users to supplement the automatic "Allow" generation functionality, and therefore the user is subject to the implementation as to whether these match.
>>
>> Explicitly, given the Jersey example, I can easily customise the @OPTIONS request response, but 405 handling is buried deep within the (internal) MethodSelectingRouter::getMethodRouter, leading to discrepancies between the dynamic @OPTIONS handling and the *static* 405 handling.
>>
>> So, aside from extending Jersey in some way to handle this "dynamic resource" (a discussion for another forum) I am wondering if a future revision of the spec could or should mandate some pluggable delegation mechanism for handling Allow headers.
>>
>> Thoughts?
>>
>> Best regards
>>
>> Paul
>>
>>
>
>
>