JAXRS, endpoints and a / welcome page - any ideas why it's broken?

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Nick Burch-2
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());

Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

David Meikle
Hi Nick,

On 7 May 2014, at 12:48, Nick Burch <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Sergey Beryozkin
In reply to this post by Nick Burch-2
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());
>


Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Nick Burch-2
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
Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Sergey Beryozkin
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

Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Chris Mattmann
In reply to this post by Nick Burch-2
Hi Guys,

Some thoughts here:


-----Original Message-----

From: Nick Burch <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Wednesday, May 14, 2014 6:22 AM
To: "[hidden email]" <[hidden email]>
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


Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Sergey Beryozkin
Hi Chris,
On 16/05/14 16:31, Chris Mattmann wrote:

> Hi Guys,
>
> Some thoughts here:
>
>
> -----Original Message-----
>
> From: Nick Burch <[hidden email]>
> Reply-To: "[hidden email]" <[hidden email]>
> Date: Wednesday, May 14, 2014 6:22 AM
> To: "[hidden email]" <[hidden email]>
> 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


>
>

Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Nick Burch-2
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
Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Sergey Beryozkin
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

Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Nick Burch-2
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
Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Sergey Beryozkin
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


Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Mattmann, Chris A (3010)
In reply to this post by Nick Burch-2
+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: [hidden email]
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, May 19, 2014 1:07 PM
To: "[hidden email]" <[hidden email]>
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

Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Mattmann, Chris A (3010)
In reply to this post by Sergey Beryozkin
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: [hidden email]
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Tuesday, May 20, 2014 5:19 AM
To: "[hidden email]" <[hidden email]>
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Mattmann, Chris A (3010)
In reply to this post by Sergey Beryozkin
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: [hidden email]
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 <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Monday, May 19, 2014 7:42 AM
To: "[hidden email]" <[hidden email]>
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 <[hidden email]>
>> Reply-To: "[hidden email]" <[hidden email]>
>> Date: Wednesday, May 14, 2014 6:22 AM
>> To: "[hidden email]" <[hidden email]>
>> 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
>
>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Nick Burch-2
In reply to this post by Sergey Beryozkin
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
Reply | Threaded
Open this post in threaded view
|

Re: JAXRS, endpoints and a / welcome page - any ideas why it's broken?

Mattmann, Chris A (3010)
I got it :)

Sent from my iPhone

> On Jun 2, 2014, at 12:35 PM, "Nick Burch" <[hidden email]> 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