Hi Chris,
On 16/05/14 16:31, Chris Mattmann wrote:
Hi Guys,
Some thoughts here:
-----Original Message-----
From: Nick Burch <apa...@gagravarr.org>
Reply-To: "dev@tika.apache.org" <dev@tika.apache.org>
Date: Wednesday, May 14, 2014 6:22 AM
To: "dev@tika.apache.org" <dev@tika.apache.org>
Subject: Re: JAXRS, endpoints and a / welcome page - any ideas why it's
broken?
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?
How about @Path("/unpack")?
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?
What do you think about my suggestion above?
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?
I would say let's just add the @Path("/unpack") - that's saving us 2
characters and is a small incremental change.
If you guys are +1 I will file an issue and update it.
I've just looked at the source, unfortunately adding a new Path value
will affect the request URIs, UnpackerResource has 2 methods accepting
path segments starting from "/unpacker" and "/all".
So if we updated then the users would have to modify URIs to contain
"/unpack/unpacker1", etc, as opposed to the current "unpacker1".
If it only had 1 resource method then we'd just push that method's Path
up and update the method's Path to "/", but it has 2 methods.
I'm not sure how used is UnpackerResource. If no one uses it or very few
users use it then may be it is the right time to introduce a class-level
Path and document the possible migration task.
Otherwise we can simply keep supporting it as is...
Cheers, Sergey
[1] http://wiki.apache.org/tika/TikaJAXRS
Cheers,
Chris
