+1 very nice, igor :-) Am 16.11.2011 um 17:33 schrieb Igor Vaynberg:
> 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 <[email protected]> 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 <[email protected]> >> wrote: >>>> sure >>>> >>>> -igor >>>> >>>> On Wed, Nov 16, 2011 at 12:49 AM, Martijn Dashorst < >>>> [email protected]> wrote: >>>> >>>>> On Tue, Nov 15, 2011 at 7:00 PM, Igor Vaynberg < >> [email protected]> >>>>> 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: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> Martin Grigorov >>> jWeekend >>> Training, Consulting, Development >>> http://jWeekend.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
