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 > >
