You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by Nick Burch <ap...@gagravarr.org> on 2014/05/07 11:48:21 UTC
JAXRS, endpoints and a / welcome page - any ideas why it's broken?
Hi All
One for our JAXRS gurus here...
At ApacheCon, we came up with the idea of having a welcome page on the
Tika Server, so that we could point people to it to try Tika, and let them
discover what it offered. Based on that, and the mailing list discussions,
we raised TIKA-1269.
(Related to that is TIKA-1270, which aims to add endpoints similar to the
--list- ones the Tika CLI has, which is in progress)
While we work out the best way to allow users to discover + learn about +
try the various REST endpoints on TIKA-1269, I've started with something
basic. This is done with the simple TikaWelcome class, which has a Path of
/
The problem - when the MetadataEP and UnpackerResource are enabled, it
doesn't work! With those to there, when you request / you get a 404 and
the server logs:
rg.apache.cxf.jaxrs.utils.JAXRSUtils findTargetMethod
WARNING: No operation matching request path "/" is found, Relative Path:
/, HTTP Method: GET, ContentType: */*, Accept: */*,. Please enable
FINE/TRACE log level for more details.
However, if you comment out those two endpoint classes from the
sf.setResourceClasses() call in TikaServerCLI, then the request gets
correctly routed to the welcome page.
Neither MetadataEP nor UnpackerResource have a path that clashes, so I've
no idea why having them active stops / working. Any ideas?
(Patch below if you want to try disabling them yourself to investigate)
Nick
Index: src/main/java/org/apache/tika/server/TikaServerCli.java
===================================================================
--- src/main/java/org/apache/tika/server/TikaServerCli.java (revision
1592656)
+++ src/main/java/org/apache/tika/server/TikaServerCli.java (working
copy)
@@ -92,10 +92,20 @@
JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
// Note - at least one of these stops TikaWelcome matching on /
// This prevents TikaWelcome acting as a partial solution to
TIKA-1269
- sf.setResourceClasses(MetadataEP.class, MetadataResource.class,
- TikaResource.class, UnpackerResource.class,
- TikaDetectors.class, TikaMimeTypes.class,
- TikaVersion.class, TikaWelcome.class);
+// sf.setResourceClasses(MetadataEP.class, MetadataResource.class,
+// TikaResource.class, UnpackerResource.class,
+// TikaDetectors.class, TikaMimeTypes.class,
+// TikaVersion.class, TikaWelcome.class);
+ sf.setResourceClasses(
+// MetadataEP.class,
+ MetadataResource.class,
+ TikaResource.class,
+// UnpackerResource.class,
+ TikaDetectors.class,
+ TikaMimeTypes.class,
+ TikaVersion.class,
+ TikaWelcome.class
+ );
List<Object> providers = new ArrayList<Object>();
providers.add(new TarWriter());
Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?
Posted by David Meikle <lo...@gmail.com>.
Hi Nick,
On 7 May 2014, at 12:48, Nick Burch <ap...@gagravarr.org> wrote:
> Hi All
>
> One for our JAXRS gurus here…
OK, not a guru here but I have a hunch.
> At ApacheCon, we came up with the idea of having a welcome page on the Tika Server, so that we could point people to it to try Tika, and let them discover what it offered. Based on that, and the mailing list discussions, we raised TIKA-1269.
>
> (Related to that is TIKA-1270, which aims to add endpoints similar to the --list- ones the Tika CLI has, which is in progress)
>
> While we work out the best way to allow users to discover + learn about + try the various REST endpoints on TIKA-1269, I've started with something basic. This is done with the simple TikaWelcome class, which has a Path of /
>
> The problem - when the MetadataEP and UnpackerResource are enabled, it doesn't work! With those to there, when you request / you get a 404 and the server logs:
> rg.apache.cxf.jaxrs.utils.JAXRSUtils findTargetMethod
> WARNING: No operation matching request path "/" is found, Relative Path: /, HTTP Method: GET, ContentType: */*, Accept: */*,. Please enable FINE/TRACE log level for more details.
>
> However, if you comment out those two endpoint classes from the sf.setResourceClasses() call in TikaServerCLI, then the request gets correctly routed to the welcome page.
>
> Neither MetadataEP nor UnpackerResource have a path that clashes, so I've no idea why having them active stops / working. Any ideas?
I am having a look quickly whilst traveling but from peeking at the code it looks like the following to me:
* MetadataEP - we have no @Produces which will fail in the introspection code on the TikaWelcome class
* UnpackerResource - as there is no class level @Path I am suspecting this is clashing with the TikaWelcome as it builds the routes with the method ones being place on the root as well.
I don’t have time to test it just now but I wonder what would happen if you reordered TikaWelcome to the top about UnpackerResource? If my hunch is correct it should make the / request work using the self-generated documentation.
> (Patch below if you want to try disabling them yourself to investigate)
>
> Nick
>
Cheers,
Dave
Re: JAXRS, endpoints and a / welcome page - any ideas why it's
broken?
Posted by "Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>.
+1 to Nick's suggestion and let's see what our users say. :)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-5th floor
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Nick Burch <ap...@gagravarr.org>
Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
Date: Monday, May 19, 2014 1:07 PM
To: "dev@tika.apache.org" <de...@tika.apache.org>
Subject: Re: JAXRS, endpoints and a / welcome page - any ideas why it's
broken?
>On Mon, 19 May 2014, Sergey Beryozkin wrote:
>>> I think it might be good to push them into a common path prefix. Though
>>> /unpack/unpacker seems a bit unwieldy...
>>
>> If we do introduce "/unpack" then may be we can drop "/unpacker", and
>>have
>> two methods with "/" & "/all", so users will work with "/unpacker" &
>> "/unpack/all"
>
>Won't /unpack/{id} clash with /unpack/all/{id}, or is that safe?
>
>>>> 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 suppose worst case we could create an abstract parent, put most of
>>>the
>>> logic there, then have two classes one per method?
>>
>> Introducing the inheritance will not change the target URI
>
>Nope, but it will let us specify the path on the class so avoid the /
>clash we have now. Not so clean though...
>
>>> Maybe we should post to users@, and see if anyone says they do?
>>
>> Sounds good, please ask or I can do it, let me know please
>
>As our jaxrs guru, can you? :)
>
>Nick
Re: JAXRS, endpoints and a / welcome page - any ideas why it's
broken?
Posted by "Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>.
Thanks Sergey!
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-5th floor
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Sergey Beryozkin <sb...@gmail.com>
Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
Date: Tuesday, May 20, 2014 5:19 AM
To: "dev@tika.apache.org" <de...@tika.apache.org>
Subject: Re: JAXRS, endpoints and a / welcome page - any ideas why it's
broken?
>On 19/05/14 18:07, Nick Burch wrote:
>> On Mon, 19 May 2014, Sergey Beryozkin wrote:
>>>> I think it might be good to push them into a common path prefix.
>>>>Though
>>>> /unpack/unpacker seems a bit unwieldy...
>>>
>>> If we do introduce "/unpack" then may be we can drop "/unpacker", and
>>> have two methods with "/" & "/all", so users will work with
>>> "/unpacker" & "/unpack/all"
>>
>> Won't /unpack/{id} clash with /unpack/all/{id}, or is that safe?
>
>It is safe indeed
>
>>
>>>>> 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 suppose worst case we could create an abstract parent, put most of
>>>>the
>>>> logic there, then have two classes one per method?
>>>
>>> Introducing the inheritance will not change the target URI
>>
>> Nope, but it will let us specify the path on the class so avoid the /
>> clash we have now. Not so clean though...
>>
>>>> Maybe we should post to users@, and see if anyone says they do?
>>>
>>> Sounds good, please ask or I can do it, let me know please
>>
>> As our jaxrs guru, can you? :)
>>
>LOL, anyone who has spent a bit of time with JAX-RS qualifies as an
>expert :-).
>
>I've just asked at the users list
>
>Cheers, Sergey
>
>
>> Nick
>
>
Re: JAXRS, endpoints and a / welcome page - any ideas why it's
broken?
Posted by "Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>.
I got it :)
Sent from my iPhone
> On Jun 2, 2014, at 12:35 PM, "Nick Burch" <ap...@gagravarr.org> wrote:
>
> On Tue, 20 May 2014, Sergey Beryozkin wrote:
>>>>> Maybe we should post to users@, and see if anyone says they do?
>>>> Sounds good, please ask or I can do it, let me know please
>>> As our jaxrs guru, can you? :)
>>
>> I've just asked at the users list
>
> Based on the silence, I don't think the unpacker resource is very widely used. As such, I think we should be fine to push it to the new URL pattern as discussed, and mention it in change logs / release notes / etc
>
> Who wants to do the honours? :)
>
> Nick
Re: JAXRS, endpoints and a / welcome page - any ideas why it's
broken?
Posted by Nick Burch <ap...@gagravarr.org>.
On Tue, 20 May 2014, Sergey Beryozkin wrote:
>>>> Maybe we should post to users@, and see if anyone says they do?
>>>
>>> Sounds good, please ask or I can do it, let me know please
>>
>> As our jaxrs guru, can you? :)
>
> I've just asked at the users list
Based on the silence, I don't think the unpacker resource is very widely
used. As such, I think we should be fine to push it to the new URL pattern
as discussed, and mention it in change logs / release notes / etc
Who wants to do the honours? :)
Nick
Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 19/05/14 18:07, Nick Burch wrote:
> On Mon, 19 May 2014, Sergey Beryozkin wrote:
>>> I think it might be good to push them into a common path prefix. Though
>>> /unpack/unpacker seems a bit unwieldy...
>>
>> If we do introduce "/unpack" then may be we can drop "/unpacker", and
>> have two methods with "/" & "/all", so users will work with
>> "/unpacker" & "/unpack/all"
>
> Won't /unpack/{id} clash with /unpack/all/{id}, or is that safe?
It is safe indeed
>
>>>> 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 suppose worst case we could create an abstract parent, put most of the
>>> logic there, then have two classes one per method?
>>
>> Introducing the inheritance will not change the target URI
>
> Nope, but it will let us specify the path on the class so avoid the /
> clash we have now. Not so clean though...
>
>>> Maybe we should post to users@, and see if anyone says they do?
>>
>> Sounds good, please ask or I can do it, let me know please
>
> As our jaxrs guru, can you? :)
>
LOL, anyone who has spent a bit of time with JAX-RS qualifies as an
expert :-).
I've just asked at the users list
Cheers, Sergey
> Nick
Re: JAXRS, endpoints and a / welcome page - any ideas why it's
broken?
Posted by Nick Burch <ap...@gagravarr.org>.
On Mon, 19 May 2014, Sergey Beryozkin wrote:
>> I think it might be good to push them into a common path prefix. Though
>> /unpack/unpacker seems a bit unwieldy...
>
> If we do introduce "/unpack" then may be we can drop "/unpacker", and have
> two methods with "/" & "/all", so users will work with "/unpacker" &
> "/unpack/all"
Won't /unpack/{id} clash with /unpack/all/{id}, or is that safe?
>>> 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 suppose worst case we could create an abstract parent, put most of the
>> logic there, then have two classes one per method?
>
> Introducing the inheritance will not change the target URI
Nope, but it will let us specify the path on the class so avoid the /
clash we have now. Not so clean though...
>> Maybe we should post to users@, and see if anyone says they do?
>
> Sounds good, please ask or I can do it, let me know please
As our jaxrs guru, can you? :)
Nick
Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
On 19/05/14 13:50, Nick Burch wrote:
> On Mon, 19 May 2014, Sergey Beryozkin wrote:
>> 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".
>
> I think it might be good to push them into a common path prefix. Though
> /unpack/unpacker seems a bit unwieldy...
If we do introduce "/unpack" then may be we can drop "/unpacker", and
have two methods with "/" & "/all", so users will work with "/unpacker"
& "/unpack/all"
>
>> 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 suppose worst case we could create an abstract parent, put most of the
> logic there, then have two classes one per method?
Introducing the inheritance will not change the target URI
>
>> 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.
>
> Maybe we should post to users@, and see if anyone says they do?
Sounds good, please ask or I can do it, let me know please
Thanks, Sergey
>
> Thanks
> Nick
Re: JAXRS, endpoints and a / welcome page - any ideas why it's
broken?
Posted by Nick Burch <ap...@gagravarr.org>.
On Mon, 19 May 2014, Sergey Beryozkin wrote:
> 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".
I think it might be good to push them into a common path prefix.
Though /unpack/unpacker seems a bit unwieldy...
> 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 suppose worst case we could create an abstract parent, put most of the
logic there, then have two classes one per method?
> 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.
Maybe we should post to users@, and see if anyone says they do?
Thanks
Nick
Re: JAXRS, endpoints and a / welcome page - any ideas why it's
broken?
Posted by "Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>.
Hi Guys,
Looking forward to the feedback from the user community. I'm going to work
up a patch that rethinks and tries to standardize some of the endpoints and
a proposal for it.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-5th floor
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Sergey Beryozkin <sb...@gmail.com>
Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
Date: Monday, May 19, 2014 7:42 AM
To: "dev@tika.apache.org" <de...@tika.apache.org>
Subject: Re: JAXRS, endpoints and a / welcome page - any ideas why it's
broken?
>Hi Chris,
>On 16/05/14 16:31, Chris Mattmann wrote:
>> Hi Guys,
>>
>> Some thoughts here:
>>
>>
>> -----Original Message-----
>>
>> From: Nick Burch <ap...@gagravarr.org>
>> Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
>> Date: Wednesday, May 14, 2014 6:22 AM
>> To: "dev@tika.apache.org" <de...@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
>
>
>>
>>
>
Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Chris,
On 16/05/14 16:31, Chris Mattmann wrote:
> Hi Guys,
>
> Some thoughts here:
>
>
> -----Original Message-----
>
> From: Nick Burch <ap...@gagravarr.org>
> Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
> Date: Wednesday, May 14, 2014 6:22 AM
> To: "dev@tika.apache.org" <de...@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
>
>
Re: JAXRS, endpoints and a / welcome page - any ideas why it's
broken?
Posted by Chris Mattmann <ma...@apache.org>.
Hi Guys,
Some thoughts here:
-----Original Message-----
From: Nick Burch <ap...@gagravarr.org>
Reply-To: "dev@tika.apache.org" <de...@tika.apache.org>
Date: Wednesday, May 14, 2014 6:22 AM
To: "dev@tika.apache.org" <de...@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.
Cheers,
Chris
Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
Re: JAXRS, endpoints and a / welcome page - any ideas why it's
broken?
Posted by Nick Burch <ap...@gagravarr.org>.
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?
> 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?
> 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?
Nick
Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Nick,
Sorry for a delay, just back from a short break,
On 07/05/14 10:48, Nick Burch wrote:
> Hi All
>
> One for our JAXRS gurus here...
>
> At ApacheCon, we came up with the idea of having a welcome page on the
> Tika Server, so that we could point people to it to try Tika, and let
> them discover what it offered. Based on that, and the mailing list
> discussions, we raised TIKA-1269.
>
> (Related to that is TIKA-1270, which aims to add endpoints similar to
> the --list- ones the Tika CLI has, which is in progress)
>
> While we work out the best way to allow users to discover + learn about
> + try the various REST endpoints on TIKA-1269, I've started with
> something basic. This is done with the simple TikaWelcome class, which
> has a Path of /
>
> The problem - when the MetadataEP and UnpackerResource are enabled, it
> doesn't work! With those to there, when you request / you get a 404 and
> the server logs:
> rg.apache.cxf.jaxrs.utils.JAXRSUtils findTargetMethod
> WARNING: No operation matching request path "/" is found, Relative Path:
> /, HTTP Method: GET, ContentType: */*, Accept: */*,. Please enable
> FINE/TRACE log level for more details.
>
> However, if you comment out those two endpoint classes from the
> sf.setResourceClasses() call in TikaServerCLI, then the request gets
> correctly routed to the welcome page.
>
> Neither MetadataEP nor UnpackerResource have a path that clashes, so
> I've no idea why having them active stops / working. Any ideas?
>
> (Patch below if you want to try disabling them yourself to investigate)
>
UnpackerResource has no Path annotation so it is defaulted to "/".
In JAX-RS 1.1 if we have say 2 root resources with the same path then
the selection is unpredictable.
AFAIK all JAX-RS 1.1 stacks have the extensions to address this issue
and this is the CXF one:
http://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-Customselectionbetweenmultipleresources
JAX-RS 2.0 fixes this issue, I'll be working on upgrading Tika to CXF
3.0 shortly, and it will work as expected. 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.
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
Cheers, Sergey
> Nick
>
>
> Index: src/main/java/org/apache/tika/server/TikaServerCli.java
> ===================================================================
> --- src/main/java/org/apache/tika/server/TikaServerCli.java (revision
> 1592656)
> +++ src/main/java/org/apache/tika/server/TikaServerCli.java (working
> copy)
> @@ -92,10 +92,20 @@
> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> // Note - at least one of these stops TikaWelcome matching on /
> // This prevents TikaWelcome acting as a partial solution to
> TIKA-1269
> - sf.setResourceClasses(MetadataEP.class, MetadataResource.class,
> - TikaResource.class, UnpackerResource.class,
> - TikaDetectors.class, TikaMimeTypes.class,
> - TikaVersion.class, TikaWelcome.class);
> +// sf.setResourceClasses(MetadataEP.class, MetadataResource.class,
> +// TikaResource.class, UnpackerResource.class,
> +// TikaDetectors.class, TikaMimeTypes.class,
> +// TikaVersion.class, TikaWelcome.class);
> + sf.setResourceClasses(
> +// MetadataEP.class,
> + MetadataResource.class,
> + TikaResource.class,
> +// UnpackerResource.class,
> + TikaDetectors.class,
> + TikaMimeTypes.class,
> + TikaVersion.class,
> + TikaWelcome.class
> + );
>
> List<Object> providers = new ArrayList<Object>();
> providers.add(new TarWriter());
>