We are using FlowLogix CDI support in production now. The code is basically taken from Magnus' module, and enhanced it a bit to be more resilient in case CDI is not present. We've been using it in production for 6 months and it works great.
On Mar 10, 2013, at 5:56 PM, Magnus Kvalheim wrote: > Hi. > > Our motivation at the time was to investigate a move from a spring stack to > a jee one. > Most is written using jee annotations, with spring behind the scenes, so a > switch looked feasible. > > I made the tapestry-cdi module which bridged the gap on tapestry side. > ( https://github.com/magnuskvalheim/tapestry-cdi ). > > It worked quite well and got our apps playing nice with jee; jboss as7, > jpa, cdi, +more and tapestry. But in the end it didn't move past sandbox > stage and we're still with spring. It was a nice experience though and I > found CDI quite solid and powerful and think that Tapestry does deserve a > first class CDI module. > > We never had any need to to do the reverse (expose tapestry services to > cdi) so we didn't explore that in detail. > Tapestry IOC has a lot going for it as well so I can see that some would > like the option to go that direction as well. > > I think that maybe CDI->Tapestry and Tapestry->CDI should be > two separate modules. Or if it's in same module - have a convenient way to > configure what directions for it to operate. > > For CDI->Tapestry I would be happy to donate my module if it can be useful. > Think maybe Lenny have some production related experience with it. > The other mentioned, cdi-tapestry-contribution ( > https://github.com/rmannibucau/cdi-tapestry-contribution ) looks good and > could be used somewhere in production as well. > IMO we only need one good supported one :-) > > --magnus > > On Sun, Mar 10, 2013 at 10:15 AM, Lenny Primak <lpri...@hope.nyc.ny.us>wrote: > >> Kalle, that is exactly correct. >> The CDI stuff (and by extension the CDI code in FlowLogix) which is taken >> direct from CDI module >> is so meant to use CDI beans in Tapestry, not use Tapestry services as CDI >> beans. >> >> On Mar 10, 2013, at 1:58 AM, Kalle Korhonen wrote: >> >>> Both of these seem to be about referencing and using CDI managed beans in >>> Tapestry services, please correct me if I'm wrong. What I'm asking is the >>> reverse - using Tapestry services in applications & frameworks expecting >> a >>> CDI environment. >>> >>> Kalle >>> >>> >>> On Sat, Mar 9, 2013 at 3:41 PM, Lenny Primak <lpri...@hope.nyc.ny.us> >> wrote: >>> >>>> Actually, the CDI SPI statement may not be accurate. >>>> CDI support uses BeanManager to do its job, so its CDI SPI. Not sure, >>>> Kalle, if that's what you are referring to. >>>> >>>> >>>> >> http://code.google.com/p/flowlogix/source/browse/tapestry-services/src/main/java/com/flowlogix/web/services/CDIModule.java >>>> >>>> On Mar 9, 2013, at 5:56 PM, Lenny Primak wrote: >>>> >>>>> I would love to contribute the FlowLogix module, or as much of it as it >>>> still applies to tapestry 5.4 into the core. It includes CDI support >> plus >>>> the JEE stack support. >>>>> The CDI interface doesn't use SPI yet. >>>>> >>>>> >>>>> >>>>> On Mar 9, 2013, at 5:34 PM, Kalle Korhonen <kalle.o.korho...@gmail.com >>> >>>> wrote: >>>>> >>>>>> Hey Magnus, >>>>>> >>>>>> as part of your tapestry-cdi work, did you look into implementing a >>>>>> Tapestry CDI SPI, i.e. an implementation of >>>>>> javax.enterprise.inject.spi.BeanManager? This is related to my earlier >>>>>> thread about injectable entitylisteners ( >>>>>> >>>> >> http://mail-archives.apache.org/mod_mbox/tapestry-dev/201210.mbox/%3CCA+=ewnb+tjv01fiyzsded3u5iyop3wcf1r3prhqtdjrm7ix...@mail.gmail.com%3E >>>> ). >>>>>> JPA 2.1 is required the check the SPI (see >>>>>> http://java.dzone.com/articles/cdi-extensions-you-can-build, >>>>>> http://java.net/downloads/jpa-spec/JavaPersistencePFD.pdf, >>>>>> >>>> >> http://stackoverflow.com/questions/12951701/how-to-get-entity-manager-or-transaction-in-jpa-listener >>>> , >>>>>> >>>> >> http://stackoverflow.com/questions/11740322/cdi-injection-is-not-working-in-servlets >>>> ). >>>>>> The CDI is a solid spec, we should start thinking about offering >>>>>> tapestry-cdi or similar as a core Tapestry module. >>>>>> >>>>>> Kalle >>>>>> >>>>>> >>>>>> On Thu, Aug 18, 2011 at 11:59 AM, Magnus Kvalheim <mag...@kvalheim.dk >>>>> wrote: >>>>>> >>>>>>> Yes, I've noticed. Great work Igor :) >>>>>>> >>>>>>> I've intentionally not done anything for tapestry-cdi in terms of >>>>>>> supporting >>>>>>> javax.inject.@Inject. >>>>>>> >>>>>>> As Tap @inject and javax @inject are interchangeable - cdi bean >>>> injection >>>>>>> with either @inject should 'just work' with tapestry-cdi and T5.3 :) >>>>>>> >>>>>>> On Thu, Aug 18, 2011 at 12:56 PM, Igor Drobiazko >>>>>>> <igor.drobia...@gmail.com>wrote: >>>>>>> >>>>>>>> Just as a side note: starting with T5.3 it's possible to use JSR 330 >>>> for >>>>>>>> injection. >>>>>>>> >>>>>>>> Check this out: >>>>>>>> http://tapestry.apache.org/using-jsr-330-standard-annotations.html >>>>>>>> >>>>>>>> On Wed, Jun 8, 2011 at 1:56 PM, Magnus Kvalheim <mag...@kvalheim.dk >>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> We're looking into moving our apps from a 'traditional' servlet >>>>>>> container >>>>>>>>> with spring into a Java EE web profile server like glassfish 3.1. >>>>>>>>> Motivations for doing this is to utilize cdi(jsr 299, 330), ejb3 >> and >>>>>>>> more. >>>>>>>>> Not just for the tapestry app, but also the other applications in >>>>>>>>> our portfoleo which share common core business logic. >>>>>>>>> >>>>>>>>> For reference on previous discussions: >>>>>>> >>>> >> http://tapestry.1045711.n5.nabble.com/Java-based-spring-configuration-td3394086.html >>>>>>>>> http://tapestry.1045711.n5.nabble.com/Discussion-td2421783i20.html >>>>>>>>> >>>>>>>>> Now, I've tried running the tapestry quickstart app in glassfish >> 3.1 >>>>>>>> (with >>>>>>>>> the eclipse connector for publishing). >>>>>>>>> This works ok - although I cannot make live class reloading work. >> :( >>>>>>>>> >>>>>>>>> Glassfish uses Weld, so the CDIModule is basically an >> objectprovider >>>>>>> for >>>>>>>>> injecting Weld managed beans. >>>>>>>>> (As you probably know CDI/Weld can also be used outside jee as >>>>>>>> alternative >>>>>>>>> to tapestry-ioc, spring, etc) >>>>>>>>> >>>>>>>>> *CDIModule class* >>>>>>>>> *public class CDIModule { * >>>>>>>>> * public static void bind(ServiceBinder binder) {* >>>>>>>>> * binder.bind(ObjectProvider.class, >>>>>>>>> CDIObjectProvider.class).withId("CDIObjectProvider"); * >>>>>>>>> * } * >>>>>>>>> * public static BeanManager buildBeanManager(Logger log) { * >>>>>>>>> * try {* >>>>>>>>> * BeanManager beanManager = (BeanManager) new >>>>>>>>> InitialContext().lookup("java:comp/BeanManager");* >>>>>>>>> * return beanManager; * >>>>>>>>> * } catch (NamingException e) {* >>>>>>>>> * log.error("Could not lookup jndi resource: >> java:comp/BeanManager", >>>>>>> e);* >>>>>>>>> * }* >>>>>>>>> * return null;* >>>>>>>>> * } * >>>>>>>>> * public static void contributeMasterObjectProvider(* >>>>>>>>> * @InjectService("CDIObjectProvider") ObjectProvider cdiProvider,* >>>>>>>>> * OrderedConfiguration<ObjectProvider> configuration) { * >>>>>>>>> *// configuration.add("cdiProvider", cdiProvider, >>>>>>> >>>> >> "after:Service,after:AnnotationBasedContributions,after:Alias,after:Autobuild"); >>>>>>>>> * >>>>>>>>> * configuration.add("cdiProvider", cdiProvider, "after:*"); * >>>>>>>>> * } * >>>>>>>>> *}* >>>>>>>>> * >>>>>>>>> * >>>>>>>>> The beanmanager is expected to be found in jndi. If the beans.xml >> is >>>>>>>>> present >>>>>>>>> it will be available at this point. >>>>>>>>> The BeanManager is also exposed as a service and injectable for >> other >>>>>>>>> services or components. >>>>>>>>> I've tested by adding the *@SubModule(CDIModule.class) *to my >>>>>>> quickstart >>>>>>>>> appmodule. >>>>>>>>> * >>>>>>>>> * >>>>>>>>> *CDIObjectProvider class* >>>>>>>>> *public class CDIObjectProvider implements ObjectProvider { * >>>>>>>>> * private BeanManager beanManager;* >>>>>>>>> * private Logger log;* >>>>>>>>> * * >>>>>>>>> * @SuppressWarnings({ "unchecked", "rawtypes" })* >>>>>>>>> * private Set allowedScopes = CollectionFactory.newSet(* >>>>>>>>> * ApplicationScoped.class,* >>>>>>>>> * Singleton.class);* >>>>>>>>> * >>>>>>>>> * >>>>>>>>> * public CDIObjectProvider(* >>>>>>>>> * Logger log,* >>>>>>>>> * @InjectService("BeanManager") BeanManager manager) {* >>>>>>>>> * this.beanManager = manager;* >>>>>>>>> * this.log = log;* >>>>>>>>> * }* >>>>>>>>> * @SuppressWarnings("unchecked")* >>>>>>>>> * public <T> T provide(Class<T> objectType,* >>>>>>>>> * AnnotationProvider annotationProvider, ObjectLocator locator) {* >>>>>>>>> * Set<Bean<?>> beans = beanManager.getBeans(objectType);* >>>>>>>>> * if(beans!=null && beans.size()>0) {* >>>>>>>>> * Bean<T> bean = (Bean<T>) beans.iterator().next(); * >>>>>>>>> * if(hasValidScope(bean)) {* >>>>>>>>> * CreationalContext<T> ctx = >>>>>>> beanManager.createCreationalContext(bean);* >>>>>>>>> * T o = (T) beanManager.getReference(bean, objectType, ctx); * >>>>>>>>> * log.info("Found and returning: >> "+objectType.getCanonicalName());* >>>>>>>>> * return o; * >>>>>>>>> * }* >>>>>>>>> * }* >>>>>>>>> * return null;* >>>>>>>>> * } * >>>>>>>>> * protected <T> boolean hasValidScope(Bean<T> bean) {* >>>>>>>>> * return bean!=null && allowedScopes.contains(bean.getScope());* >>>>>>>>> * }* >>>>>>>>> *}* >>>>>>>>> >>>>>>>>> I've limited the scope to singleton/applicationscoped. Perhaps also >>>>>>>> Default >>>>>>>>> could be accepted though. >>>>>>>>> Until now I've only tested this with pojo's and not ejb's - but for >>>>>>> that >>>>>>>>> it's working as expected. >>>>>>>>> I can inject CDI beans into pages and components using* >>>>>>>>> org.apache.tapestry5.ioc.annotations.Inject* >>>>>>>>> >>>>>>>>> I'm no expert to tapestry internals - so there could be >>>>>>>>> other considerations that needs to be addressed. >>>>>>>>> In fact in seemed just a little to easy to implement - so I must >> have >>>>>>>>> missed >>>>>>>>> something. - Or perhaps it's just that easy to do in Tapestry :) >>>>>>>>> >>>>>>>>> Thoughts, comments? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Igor Drobiazko >>>>>>>> http://tapestry5.de >>>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
