>Yeah, I don't know if that's doable now, but we could do some work on
>Tapestry-IoC so the Registry object could provide a method that returns a
>list of services, something which isn't done yet AFAIK.
Maybe this service could help us for that :
http://tapestry.apache.org/current/apidocs/org/apac
On Thu, May 16, 2013 at 12:08 PM, Nourredine Khadri <
nourredine.kha...@atos.net> wrote:
> >I do believe that the same could be said for tapestry-cdi and by
> extension FlowLogix
> >Magnus, can you comment on this?
> I think that you have to rely on a specific container's implementation
> to exclu
On Thu, 16 May 2013 07:08:09 -0300, Nourredine Khadri
wrote:
What about having Tapestry-IoC as a CDI portable extension which
registers
T-IoC services as CDI beans? This way, we can still have the best of two
worlds without Tapestry-IoC implementing CDI and with way less work.
Currently, C
>I do believe that the same could be said for tapestry-cdi and by extension
>FlowLogix
>Magnus, can you comment on this?
I think that you have to rely on a specific container's implementation
to exclude classes from scanning and avoid conficts between CDI and
Tapestry IOC. I can be wrong.
Also, I
Good job...
I am very glad to see CDI is supported in Tapestry, but I viewed the
pom.xml, it depended on openejb(not standard CDI api), and tomee(for test).
I wish Apache DeltaSpike(which is the successor of MyFaces CODI and
JBoss Seam3 and others) can be considered as dependency, it is also fr
On Wed, 15 May 2013 14:19:11 -0300, Thiago H de Paula Figueiredo
wrote:
One (maybe stupid) question: does it allow Tapestry services to be
provided as CDI beans, so they can have transaction handling or other
CDI-provided stuff, and still be injectable through Tapestry-IoC? That
would be t
On Wed, 15 May 2013 17:19:13 -0300, Kalle Korhonen
wrote:
If Tapestry IOC would fully implement
the CDI spec, how would it be any different than any other CDI
implementation?
+1 to that. I'd love to see that happening (and, of course, to contribute
for that). The Tapestry-IoC implementati
On Wed, 15 May 2013 17:06:13 -0300, Lenny Primak
wrote:
Now saying that, I am not saying Tapestry, or Tapestry-IOC sucks, I just
feel Tapestry-IOC is unnecessary in the current technology landscape and
presents a barrier to learning Tapestry.
Tapestry-IoC is very necessary for Tapestry.
On Wed, May 15, 2013 at 1:06 PM, Lenny Primak wrote:
> I grasp them fully.
> I stand by my opinion.
> Now saying that, I am not saying Tapestry, or Tapestry-IOC sucks, I just
> feel
> Tapestry-IOC is unnecessary in the current technology landscape and
> presents a barrier to
> learning Tapestry.
>
Please, don't take my statements personally.
I've been using these technologies for 2+ years.
I grasp them fully.
I stand by my opinion.
Now saying that, I am not saying Tapestry, or Tapestry-IOC sucks, I just feel
Tapestry-IOC is unnecessary in the current technology landscape and presents a
b
*** There is no such thing as** **a** **stupid question*. ;)
Currently the CDI extension at
https://github.com/got5/tapestry-cdi/blob/master/src/main/java/org/got5/tapestry5/cdi/extension/TapestryExtension.javaforce
the CDI manager to ignore Tapestry service.
2013/5/15 Thiago H de Paula Figueired
On Wed, May 15, 2013 at 12:42 PM, Lenny Primak wrote:
> I think all of the CDI modules are basically a consumer layer so Tapestry
> pages/components/etc. can use CDI beans.
> Usually, the use case is that the rest of the company is using CDI, and
> the presentation layer (Tapestry) needs to use
>
Well, I don't want to maintain redundant code, it I don't have to.
I would gladly switch to another module, and that will give me less code to
maintain.
Other comments interspersed below...
On May 15, 2013, at 12:38 PM, Nourredine Khadri wrote:
> No need to delete your contribution Lenny : )
>
I think all of the CDI modules are basically a consumer layer so Tapestry
pages/components/etc. can use CDI beans.
Usually, the use case is that the rest of the company is using CDI, and the
presentation layer (Tapestry) needs to use
some of that functionality.
This may be off topic, but in al
On Wed, 15 May 2013 10:35:36 -0300, Nourredine Nourredine
wrote:
Hi,
Hi!
Atos is proud to announce the first release of Tapestry-cdi, part of
the got5[1] project.
Yay! Thanks!
One (maybe stupid) question: does it allow Tapestry services to be
provided as CDI beans, so they can have t
No need to delete your contribution Lenny : )
This module was first implemented to fulfill our need and to replace
our internal IOC framework. Now we want to share it.
We have been focused on a Tomee environment, though the implementation
is not container specific. We also need to handle CDI quali
So, now we have 4 CDI modules. How do they compare?
Should I bother keeping mine ( in FlowLogix )?
I can gladly delete it if the got5 one is better.
We are using FlowLogix one in production,
the only difference between it and Magnus' module,
is it works even if CDI is turned off (no beans.xml)
D
Congratulations guys - and thanks for putting this together. This is good
news.
One of my wishes was to have a solid cdi production quality module, but
never really made past pet-project as we're still on with spring. (Still
hoping for spring to implement the spec, but that might never gonna
happen
Hi,
Atos is proud to announce the first release of Tapestry-cdi, part of
the got5[1] project.
This library is based on work of Romain Manni Bucau[2] and inspired
from other contributions (Magnus Kvalheim[3] and FlowLogix
projects[4]).
We have updated the dependencies of this library to use Tapest
Hi,
Atos is proud to announce the first release of Tapestry-cdi, part of the
got5[1] project.
This library is based on work of Romain Manni Bucau[2] and inspired from
other contributions (Magnus Kvalheim[3] and FlowLogix projects[4]).
We have updated the dependencies of this library to use Tape
20 matches
Mail list logo
