On Wed, Nov 16, 2011 at 6:45 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote: > On Wed, Nov 16, 2011 at 1:20 AM, Martin Grigorov <mgrigo...@apache.org> wrote: >> >> 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 ... > > cdi uses the standard javax.inject.Inject...not sure where you found > the enterprise.inject.Inject variation > >> - is it possible to not proxy the injected object (we have a ticket >> with patch for Spring for that but not for Guice) > > not as far as i know. proxying is part of the spec. im sure, if > needed, we can write the container-specific logic to unwrap the proxy, > but why would we want to? id like to see a good usecase first...
there is an open ticket in our Jira iirc it was about injecting a j.l.Class close it :-) > >> 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 > > it doesnt work because we use cdi-specific functionality to inject > noncontextual objects - not the framework provided by wicket-ioc such > as IFieldValueFactory, etc. > > we can probably wire it in, but NonContextualManager in wicket-cdi > provides more then just inject(), it also has postConstruct() and > preDestroy() > > https://github.com/42Lines/wicket-cdi/blob/master/wicket-cdi/src/main/java/net/ftlines/wicket/cdi/NonContextualManager.java > >> - why Spring/Guice doesn't support @PostConstruct ? > > guice does via an addon lib, not sure what spring's status is. Spring supports it too. Wicket-Spring doesn't do that for Wicket components/behaviors > >> 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 ? > > we should provide minimal integration. we should not start normalizing > across containers, its a huge job that is worthy of its own project. > > -igor > >> >> 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 > > -- 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
