Hi Adam,
Sorry there was a bug in my example it should be:
@Path("/")
// This class is not abstract!!
public class BootService
{
@Path("{serviceClassName}")
public AbstractService getServiceClass(
@PathParam("serviceClassName") String serviceClassName)
{
// get the impl from the serviceClassName
AbstractService as = ...
return as;
}
...
}
In terms of the inheritance of @Path, it was never intended that it
should be @Inherited as part of the JAX-RS API. So from that perspective
there is no gap between JAX-RS and the Jersey RI. But there is bug in
trying to instantiate interfaces and abstract classes which i have fixed
in the latest build, such classes are now ignored and warnings are produced.
In terms of inheritance rules in general we definitely need to nail that
down in the specification.
Paul.
Adam Karl wrote:
> 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