Hi,
Please excuse the cross-post, but I'm becoming more of the opinion that
there is no trivial fix for this, and therefore maybe it needs some "dev"
eyes on it :)
More investigation reveals that the problem is (at least) two fold:
- Within a Filter there is no real way *back* to the current Resource
- For a 405, there appears not to be any "MatchingResources" from
uriInfo::getMatchedResources() (presumably because there is no match on
method), so it's difficult to contextualise a suitable delegate.
Any thoughts willingly received.
Thanks
Paul
---------- Forwarded message ----------
From: Paul Moore <paulkmoore_at_gmail.com>
Date: 16 July 2013 00:08
Subject: Controlling the content of the "Allow" header
To: users_at_jersey.java.net
Hi all,
Just a quick question to find out if there's a sensible way to control the
contents of the "Allow" header with some form of delegate pattern, or
similar.
My research to date indicates that the JAX-RS 2 spec support for handling
the Allow header is:
- Specifying the Allow header content using the ResponseBuilder (as part
of normal processing)
- Providing an @OPTIONS annotated method for direct Http Options requests
- Some reflection based (auto) generation of the supported methods
during handling of a NotAllowedMethod (405), specifically in
MethodSelectingRouter::getMethodRouter
To provide some context to what I'm trying to do...
I have a collection that is POST accepting for some of the time. When the
parent object is deemed *complete* no further POSTing of subordinate
resources is permitted. In this way, an OPTIONS request to the subordinate
(collection) should change from POST accepting to non-POST accepting e.g.
"GET, POST, OPTIONS" -> "GET, OPTIONS"
Have I missed something obvious, of am I off on a deep(er) journey into the
Jersey internals?
Note: I've also looked at Filters as a possible way of achieving this, but
see no easy path to "get back to" the calling context i.e. a method in the
resource class.
Thoughts welcomely received
Best regards
Paul