HI Alan,
Hi Alex,
Unfortunately this is not currently possible. Once the request path
has been consumed then it is resource methods that will be matched,
rather than resource methods and/or a sub-resource locator with an
empty path. This will require a change to the matching algorithm.
It may be possible to modify such that if a resource method is not
matched and if a sub-resource locator with an empty path is present
then that is invoked i.e. any resource methods should take precedence.
Can you log an issue?
Paul.
On May 26, 2010, at 12:08 PM, Alex Treppass wrote:
> Currently the @Path() annotation cannot be used to annotate
> methods that return delegates. We believe that a change would
> enhance the do one thing and do it well mantra of Agile programming.
>
> (See attached web application)
>
> The ManageThings class is a class that communicates with some
> underlying system. It knows the format of the system and how to
> convert the data into the representation that is required by the web
> service. This functionality will always be required by the web
> service there is no need to configure this bit at runtime. The
> proposed architecture is that (for each request) this class passes
> the retrieved things to delegate classes.
>
> The IListThings class is a delegate. The role of IListThings is to
> process the things to match the user request. The requirements of
> the processing may be different for different installations of the
> application, and may change over time. We would like these
> processing options to be configurable at runtime. There are two sub
> classes of IListThings one which returns the things unordered, and
> one which sorts the things by id (ascending or descending). The
> delegate is created by a factory the factory may be configured at
> runtime. This allows the available formatting options to be chosen
> at runtime.
>
> Problem: ManageThings cannot declare an empty path for methods that
> return delegate objects.
>
> This means that we are required to put the request to list things
> at /things/list. We would prefer to put the request at /things
> because that looks like a traditional directory structure and will
> be better understood by the end user.
>
> p.s. Another use of the delegate in our application is to change
> which method request types (GET, POST, etc.) are available.
>
> <
> emptyPathDelegate
> .zip
> >---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net