Martin Grotzke wrote:
>> I see. I am not sure @Resource is the right thing to use in all
>> cases. Note that for Jersey injected stuff on fields we stopped using
>> @Resource and switched to using @Context because we were not
>> conforming to @Resource with regard to it's use as it pulls in other
>> EE 5 stuff (like JNDI).
>>
>> Hmmm... i wonder if we could reuse @Context instead of created a new
>> annotation?
> So instances for @Context-annotated fields or method arguments would be
> pulled from the ComponentProvider?
>
Yes, if Jersey does not know what to do with them.
> ResourceProvider sounds well (or ResourceFactory?). Hmm, just thinking
> again about this - it's not only about resources (resource classes in
> the REST world), but one might also pull other dependencies from the
> ComponentProvider using this, right? E.g. some prototyped (perRequest)
> scoped bean that is instantiated by the IoC-container (I don't have a
> good example, sorry). So perhaps it should not be named too resourceFul,
> but perhaps s.th. like BeanProvider or BeanFactory?
> What would be the difference between the ComponentProvider and the
> ResourceProvider/BeanFactory? Just to get a better idea of what it
> is... :)
>
"ResourceProvider" would only return instances of resource classes.
There is some additional functionality in the management of resource
class life-cycle that is not available when using ComponentProvider e.g.
the per-request life-cycle chooses the constructor and constructor
parameters are extracted from the HTTP request and injected as method
parameters. Someone may develop their own provider that stores resource
classes on the servlet HttpSession.
If a general instance of something is required then perhaps it is best
to use existing IoC mechanisms ? (in addition to allows injection of
ComponentProvider).
BTW feel free to use the Jersey wiki [1] to capture the Spring
requirements you noted in a previous email.
> Just to throw in an alternative for the existing ResourceProvider: what
> about ScopedResourceProvider or ScopedResourceFactory?
>
Thinking some more the *Provider fits naming scheme with the SPI stuff
that provides to the Jersey runtime. I think anything that the developer
would commonly use would be better named to something else, for example
ResourceContext would be a better fit:
public interface ResourceContext {
<T> T getResource(Class<T> c);
}
Paul.
[1]
http://wikis.sun.com/display/Jersey/IoC+utilities
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109