[weld-dev] persistence and transactions outside Java EE

Gavin King gavin.king at gmail.com
Tue Nov 24 19:33:46 EST 2009


Look, Dan, trust me, I would have tried to push to have support for
declarative tx management for managed beans in EE 6, but frankly I
already used up every drop of political capital and then some to just
get managed beans with interceptors and dependency injection in. Now
that we have that much, we have a foundation for generalizing
declarative transactions next time around. But we could easily have
ended up with no managed beans at all. So you should be thankful for
what you *do* have.

On Tue, Nov 24, 2009 at 4:28 PM, Dan Allen <dan.j.allen at gmail.com> 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 at 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 at 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
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org



More information about the weld-dev mailing list