Re: [weld-dev] persistence and transactions outside Java EE
Dan,
I agree that this is less than ideal, but probably not so bad.
The proprietary feel is what we wanted to avoid and hence we are not
messing with the EJB aspect meta-data naming and not pretending as
though we are using something vastly different from what's there in the
EJB container, including the Resin transaction manager as is with
baked-in optimizations. We are also not discouraging users from using
EJB. The choice is up to them and for Resin at least, our users are
definitely smart enough to figure out what's what on their own. We
simply state the facts and our recommendations as we see them - there's
really no "lobbying" involved :-).
Cheers,
Reza
Dan Allen wrote:
Sigh. I still feel like we are stuck. I'm hearing that we can
either
have developers use EJB (lite or full Java EE) or they have to go find
a framework to have transactional beans. Maybe in the future this will
be in Java EE, but today we have to go about it our own way. And the
divergence is what bothers me.
If I had to sell this thing to an audience today, I would basically
lobby hard for the use of an EJB w/ EJB lite because the alternative
sounds too proprietary for me.
-Dan
On Tue, Nov 24, 2009 at 4:17 PM, Reza Rahman <reza_rahman(a)lycos.com
<mailto:reza_rahman@lycos.com>> wrote:
Dan,
I think the idea of using EJB "aspects" outside the component model is
something Java EE will accommodate soon anyway. The solution for now
should probably be implementing embeddable containers that way right
now. In our case, we still use @TransactionAttribute, but maybe
you guys
could use @Transactional or something similar...
Cheers,
Reza
Dan Allen wrote:
> Yep, the spec states:
>
> 'In a Java EE implementation, a Managed Bean may use any of the
> resource injection functionality laid out in Chapter 5 of the
Java EE
> Platform specification, “Resources, Naming and Injection“.'
>
> Hmm, but the trouble is, where does that leave Tomcat and Jetty? And
> if the resource like the persistence context or UT is to be
injected,
> who is doing the injecting? Of course, if EJB lite were present, it
> could handle it.
>
> So basically, what I'm getting at is that perhaps CDI can
provide this
> transaction and persistence support (maybe even the resource
> injection) when the Java EE environment is not present (meaning EJB
> lite is also absent).
>
> Of course, we can prototype this as a portable extension today. I'm
> certainly not opposed to that. But I would hope if we did, the long
> term goal would be to somehow provide this in Java EE lite.
>
> I understand this argument is circular, because eventually you
arrive
> back at the question "why not just make them use Java EE?" The
idea is
> to attract developers to Java EE by giving them one more
stepping stone.
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org <mailto:weld-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/weld-dev
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen