Thanks for your interest Paul.
I would definitely love to request for an enhancement. But before that, just
a little clarification.
Just gone through the spec for the resource method resolution (section
3.7.2-3 of jax_rs-1.1 spec). In the 'c' section (3.7.2-3(c)), it was
mentioned like:
(c) The request is dispatched to the first Java method in the set
>
Though the resolution when there is possibility of inheritance are not
clearly mentioned, if I understood correct, when there are multiple methods
matched for a given request we can consider the first of the matched methods
(sorted in a particular fashion using the procedure described in
3.7.2-3(b)).
So, when both (or may be more) methods had exact consume & produce values
the above said sorting is not much effective.
With this,
case-1: When all the matched methods are declared in a single resource
(don't know why one want to declare like this?): may be we can consider the
first declared matching method
case-2: When matched methods are declared through inheritance (one in parent
and other in child resource): ( this is our case here), may be we can
consider the more specific one, like, child method when child resource is
accessed. If the child resource is having multiple exact matches in it too,
then it can be treated as case-1.
Please review and give comments.
ManiKanta G
twitter.com/ManiKantaG
On Tue, Sep 7, 2010 at 12:51 PM, Paul Sandoz <Paul.Sandoz_at_oracle.com> wrote:
>
> On Sep 7, 2010, at 8:32 AM, ManiKanta G wrote:
>
> Thanks Paul,
>>
>>
>>
>> No. Jersey is detecting an error with the ChildResource class and will not
>> deploy the application because of that error.
>>
>>
>> Oh, okay. When I start the server it is not listing any exception, but
>> only when I invoked the resources then only those exceptions were shown.
>> Then I thought the about this doubt.
>>
>>
> I think what is happening is lazy initialization of the servlet.
> Initialization occurs on the first request that matches the servlet URL
> pattern.
>
>
>
> But it'll be nice, when some ambiguities like these arise, if the
>> resolution is based given some more priority to the the actual resource
>> matching to a specific request. I mean, when accessing the /child giving the
>> preference to the Child' method (which is having the @Produces same as its
>> parent method). And stopping the parent resource from accessing when there
>> is some conflict with some child resource is not desirable I believe, at
>> least for me, if not every one :).
>>
>
> As i said it is a deployment error, lazy initialization is giving the
> illusion of different behaviour.
>
>
>
> Is this enforced by JAX-RS. Sorry, I didn't see this behavior any where
>> though I've gone through the spec.
>>
>>
> The spec does not explicitly talk about conflicts, we could improve that
> part. Note that such conflicts can also occur on public methods defined on
> the same class.
>
> The spec states that resource methods are public methods of a resource
> class, hence any public methods from a super class are included and treated
> as one set. There is no sort order for resource methods based on the class
> hierarchy, so there is ambiguity on which method to select. I suppose we
> could support some form of enhancement here. Would you like to log an issue
> against the JAX-RS API here:
>
> https://jsr311.dev.java.net/servlets/ProjectIssues
>
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>