On Sep 8, 2010, at 9:15 AM, ManiKanta G wrote:
>
> 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.
>
Correct, it is ambiguous, because "public methods" means "all the
public member methods of the class or interface represented by this
Class object, including those declared by the class or interface and
those inherited from superclasses and superinterfaces." as defined by
Class.getMethods().
http://download.oracle.com/javase/6/docs/api/java/lang/Class.html#getMethods%28%29
> 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
>
Method order is undefined, so we cannot do that:
http://download.oracle.com/javase/6/docs/api/java/lang/Class.html#getMethods%28%29
"The elements in the array returned are not sorted and are not in any
particular order."
> 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.
>
We can consider a second sort key associated with the class hierarchy.
Please log an issue to capture your idea and it can be considered for
any JAX-RS 2.0 effort.
Paul.
> 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
>
>