Just to complete the loop on my side regarding making Tapestry services as
CDI beans, it is almost, kind of, possible via an SPI extension. However,
you run into issues with the lifecycle management and bean requirements
(no-arg constructor etc.) as well as dependency loops. I followed
http://rmann
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
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/
Also, you can secure CDI beans using Tapestry-security using this:
http://code.google.com/p/flowlogix/wiki/TLShiroSecurityInterceptor
On Mar 10, 2013, at 5:15 AM, Lenny Primak wrote:
> Kalle, that is exactly correct.
> The CDI stuff (and by extension the CDI code in FlowLogix) which is taken
>
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
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 wrot
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 M
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 wrote:
> Hey Magnus,
>
> as part of yo
+1
Did you have a look at https://github.com/got5/cdi-tapestry-contribution?
François
2013/3/9 Kalle Korhonen :
> 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 re
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.
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,
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 wrote:
> Hi all,
>
> We're looking into moving our apps from a 'traditional' ser
Great news!
Ok, so I've made some good progress again after getting involved in this
thread:
http://tapestry.1045711.n5.nabble.com/Supporting-EJB-annotation-in-Tapestry-classes-td4696836.html
So the problem was:
When contributing to MasterObjectProvider my CDIObjectprovider will resolve
any tapes
Thanks Howard, great to hear I'm on the right track :)
I haven't given much thought to exposing tapestry services to cdi.
It's not something we currently require for our projects, but if it's
requested by others I could look into that as well!
*Question*
I have one issue related to the CDIObjectP
Nope, it's designed to be easy ... though contributions into
MasterObjectProvider are always tricky since you can get into
dependency cycles very easily. You've properly side-stepped this using
@InjectService (using the special @Local marker annotation is always
very important).
The hard part, whi
15 matches
Mail list logo
