Hi Nick,
On 14/05/14 14:22, Nick Burch wrote:
On Wed, 14 May 2014, Sergey Beryozkin wrote:
UnpackerResource has no Path annotation so it is defaulted to "/".
Every endpoint method within the class does have one though. I would've
expected it to match based on those, is that not the case?
JAX-RS 1.1 selection algorithm works as follows: a matching root
resource is found first, a resource method is searched next, if no
method is matched then no back-tracking to the other matching root
resource, if any, is done. The extension I linked to can be used to
resolve it.
JAX-RS 2.0 algorithm does it differently, it basically accumulates all
the resource methods found in all of the matching root resources and
then looks for a matching resource method so in our case it will work.
However, the selection between multiple root resources with the same
top-level Path is more expensive so ideally we could introduce a
dedicated @Path to UnpackerResource.
As we add more endpoints, that would seem to make sense to me. I'm not
sure how widely used the unpacker resource is, so I don't know how much
disruption it would be if we added a /unpacker/ prefix to the path?
Right, it is a concern. May be lets upgrade to CXF 3.0.0 (will be voted
for in the next few days), ensure we have it working as is and then
revisit the possibility of upgrading UnpackerResource root Path ?
We can definitely support the legacy clients with a custom 2.0
ContainerRequestFilter PreMatch filter if we did update the Path,
example, we'd have a pre-configured UnpackerResourceFilter which would
adapt a known (old) UnpackerResource URI to the new one for the
selection algorithm to succeed
However. may be we can settle on having two root resource with the same
root Path given that Unpacker & Welcome roots have a limited set of
resource methods once it's confirmed CXF 3.0.0 supports it as expected
I'll work on the upgrade asap.
As a side node it is also possible to add some separation into the URI
space with CXF with the help of multiple endpoints or servlets. Example,
if we talked about Spring or Blueprint then we'd be able to have a
number of individual JAX-RS endpoints with unique relative addresses
with each endpoint having a number of root resources with unique root
Paths - so if a number of resources will keep growing then we can
consider splitting them into endpoints/groups
The other option is to consider implementing a Welcome functionality
in a JAX-RS 2.0 ContainerRequestFilter (supported in CXF 2.7.x), build
a welcome info there and abort/block a request
Is that the more "normal" way to handle it in JAX-RS, or is what we've
got so far a generally know practice?
It's not really a JAX-RS specific approach, rather I was thinking how to
work-around the issue. CXF generates WADL from a filter but it is
perfectly OK to offer a Welcome root resource if preferred
Cheers, Sergey
Nick
