Hi Paul,
On Fri, Apr 11, 2008 at 4:52 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> Martin Grotzke wrote:
>
> > On Fri, 2008-04-11 at 10:28 +0200, Paul Sandoz wrote:
> >
> > > Hi Martin,
> > >
> > > On Apr 11, 2008, at 9:23 AM, Martin Grotzke wrote:
> > >
> > >
> > > > Hi Paul,
> > > >
> > > > yesterday I started to write tests for the spring-integration (using
> > > > embedded jetty as you posted some weeks ago, which is really cool
> > > > btw :)).
> > > >
> > > >
> > > Great. (BTW i plan to switch to Grizzly for embedded servlet testing
> after the 0.7 release).
> > >
> > Ok. With jetty it took some time for me to notice that I have to use the
> > spring servlet for spring initialization - I didn't find out how to
> > configure a servlet context listener. Hopefully with Grizzly this is
> > easier then :)
> >
> > Just for interest: in what is Grizzly better than Jetty?
> >
> >
>
> The Grizzly community is very active, helpful and fixes things really fast,
> and we just need to put one jar in the distribution. Plus i want to use
> Grizzly for comet support.
>
>
>
>
> >
> > >
> > >
> > > > When doing this I noticed, that WebApplication.initiate fails when
> > > > injectResources is invoked for XMLJAXBElementProvider (which inherits
> > > > the field
> > > > @Context private ContextResolver<JAXBContext> cr;
> > > > from AbstractJAXBElementProvider).
> > > >
> > > > How is this realized, how can I test on this case? The issue is, that
> I
> > > > currently try to get an instance of a @Context annotated field, if
> > > > there's no type->injectable mapping existing for the field type.
> > > >
> > > >
> > > Developers can register stuff like this:
> > >
> > > @Provider
> > > public class MyResolver implements ContextResolver<JAXBContext> {
> > > }
> > >
> > > and an aggregated instance of such providers will be added to the list
> of injectables (see the WebApplicaitonImpl.init method). In general a
> developer can add a resolver for any type. If there are no such providers
> then no injectable will be registered and thus it will be null. We should
> not defer to the component provider for types of ContextResolver (off the
> top of my head i cannot recall if there are others as well).
> > >
> > Hopefully not :)
> > So for now I don't inject @Context annotated fields if the field type is
> > ContextResolver.
> >
> >
>
> OK.
>
>
>
>
> >
> > >
> > > > Another possibility would be to use the annotation->injectable thing
> for this, another would be to use another annotation than
> > > > @Context.
> > > >
> > >
> > What do you think about this? I'm not completely happy with the "inject
> > instances pulled from the component provider if the field is annotated
> > with @Context and we don't have better alternatives"-thing as it seems
> > to me to be somehow magic - or not very stable. I'm just not sure and
> > wanted to raise the question again.
> >
>
> That is OK, we have run into some issues so i think you are right to raise
> it.
>
>
>
>
> > If we would use the annotation-injectable way the spring-integration
> > module could define it's own @Inject annotation and inject beans pulled
> > from spring. The disadvantage is, that this logic has to be duplicated
> > for different IoC-backends...
> >
> >
>
> My understanding is there are two requirements:
>
> 1) Support annotation-based injection on fields for IoC frameworks that
> do not have such capability; and
>
> 2) Support constructor/method parameter injection of IoC registered
> instances.
>
> Given that we ran into an issue with using @Context for 1) then perhaps we
> should have a different annotation like you proposed that is clearly
> separate from @Context. If we make changes to Injectable it should easy to
> support, and that way we also support Frank's requirements.
>
> For 2) we still require are our own annotation, as i don't see any features
> in Guice/Spring to allow intermixing of parameter injection responsibilities
> (that could change as we learn more).
>
> So i think i am leaning towards the following:
>
> 1) Supporting injectable per annotation and injectable per
> annotation+type;
>
> 2) Use a new annotation as you previously said (you were right!)
> to specify deferring to an IoC framework;
>
> 3) Implement an injectable per annotation, from 1), for 2); and
>
> 4) Implement a parameter injectable for 2).
>
> Sound like a plan?
>
> Paul.
>
> --
It sounds really good!
Thanks a lot. With these changes we can integrate any external IoC
container very easy.
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
--
Frank D. Martínez M.
Asimov Technologies Ltda.
Blog: http://www.ibstaff.net/fmartinez/