using @javax.inject.Inject is perfectly fine. the rest (required, dont proxy, blah) can be done using qualifier annotations
@javax.inject.Inject @org.apache.wicket.ioc.Dependency(required=true, proxy=false) -igor On Wed, Nov 16, 2011 at 6:36 AM, Peter Ertl <pe...@gmx.org> wrote: > > - why we don't use jsr330 @javax.inject.Inject since both Spring and > > Guice support it. With CDI I think javax.enterprise.inject.Inject is > used which is yet another … > > I would not try to support @javax.inject.Inject which means using the > lowest common denominator of all these injection technologies. > > We still could but then it would be the second-best choice... > > For instance @javax.inject.Inject does not support optional injection like > guice @Inject(optional=true) does. Or @SpringBean(required=true). Or > control if we want to create a proxy for the injected bean or not, and so > on... > > I would favor the usage of one common wicket-specific(!) injection > annotation (e.g. @WicketInject ) so we can add options to it which might be > implemented differently depending on the framework (guice/spring/cdi). > > So swapping one technologie for another will not affect the code of your > wicket application (except the initialization part). > > my 2% > > Cheers > Peter > > Am 16.11.2011 um 10:20 schrieb Martin Grigorov: > > > speaking of moving it to Apache.. > > > > currently we have some inconsistencies between Spring and Guice > > integrations and users ask from time to time : > > - why we don't use jsr330 @javax.inject.Inject since both Spring and > > Guice support it. With CDI I think javax.enterprise.inject.Inject is > > used which is yet another ... > > - is it possible to not proxy the injected object (we have a ticket > > with patch for Spring for that but not for Guice) > > > > now with CDI I see more: > > - why Injector.get().inject(me) doesn't work ? > > --- because it needs BeanManager, but since it is reachable from > > ServletContext then it should be OK > > --- because it needs the class - OK, use me.getClass() for that > > - why Spring/Guice doesn't support @PostConstruct ? > > > > So my question is: should we try to make them consistent with each > > other or we should provide minimal integration and give the user the > > possibility to use the full power of his favorite DI framework ? > > > > On Wed, Nov 16, 2011 at 10:52 AM, Igor Vaynberg <igor.vaynb...@gmail.com> > wrote: > >> sure > >> > >> -igor > >> > >> On Wed, Nov 16, 2011 at 12:49 AM, Martijn Dashorst < > >> martijn.dasho...@gmail.com> wrote: > >> > >>> On Tue, Nov 15, 2011 at 7:00 PM, Igor Vaynberg < > igor.vaynb...@gmail.com> > >>> wrote: > >>>> if you want to learn how to use CDI with Wicket i just wrote a short > blog > >>>> about it: > >>>> > >>>> https://www.42lines.net/2011/11/15/integrating-cdi-into-wicket/ > >>> > >>> Can we use it for the documentation of the CDI project (when we > >>> migrate it to apache)? > >>> > >>> Martijn > >>> > >>> -- > >>> Become a Wicket expert, learn from the best: http://wicketinaction.com > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >>> For additional commands, e-mail: users-h...@wicket.apache.org > >>> > >>> > >> > > > > > > > > -- > > Martin Grigorov > > jWeekend > > Training, Consulting, Development > > http://jWeekend.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
