I don't think it's for lack of trying that there isn't a JSR. Also we worked pretty hard to keep JAX-RS free of inventing it's own DI and lifecycle which it was on the verge of doing (@Singleton, etc.). And am glad to say that for the most part sense prevailed.
Most of this is just a fancy way of calling "new". Lately, Im beginning to wonder if we really need a standards committee to arbitrate its cosmetics... I'm sure that is not the popular view, however. Dhanji. =) On Mon, Mar 30, 2009 at 9:08 PM, James Strachan <[email protected]>wrote: > > 2009/3/27 Bob Lee <[email protected]>: > > On Fri, Mar 27, 2009 at 6:32 AM, James Strachan < > [email protected]> > > wrote: > >> > >> As an aside - I tried noodling the recent changes and couldn't quite > >> get my head around them - any chance you could hack up a little test/ > >> demo to show how the new stuff is meant to be used to implement a > >> custom injection point like @Resource? :) > > > > Definitely will do. In the mean time, your injectable type listener runs > > once when a type is first encountered, and it should do the up-front > > reflection work. It will find all methods annotated w/ @Resource, and > then > > it will create a list of Pair<Method, Provider<Object>> objects that > contain > > the method to be injected and the provider that provides the object to be > > injected. The injectable type listener registers an injection listener. > The > > injection listener just iterates through the list of pairs, gets an > object > > from the provider, and invokes the method passing in the provided object. > In > > other words, the injection listener will be very fast and not even > perform > > any lookups. In the injectable type listener, you use the Encounter to > get > > the provider, register the injection listener, report errors, etc. > > > > The same goes for supporting EJB interceptors. > > > >> > >> With the new extension points in Guice it should be possible (I hope) > >> to implement support for JSR 299 annotations on beans/services - yet > >> reuse the nice stuff in Guice (modules etc). Or to say that another > >> way; if we can find a small, common base of interoperability in the > >> IoC/DI space then allow innovation at the edges & above the spec (e.g. > >> Guice Modules v XML v classpath scanning) we will drastically lower > >> the barrier to switching from one IoC container to another which > >> should help foster more innovation and prevent lock in from the > >> established XML heavy containers. > > > > I agree that standard annotations would be useful. You'd also want to > > standardize the Provider interface. I'm not fond of 299's annotations > > though, and I think we should hold out for or even push for something > > better. > > But there seems to be zero movement on any other JSR to standardize > IoC annotations. I don't see Guice or Spring doing anything any time > soon. I'd rather have something, even sub optimal that we can use in > lieu of something better further down the road. The Java ecosystem is > littered with stuff that has been replaced (EJB1, Servlets (now JAX-RS > makes more sense), JAXB 1.0 etc. > > If one day you & Rod can be bothered to hammer out a new JSR thats > better than 299 - great! But I don't see that happening any time soon > do you? > > Hopefully we can feed your feedback to the JSR and try push for changes? :) > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://fusesource.com/ > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
