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. 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.
>
> 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 */ ); }
> 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?
Paul.
> Thanx for your feedback,
> cheers,
> Martin
>
>