On Mar 25, 2008, at 2:40 PM, Martin Grotzke wrote:
> On Tue, 2008-03-25 at 13:49 +0100, Paul Sandoz wrote:
>> On Mar 25, 2008, at 8:43 AM, Martin Grotzke wrote:
>>
>>> Hi,
>>>
>>> as this topic in the meantime is spread over a lot of postings, I
>>> just
>>> want to sum up what I would suggest for spring integration.
>>> Unfortunately I cannot speak for other IoC containers like guice,
>>> but
>>> perhaps these approaches could be aligned.
>>>
>>> - Basically Pauls SpringComponentProvider should be used (with
>>> slight
>>> modifications), so that resource classes could be configured in
>>> spring and additional spring features like AOP might be used.
>>> Spring 2.5 features like annotation based DI are fully available
>>> with
>>> this solution.
>>> - Additionally an @Inject annotation should be provided, so that not
>>> each resource class has to be configured in the
>>> applicationContext.xml
>>> but can get other spring beans injected.
>>> This annotation should also be available for resource method
>>> parameters.
>>
>> Interesting, i think that could be a good way to experiment for
>> resource method and constructor parameters as well.
>>
>> Ideally it would be nice to avoid creating such a specific annotation
>> and reuse an existing one provided by the IoC to make integration
>> smoother.
> With IoC you mean s.th. like spring-2.0 or spring-2.5?
> Then the @Inject would be provided for spring-2.0 users (by the
> jersey-spring contrib package), and for spring 2.5 the @Resource (IIRC
> this is the one supported) should be supported accordingly...?
>
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?
BTW a Jersey @Injected or @Context should be very easy to support as
we already have a simple general extraction mechanism in place.
>> But i think we need some more experience on integration and
>> use of an annotation is the best way to make progress.
>>
>>
>>> - Also provide an @Autowire annotation (with target type) to provide
>>> autowiring for spring 2.0 users
>>>
>>
>> I think providing such annotations for backwards compatibility could
>> be very useful and helpful to 2.0 users. If there are any priorities
>> involved then personally i think we should first concentrate on 2.5
>> e.g. if we want to get this into the 0.7 release.
> AFAICS especially for spring-2.5 there's nothing to do right now -
> besides the support of method parameter injection (that should not
> depend on spring-2.5).
>
> I already wrote some @Autowire annotation and extended the
> SpringComponentProvider (also based on James autowiring SCP), this was
> very little work...
>
OK :-)
>>
>>
>>>
>>> Open issues:
>>> - The mentioned injection of spring dependencies for method
>>> parameters.
>>> This is needed if an initialized subresource shall be returned
>>> from a
>>> root resource method and features provided by the IoC-container
>>> (like
>>> e.g. AOP) shall be used.
>>> I'd prefer to use some @SpringBean/_at_Inject annotation for this
>>> kind
>>> of injection as already mentioned above, but AFAICS this is right
>>> now
>>> not possible.
>>>
>>
>> Two possible solutions:
>>
>> 1) Jersey already allows the returning of a Class instance from a
>> sub-
>> locator;
>>
>> @Path("sub") Class<Foo> getFooClass() { return Foo.class; }
>>
>> 2) Support injection of a "resource lookup" class that gets an
>> instance of a resource given a concrete class.
>>
>> @Context ResourceLookup rl;
>> @Path("sub") Class<Foo> getFooClass() { return rl.get
>> (Foo.class, .... /* params */ ); }
>
> 2) looks good, so resources do not have to be created even if they
> would
> not be needed, in the case of validation failures etc.
>
OK. I will work on this probably end of this or next week as i really
need to get some API implementation work done this week. I actually
like the name ResourceProvider (it is used already but i think we
should rename the existing one to something like
ResourceLifeCycleProvider).
>>
>>> Did I miss any scenario/requirement?
>>>
>>
>> There is the knotty issue of who chooses the constructor. But if we
>> can support your concept of an @Inject marker this may alleviate some
>> of the issues here.
>>
>> Would you like to work on a branch of Jersey to experiment?
> Yes, I can do this.
>
Great. I sent you an email about the SCA.
Paul.
> Cheers,
> Martin
>
>>
>> Paul.
>>
>>> Thanx for your feedback,
>>> cheers,
>>> Martin
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>