Yes you do understand what I would like to do. I would like the path
for these endpoints, which amount to classes, to be a pattern based on
the class's canonical name. In fact, I only expose a Post method that
dispatches the request to the appropriate method within the class. This
eliminates the need for my implementation classes to know how they are
being exposed to the outside world. All they need to do is to extend my
AbstractService class.
What you propose seems ok from the perspective of JSR311 but I think
there may be a bug in how Jersey actually implements this. This isn't
really the appropriate place to discuss a possible Jersey bug but I do
want to be clear on what JSR311 intends so that I can log a proper bug
to Jersey if one exists. When I attempt to use Jersey's servlet
classpath loader, it looks for the @Path annotation on the class. If it
doesn't find that annotation, it doesn't think the class contains
resources. Using this method I get an endpoint in my abstract class
which of course produces an instantiation exception when you try to
access it. Now if @Path was @Inherited Jersey would detect my
implementation class. It should probably also not create an endpoint
directly into an Abstract class.
So, I guess I'm looking for confirmation that there is a gap between
JSR311 and Jersey here.
Best Regards,
Adam Karl
-----Original Message-----
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Monday, February 04, 2008 4:45 AM
To: users_at_jsr311.dev.java.net
Subject: Re: Inherited Path
Adam Karl wrote:
> I'm actually already doing this using the latest Jersey code which
> seems to handle finding the inherited @GET methods so, at least using
> the Jersey implementation the method annotations aren't a concern.
Yes, that is correct, annotated methods on super classes (abstract or
otherwise) are supported (same for injection and generic types that are
request entities).
> Its
> really just the class's @Path annotation that is causing me to force
> users of my Abstract class to know about how their methods are being
> exposed.
>
The reason why @Inherited is not supported on @Path is because it can
easily create a runtime conflict for two or more root resources, with
the same @Path value, when a request URI path matches the @Path value.
In the example you presented:
@Path("{serviceClassName}")
public abstract class AbstractService
{
public AbstractService getServiceClass(
@PathParam("serviceClassName") String serviceClassName)
{
return this;
}
...
}
How is the 'getServiceClass' called? Is that method a sub-locator
method? I get the impression you want to return a specific resource
instance based on the value of 'serviceClassName'.
One way to 'divorce' the parent path from something is to use a
sub-locator:
@Path("/")
public abstract class BootService
{
@Path("{serviceClassName}")
public AbstractService getServiceClass(
@PathParam("serviceClassName") String serviceClassName)
{
// get the impl from the serviceClassName
AbstractService as = ...
return as;
}
...
}
Resource classes returned by sub-locator methods do not require that
they be annotated with @Path, if they are it is ignored as the @Path on
the sub-locator method takes precedence. Thus one can support
'polymorphic' resources each with their own sub-hierarchy separated from
the super-hierarchy.
Does that meet your requirements or have i completely misunderstood what
you want to do?
Paul.
>
> Best Regards,
> Adam Karl
>
> -----Original Message-----
> From: Marc.Hadley_at_Sun.COM [mailto:Marc.Hadley_at_Sun.COM]
> Sent: Friday, February 01, 2008 5:53 PM
> To: users_at_jsr311.dev.java.net
> Subject: Re: Inherited Path
>
> IIRC, @Inherited only applies to classes so, even if @Path was
> inherited, any annotations on the abstract service class methods
> (@GET, @ProduceMime etc) wouldn't be inherited and a subclass would
> appear to unannotated except for the class-level annotations.
>
> Marc.
>
>
> On Feb 1, 2008, at 12:24 PM, Adam Karl wrote:
>
>> Here is my situation. I would like to define an abstract Service
>> class such as below. Now when the real service classes extend my
>> service class, I would like them to inherit the path annotation.
>> This allows the service classes to know nothing about the
>> implementation of my service architecture other than the fact that
>> they should be extending my abstract service class. Currently, the
>> @Path annotation is not @Inherited so this doesn't work for me. Is
>> there a reason why @Path cannot be @Inherited?
>>
>> @Path("{serviceClassName}")
>> public abstract class AbstractService { public AbstractService
>> getServiceClass(@PathParam("serviceClassName") String
>> serviceClassName)
>> {
>> return this;
>> }
>> ...
>> }
>>
>> ____________________________________________
>> Adam Karl
>> Nighthawk Radiology
>> Software Engineer
>>
>> Phone: +1 414 220 4295 ext-8319
>> Email: akarl_at_nighthawkrad.net
>>
>>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
For additional commands, e-mail: users-help_at_jsr311.dev.java.net