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.mattm...@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 <sberyoz...@gmail.com> Reply-To: "dev@tika.apache.org" <dev@tika.apache.org> Date: Monday, May 19, 2014 7:42 AM To: "dev@tika.apache.org" <dev@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 <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 > > >> >> >
