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(a)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(a)gmail.com>
>>>>> To: Pete Muir<pmuir(a)redhat.com>
>>>>> Cc: cdi-dev(a)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(a)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(a)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(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>> _______________________________________________
>>>>>>> cdi-dev mailing list
>>>>>>> cdi-dev(a)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(a)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(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/cdi-dev