[cdi-dev] CDI have any plan to process Transaction?

Pete Muir pmuir at redhat.com
Tue May 1 10:58:50 EDT 2012 

I think @Transactional will be javax.transaction, so you won't need EJB anymore.

On 1 May 2012, at 15:51, Mark Struberg wrote:

> For me the most important fact is that all the api interfaces and annotations get moved to an own spec/package.
> 
> Currently for implementing that stuff you need:
> 
>  *) JTA
>  *) EJB
>  *) JPA
> 
> That's a bit much for a lean project ;)
> 
> 
> LieGrue,
> strub
> 
> 
> ----- Original Message -----
>> From: Pete Muir <pmuir at redhat.com>
>> To: Hantsy Bai <hantsy at gmail.com>
>> Cc: cdi-dev at lists.jboss.org
>> Sent: Tuesday, May 1, 2012 12:21 PM
>> Subject: Re: [cdi-dev] CDI have any plan to process Transaction?
>> 
>> Sure :-)
>> 
>> Today:
>> 
>> * EJBs are transactional by default, IOW an EJB implicitly has 
>> @TransactionAttribute(REQUIRED) on it
>> * Managed beans are not transactional, and, without an extension like 
>> Deltaspike, cannot participate in transitions. IOW @TransactionAttribute cannot 
>> be applied to managed beans.
>> 
>> And with the proposal:
>> 
>> * Managed beans are not transactional by default, but can be made transactional 
>> by adding @Transactional
>> * By default @Transacational has a type of REQUIRED, but other modes can be 
>> specified (proposal has details)
>> * @TransactionAttribute is still used to control EJB transactions (we tried to 
>> bridge the two, but we can't see a sane way, read the EE ML archives for 
>> details)
>> 
>> IOW @Transactional brings declarative transactions to managed beans, it 
>> doesn't add new features.
>> 
>> HTH
>> 
>> On 1 May 2012, at 11:09, Hantsy Bai wrote:
>> 
>>> 
>>> can you ask in another way, what is new in the @Transacational,  compare to 
>> the existing @TransactionAttirbute ?
>>> but maybe it is not related to CDI now.
>>> 
>>> Hantsy
>>> 
>>> On 5/1/2012 17:53, Pete Muir wrote:
>>>> How do you mean?
>>>> 
>>>> On 1 May 2012, at 10:49, Hantsy Bai wrote:
>>>> 
>>>>> I do not understand why introduce @Transational in JEE7 but it  
>> still
>>>>> align with JTA.
>>>>> 
>>>>> On 5/1/2012 17:41, Pete Muir wrote:
>>>>>> Yes, that's possibly a better idea still :-D
>>>>>> 
>>>>>> On 30 Apr 2012, at 21:01, Dan Allen wrote:
>>>>>> 
>>>>>>> True, it could be a matter of packaging. We could include 
>> the necessary JAR files as part of the Servlet support in the respective 
>> distributions. In a sense, they would be "blessed" extensions, which 
>> is all any user really cares about (how else do they know what's in 
>> weld-servlet.jar, for example).
>>>>>>> 
>>>>>>> -Dan
>>>>>>> 
>>>>>>> On Mon, Apr 30, 2012 at 15:59, Mark 
>> Struberg<struberg at yahoo.de>   wrote:
>>>>>>> Over in DeltaSpike we are currently discussing the jpa 
>> module. Plans are to implement it there as portable extension. I see no need why 
>> we need to duplicate the effort by implementing it in both Weld and OWB ;)
>>>>>>> 
>>>>>>> The big benefit of this approach is that this will also run 
>> on any CDI-1.0 container!
>>>>>>> 
>>>>>>> 
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>> 
>>>>>>>> ________________________________
>>>>>>>> From: Dan Allen<dan.j.allen at gmail.com>
>>>>>>>> To: Pete Muir<pmuir at redhat.com>
>>>>>>>> Cc: cdi-dev at lists.jboss.org
>>>>>>>> Sent: Monday, April 30, 2012 9:42 PM
>>>>>>>> Subject: Re: [cdi-dev] CDI have any plan to process 
>> Transaction?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I molded this into a mini blog. Pete, if you are 
>> interested, feel free to post this as it will likely solve a wider 
>> misunderstanding from going around:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> "A standard, universal @Transactional annotation 
>> is coming in Java EE 7. However, there are some important things to keep in 
>> mind:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> - @Transactional *is* being developed as a revision to 
>> the JTA spec (as an MR)
>>>>>>>> - @Transactional *is not* being developed by the CDI 
>> EG, nor will it be in the CDI spec
>>>>>>>> - Feedback on @Transactional should be sent to the Java 
>> EE platform EG *not* to the CDI EG. The platform EG is conducting the revision 
>> to the JTA spec.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Java EE does not recognize a Servlet container as a 
>> compliant environment and therefore this feature will not be available there by 
>> default (mainly due to the absence of JTA in this environemnt).
>>>>>>>> 
>>>>>>>> 
>>>>>>>> However, to bridge the divide, Weld and OpenWebBeans 
>> will both likely offer support for @Transactional in a Servlet environment since 
>> we acknowledge that it *is* important, and is an environment preferred by many 
>> developers (but we still strongly urge you to migrate to the web 
>> profile!!)."
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -Dan
>>>>>>>> 
>>>>>>>> On Mon, Apr 30, 2012 at 04:55, Pete 
>> Muir<pmuir at redhat.com>   wrote:
>>>>>>>> 
>>>>>>>> Just to be 100% clear, as there is a lot of confusion 
>> around this topic.
>>>>>>>>> * @Transactional *IS NOT* being developed by the 
>> CDI EG nor will it be in the CDI spec
>>>>>>>>> * @Transactional *IS* being developed as a revision 
>> to the JTA spec (as a MR IIRC, but that was not my/our decision to make)
>>>>>>>>> * Feedback on @Trasnactional should be sent to the 
>> Java EE platform EG NOT to the CDI EG. The platform EG is conducting the 
>> revision to the JTA spec.
>>>>>>>>> 
>>>>>>>>> HTH!
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 30 Apr 2012, at 09:19, Pete Muir wrote:
>>>>>>>>> 
>>>>>>>>>> On 29 Apr 2012, at 23:12, Dan Allen wrote:
>>>>>>>>>> 
>>>>>>>>>>> Am I correct in saying that the annotation 
>> will control JTA
>>>>>>>>>> Yes, this will be an amendment to the JTA spec 
>> AIUI. So back where it belongs!
>>>>>>>>>> 
>>>>>>>>>>> and work in either of the two profiles (web 
>> and full)?
>>>>>>>>>> We haven't discussed this, but I'm 
>> assuming both. I will raise this.
>>>>>>>>>> 
>>>>>>>>>>> Btw, Java EE does not recognize a Servlet 
>> container as a compliant environment and therefore this feature will not be 
>> available there (without special support for it).
>>>>>>>>>> Correct. Main obstacle is actually a lack of 
>> JTA there, rather than the declarative control… But I think OWB and Weld will 
>> both offer something here as we all regard it as important!
>>>>>>>>>> 
>>>>>>>>>>> I agree with this stance since the web 
>> profile should be recognized as the low end environment. Otherwise there is not 
>> enough core services to provide a dependable and portable programming model. If 
>> you (general audience) want to use a Servlet container, you aren't using 
>> Java EE and will have to supplement with addons like CDI extensions or Spring.
>>>>>>>>>>> 
>>>>>>>>>>> -Dan
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Sent from my CyanogenMod-powered
>>>>>>>>>>> Android device, an open platform for
>>>>>>>>>>> carriers, developers and consumers.
>>>>>>>>>>> 
>>>>>>>>>>> On Apr 27, 2012 4:54 AM, "Pete 
>> Muir"<pmuir at redhat.com>   wrote:
>>>>>>>>>>> Java EE 7 will include @Transactional. This 
>> will be provided by the Java EE platform, rather than CDI specifically. It will 
>> be a CDI interceptor, and so enabled as other CDI interceptors are.
>>>>>>>>>>> 
>>>>>>>>>>> On 24 Apr 2012, at 09:10, Hantsy Bai wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> 
>>>>>>>>>>>> I have read some content about the spec 
>> 1.1, but I want to know if there
>>>>>>>>>>>> is a plan to provide a new transaction 
>> annotation...for EBJ or none EJB
>>>>>>>>>>>> proramming.
>>>>>>>>>>>> 
>>>>>>>>>>>> For example, provide a @Transactional 
>> annotation like Seam2 or Spring
>>>>>>>>>>>> 3.1...and make it work in Servlet 
>> container(none JTA transation, jdbc
>>>>>>>>>>>> only) or full profile container such as 
>> JBoss, Glassfish(JTA transaction
>>>>>>>>>>>> by default) seamlessly.
>>>>>>>>>>>> 
>>>>>>>>>>>> Automatically detect the Transaction 
>> will be used, or configure in
>>>>>>>>>>>> beans.xml file.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Regards
>>>>>>>>>>>> Hantsy
>>>>>>>>>>>> 
>> _______________________________________________
>>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>>>> 
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>>> 
>> _______________________________________________
>>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>>> 
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>> _______________________________________________
>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>>>> 
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>> 
>>>>>>>> --
>>>>>>>> 
>>>>>>>> Dan AllenPrincipal Software Engineer, Red Hat | Author 
>> of Seam in Action
>>>>>>>> Registered Linux User #231597
>>>>>>>> 
>>>>>>>> 
>>>>>>>> http://google.com/profiles/dan.j.allen
>>>>>>>> http://mojavelinux.com
>>>>>>>> http://mojavelinux.com/seaminaction
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> Dan Allen
>>>>>>> Principal Software Engineer, Red Hat | Author of Seam in 
>> Action
>>>>>>> Registered Linux User #231597
>>>>>>> 
>>>>>>> http://google.com/profiles/dan.j.allen
>>>>>>> http://mojavelinux.com
>>>>>>> http://mojavelinux.com/seaminaction
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> 
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>

More information about the cdi-dev mailing list