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.