users@jsr311.java.net

RE: Re: Inherited Path

From: Adam Karl <akarl_at_nighthawkrad.net>
Date: Mon, 4 Feb 2008 10:15:42 -0800

I mean the client application. One of my first usages I have going is a
Java client that just needs Interfaces for my "services". I create
proxy classes for the Interfaces thus making the interface something I
can program and compile against. Since I use generic annotations in the
stub Interfaces, I can call these plain old Java services (POJS!).
There is no need for my client applications to know how communication is
happening. It ends up working very much like RMI. In fact, full on
annotation extending would be useful as well but I won't argue for that
here...too much. If anyone else is looking for a workaround, you can
get around the fact that annotations are not inherited from Interfaces.
You just have to loop through all of a given class's implemented
interfaces and look for the annotations there. Its very simple if you
don't need to handle conflicts.

No problem on finding issues. Next time I'll actually log it to the
appropriate place instead of working around it and hoping someone else
finds it :)

Best Regards,
Adam Karl

-----Original Message-----
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Monday, February 04, 2008 12:02 PM
To: users_at_jsr311.dev.java.net
Subject: Re: Inherited Path

Adam Karl wrote:
> I would much rather put these annotations in an Interface as Bill
> suggested but as I understand it, Java itself has very limited support

> for annotation inheritance from Interfaces.

Yes, annotation inheritance is limited to @Inherited annotations on
super classes.


< This is a perfect example
> of where inheritance of annotations from Interfaces would be useful
> since a consumer of my services will not be able to see the Abstract
> class, only an Interface.

When you say 'consumer' do you mean the implementor of the interface?
the Jersey runtime that processes the instance of the interface? or the
client making the HTTP requests?

I am guessing the first one but what is throwing me is what you mean by
'service' as i tend to think of that as a 'Web service', blinkered
vision i guess :-)


> I've gotten around this for the time being by
> having the Interfaces for these services add an @Service annotation.
> @Service is almost identical to @Path, I just changed the name because
> Jersey's default classpath resource loader seemed to be attempting to
> instantiate the Interfaces if I used @Path.
>

Thanks for finding this issue. I have fixed things in the latest build,
such interfaces and abstract classes are now ignored (warnings are
produced).

Paul.

> Best Regards,
> Adam Karl
>
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Saturday, February 02, 2008 4:27 PM
> To: users_at_jsr311.dev.java.net
> Subject: Re: Inherited Path
>
> I do think you need some inheritance rules though. For example, in
the
> EJB 3 specification you may override a business method in a subclass
and
> provide different metadata.
>
> I also wish that JAX-RS annotations could be extracted from an
> implemented interface. i.e.:
>
> public class StoreBean implements ShoppingStore {
>
> public Book getBook(int id) {...}
> }
>
> @Path("/shopping")
> public interface ShoppingStore {
>
> @GET @Path("bookstore/books/{id}")
> public Book getBook(@PathParam("id") int id); }
>
> This would be very similar to the EJB3/JAX-WS integration style.
>
> Marc Hadley wrote:
>> 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
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> ---------------------------------------------------------------------
> 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