Re: integrating CDI into Wicket
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
Re: integrating CDI into Wicket
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
Re: integrating CDI into Wicket
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
Re: integrating CDI into Wicket
one more question: is there anything Weld specific in wicket-cdi or it should work with other CDI implementations too ? On Wed, Nov 16, 2011 at 11: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 ... - 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 -- 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
Re: integrating CDI into Wicket
The only thing external is the conversation management stuff from Seam, it looks like. The user would have to make sure they include the container-specific adapter code on the classpath (org.jboss.seam.conversation:seam-conversation-weld for example) for their CDI container. Another concern would be the fact that they (JBoss) don't publish their artifacts to Maven central. Aren't they (the managers of Maven central) frowning upon publishing artifacts up there that depend on artifacts published elsewhere? On Wed, Nov 16, 2011 at 4:21 AM, Martin Grigorov mgrigo...@apache.org wrote: one more question: is there anything Weld specific in wicket-cdi or it should work with other CDI implementations too ? On Wed, Nov 16, 2011 at 11: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 ... - 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 -- 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
Re: integrating CDI into Wicket
On Wed, Nov 16, 2011 at 1:49 PM, James Carman ja...@carmanconsulting.com wrote: The only thing external is the conversation management stuff from Seam, it looks like. The user would have to make sure they include the container-specific adapter code on the classpath (org.jboss.seam.conversation:seam-conversation-weld for example) for their CDI container. Another concern would be the fact that they (JBoss) don't publish their artifacts to Maven central. Aren't they (the managers of Maven central) frowning upon publishing artifacts up there that depend on artifacts published elsewhere? See http://www.sonatype.com/people/2011/09/8942/ On Wed, Nov 16, 2011 at 4:21 AM, Martin Grigorov mgrigo...@apache.org wrote: one more question: is there anything Weld specific in wicket-cdi or it should work with other CDI implementations too ? On Wed, Nov 16, 2011 at 11: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 ... - 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 -- 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 -- 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
Re: integrating CDI into Wicket
Is the license compatible? I am actually going to roll my own in wicketopia. On Nov 16, 2011 6:59 AM, Martin Grigorov mgrigo...@apache.org wrote: On Wed, Nov 16, 2011 at 1:49 PM, James Carman ja...@carmanconsulting.com wrote: The only thing external is the conversation management stuff from Seam, it looks like. The user would have to make sure they include the container-specific adapter code on the classpath (org.jboss.seam.conversation:seam-conversation-weld for example) for their CDI container. Another concern would be the fact that they (JBoss) don't publish their artifacts to Maven central. Aren't they (the managers of Maven central) frowning upon publishing artifacts up there that depend on artifacts published elsewhere? See http://www.sonatype.com/people/2011/09/8942/ On Wed, Nov 16, 2011 at 4:21 AM, Martin Grigorov mgrigo...@apache.org wrote: one more question: is there anything Weld specific in wicket-cdi or it should work with other CDI implementations too ? On Wed, Nov 16, 2011 at 11: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 ... - 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 -- 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 -- 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
Re: integrating CDI into Wicket
- 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
Re: integrating CDI into Wicket
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
Re: integrating CDI into Wicket
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... 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. 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
Re: integrating CDI into Wicket
On Wed, Nov 16, 2011 at 3:49 AM, James Carman ja...@carmanconsulting.com wrote: The only thing external is the conversation management stuff from Seam, it looks like. The user would have to make sure they include the container-specific adapter code on the classpath (org.jboss.seam.conversation:seam-conversation-weld for example) for their CDI container. yes. this will go away once cdi 1.1 is release which provides the conversation scope api Another concern would be the fact that they (JBoss) don't publish their artifacts to Maven central. Aren't they (the managers of Maven central) frowning upon publishing artifacts up there that depend on artifacts published elsewhere? yeah. this is really annoying. i tried to talk to them about it but eventually got the good old we dont have time for this , you go talk to the sonatype folks for us. blah. until seam is in central this will have to stay an outside module. and until weld is in central the examples also have to be outside. i can probably rewrite the examples using something that is in central, like openbeans or whatever the apache thing is. -igor On Wed, Nov 16, 2011 at 4:21 AM, Martin Grigorov mgrigo...@apache.org wrote: one more question: is there anything Weld specific in wicket-cdi or it should work with other CDI implementations too ? On Wed, Nov 16, 2011 at 11: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 ... - 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 -- 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: integrating CDI into Wicket
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
Re: integrating CDI into Wicket
+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 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: integrating CDI into Wicket
On Nov 16, 2011 11:49 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: On Wed, Nov 16, 2011 at 3:49 AM, James Carman ja...@carmanconsulting.com wrote: The only thing external is the conversation management stuff from Seam, it looks like. The user would have to make sure they include the container-specific adapter code on the classpath (org.jboss.seam.conversation:seam-conversation-weld for example) for their CDI container. yes. this will go away once cdi 1.1 is release which provides the conversation scope api This will be great! Do they have an eta? For now I'll write my own abstraction similar to your CdiContainer
Re: integrating CDI into Wicket
why would you write your own when one is already there? -igor On Wed, Nov 16, 2011 at 12:37 PM, James Carman ja...@carmanconsulting.com wrote: On Nov 16, 2011 11:49 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: On Wed, Nov 16, 2011 at 3:49 AM, James Carman ja...@carmanconsulting.com wrote: The only thing external is the conversation management stuff from Seam, it looks like. The user would have to make sure they include the container-specific adapter code on the classpath (org.jboss.seam.conversation:seam-conversation-weld for example) for their CDI container. yes. this will go away once cdi 1.1 is release which provides the conversation scope api This will be great! Do they have an eta? For now I'll write my own abstraction similar to your CdiContainer - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: integrating CDI into Wicket
That's just how I roll! :) it's a learning exercise for me. I started a cdi integration project long ago and it got lost in the shuffle On Nov 16, 2011 3:42 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: why would you write your own when one is already there? -igor On Wed, Nov 16, 2011 at 12:37 PM, James Carman ja...@carmanconsulting.com wrote: On Nov 16, 2011 11:49 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: On Wed, Nov 16, 2011 at 3:49 AM, James Carman ja...@carmanconsulting.com wrote: The only thing external is the conversation management stuff from Seam, it looks like. The user would have to make sure they include the container-specific adapter code on the classpath (org.jboss.seam.conversation:seam-conversation-weld for example) for their CDI container. yes. this will go away once cdi 1.1 is release which provides the conversation scope api This will be great! Do they have an eta? For now I'll write my own abstraction similar to your CdiContainer - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
integrating CDI into Wicket
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/ -igor
