On Fri, 2008-04-11 at 10:17 +0200, Paul Sandoz wrote:
> On Apr 10, 2008, at 9:36 PM, Martin Grotzke wrote:
> >>
> >> It may be better to start creating an injectable thing per resource
> >> class (via ResourceClass) if we go this route to be more efficient
> >> i.e.
> >> we do the wiring up just once and avoid as much Java reflection as
> >> possible once we are up and running. But i am sure IoC frameworks do
> >> this type of optimization.... they may even generate byte code...
> >>
> >>
> >> I also think it may be useful to extend ComponentProvider such that
> >> injection can be deferred in general (rather than just the restricted
> >> case using @Context). What is required is a method signature as
> >> follows:
> >>
> >> getInstance(Annotation[] as, Type t, Class<?> c)
> >>
> >> Where t is the generic type (obtained from the field or parameter).
> >>
> >> Which means one could support the following:
> >>
> >> @XYZ List<ABC> l;
> > Shall we add this in the spring-integration branch, or would prefer
> > implementing this in the trunk?
> >
>
> I think the branch would be best (for the above and for injection
> detection based just on the annotation).
Ok, so I would start implementing these things in the spring-integration
branch, then you can have a look at it and give pointers how to
improve...
>
> I have a bunch of changes queued up for the trunk today (i promised a
> while back to investigate reloading with JavaRebel SDK) and next week
> i need to attempt to support the API feature @PathParam("id") Path
> Segment, and we need make a stable release so i would prefer not to
> put to many new things in the trunk as it might destabilize things.
> Is that OK?
I completely agree.
Do you think there might be conflicts between your changes and the
things we're doing in the branch?
Cheers,
Martin
>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net