Hi Martin,
Martin Grotzke wrote:
> Hi Paul,
>
> I just continued with parts of the spring integration.
>
> The ResourceContext is implemented now, so that resource classes can
> pull dependencies from it. The Resourcecontext is injected if the field
> is annotated with @Context.
>
Great.
> Concerning case 2 (injecting external dependencies based on some
> annotation) please see below..
>
> On Wed, 2008-03-26 at 12:01 +0100, Paul Sandoz wrote:
>> 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.
> I just tried to implement this in the spring branch, then I realized,
> that the ComponentProvider.getInstance expects not only the type/class,
> but also the scope - which is not known at this place, as it's
> completely left to the application which scope the external dependency
> has.
>
> What would you suggest as solution for this? Would you say the
> ComponentProvider should get another getInstance with just the class to
> support this case?
>
Hmm... perhaps we need to be explicit on three types of scope:
- per web-application
- per request
- don't care
Jersey can inform when it needs a component of a given scope (e.g. for
resource classes or a message body reader/writer) or inform it does not
care what the scope is.
But i guess there could be issues if the scope of the thing to inject on
is not compatible with the scope of the thing that is being injected,
e.g. a singleton resource with a per-request thing being injected. Not
sure what we can do about this except say "developer beware!", and in
such cases one should use the direct IoC injection mechanisms if possible.
> You can have a look at WebApplicationImpl.injectResources as it's
> handled right now, this is just a temporary solution to test if it
> works, perhaps you want to take a look at it.
>
For general field injection i think you have chosen the right place.
General comment, for errors in the runtime we should throw a
ContainerException (rather than RuntimeException) so we know it is an
error associated with the JAX-RS runtime.
Paul.
> Cheers,
> Martin
>
>
>
>>
>>> 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