On Jul 1, 2010, at 4:06 PM, James Strachan wrote:
> On 1 July 2010 14:32, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>> Hi James,
>>
>> So would something like the following work for you:
>>
>> def getElement(@<I do not know what to call this!> subResource:
>> Element) =
>> { ... }
>>
>> ?
>
> Sure!
>
>> That would be really easy to support because we can write an
>> InjectableProvider that defers to ResourceContext. I can even send
>> one in
>> the email in addition to adding it to the workspace so that one can
>> use it
>> with a stable version.
>>
>> But as you can tell i am having a naming problem :-) any suggestions?
>
> Yeah, I wasn't sure what to call it either :)
>
> How about...
>
> def getElement(@SubResource e: Element) = ...
>
I thought of that too, but may not be accurate as a sub-resource could
ask for a reference to the root resource using the same mechanism.
@ResourceRef?
still don't like it much but...
Would you mind logging an issue, since i will be away i am not sure i
will get to this today and may forget when i get back!
>
> As an aside - I hit another related thing today. One of the awesome
> things about JAXRS is its so modular; drop a bunch of jars together
> with jaxrs beans in them and provided your URIs don't clash, you've an
> extensible web app & REST API.
>
> However I've found I often want to extend an existing sub resource in
> a modular way so that adding a jar to a web app can extend/enhance a
> web app/REST API.
>
> e.g. camel-web is a web console for Camel which has a root resource &
> then a rather big tree of sub resources. If folks drop in the
> activemq-camel-web jar, it would be nice to be able to replace some of
> the endpoints with derived sub resource classes which offer more
> representations or behaviour with knowledge of activemq etc.
>
> If the application code is explicitly doing "new Element(id)" then you
> have to go through the whole resource chain from root to sub resource
> and overriding them all.
>
> If jersey is instantiating the sub resource we could let the framework
> detect a sub class being on the classpath (if its in the set of
> packages scanned by jersey) then a new DerivedElement class could be
> injected in the above example.
>
> e.g. in a base module...
>
> def getElement(@SubResource e: Element) = ...
>
>
> could return an instance of "Element".
>
> Add derived.jar to the classpath and jersey might create a
> "DerivedElement" instead.
>
> (There could be issues if there are multiple derivations of the class
> on the classpath though :)
>
Do you think it might be better in this case to use Guice? A binding
could declare that when a reference to Element is requested it will be
an implementation of DerivedElement. This would avoid issues of
multiple derivations and also avoid the tricky bit of Jersey having to
scan for derived classes.
I think that should actually work with @SubResource given the way
Jersey will ask Guice for a reference.
Paul.