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

Reply via email to