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...?
> 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...
>
>
> >
> > 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.
>
> > 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.
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
>