On Tue, 2008-03-25 at 16:00 +0100, Paul Sandoz wrote:
> 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?
So instances for @Context-annotated fields or method arguments would be
pulled from the ComponentProvider?
>
> BTW a Jersey @Injected or @Context should be very easy to support as
> we already have a simple general extraction mechanism in place.
Great :)
> >>> 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).
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... :)
Just to throw in an alternative for the existing ResourceProvider: what
about ScopedResourceProvider or ScopedResourceFactory?
Cheers,
Martin
>
> >>
> >>> 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
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>