[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-121: -------------------------- Affects Version/s: (was: 1.1 (Proposed)) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Richard Hightower commented on CDI-121: --------------------------------------- I am. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-121: -------------------------- Assignee: Richard Hightower -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Jens Schumann commented on CDI-121: ----------------------------------- Adam: We use this for our own projects, including support for @ApplicationException. While it certainly makes sense from an EJB perspective it really feels strange to add an EJB dependency to CDI in order to add TX support (ApplicationException/TransactionAttribute are located at javax.ejb). We should probably move this discussion to CDI-27. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-121: -------------------------------- I believe Reza on the JMS EG was looking for support for this as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Reza Rahman commented on CDI-121: --------------------------------- Just to add a bit more detail to this, the basis for Rick's initial proposal for @TransactionScoped is rooted in our implementation for Resin and is inspired largely by the JPA transactional persistence context (it has nothing to do with the current notion of CDI conversations). You can browse the initial version of it here: http://www.opensourcejavaphp.net/java/resin/com/caucho/server/webbeans/Tr.... The basic idea is to have beans scoped to the active JTA transaction. While the current Resin @TransactionScoped is not implemented this way right now, I think the scope also needs to "downgrade" to "per-bean-method-invocation" scope (a la stateless session beans without a pool) if an active transaction is not present. Currently, Resin will throw a context not active exception if no transaction is found, which I don't think is too usable as a fall-back strategy. Here is sample code that uses this scope: http://www.caucho.com/articles/CanDI_demo_2.zip. The basic use case for it is when Java EE end-users need to integrate their own transactional back-end resources via CDI into any managed bean (including EJBs). I don't think straight @TransactionScoped is really the right answer for JMS 2 though. The most obvious reason is that besides being transaction scoped, JMS objects in the same scope will also need to be created and destroyed in a specific order, which a general purpose scope will still not do (short of maybe standardizing something like EJB @DependsOn in CDI). Let me know if I can explain further. I'll coordinate on this with Rick/Scott too. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Reza Rahman commented on CDI-121: --------------------------------- I think it depends on the implementation. For stateless session bean style/code generation proxies, it's easy because you just create a new delegate instance and get rid of it after the target method is invoked. Depending on the implementation, you might have to use thread local as underlying storage and clear thread-local once an interceptor tells you the method invocation is done. We do have a @ThreadScoped in Resin that might be helpful to look at: http://www.opensourcejavaphp.net/java/resin/com/caucho/inject/ThreadConte.... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Stuart Douglas commented on CDI-121: ------------------------------------ So it turns out I wan't thinking when I made that comment. I was just thinking that this idea of 'stateless if the scope is not active' could be generalised to all scopes, so you could place an annotation on a bean that enables this behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-121: ----------------------------------- This is still fairly easy to write as a CDI Extension (hacked it as CODI addon a year ago) and painfully hard to write if you need to get it working on ALL EE containers. So it wont work easily without non-portable config. You would at least have to config the JNDI namespace of JTA (hell why the ffff is this always different on any container btw?). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-121: ------------------------------- We can always use a container specific integration if this is built into a CDI impl. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Marina Vatkina edited comment on CDI-121 at 9/9/11 6:36 PM: ------------------------------------------------------------ There is a generic interface for the integration purposes: http://java.sun.com/javaee/6/docs/api/javax/transaction/TransactionSynchr... was (Author: mvatkina): There is a generic interface for the integration purposes: Isn't http://java.sun.com/javaee/6/docs/api/javax/transaction/TransactionSynchr... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Reza Rahman commented on CDI-121: --------------------------------- I'm not sure what @Transactional means, but I don't see why you would need to import @TransactionAttribute to implement @TransactionScope really - we don't. It doesn't really matter if the JTA transaction is started in EJB or not. The transaction could just as easily be in the web container. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Reza Rahman commented on CDI-121: --------------------------------- You can write a TCK test by simply using UserTransaction (which is already included in CDI). There is no need for @Transaction in order to standardize @TransactionScoped, just as you cam standardize @RequestScoped while a Java EE Request is still defined in the Servlet specification. @Transaction (provided it is even needed) should be standardized as part of EJB, not CDI. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] John Ament commented on CDI-121: -------------------------------- I'm wondering if this annotation (@TransactionScoped) belongs more with the EJB spec then, as a part of the standardization of transactional on top of managed beans, rather than trying to force the behavior into EJB, but the API into CDI. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-121: ------------------------------- Specifying, testing and implementing this without having some transaction control in CDI is going to be hard. However, Mark raised a far more powerful point, which is that we will end up with a feature that doesn't have particularly well defined behavior unless we build on top of declarative transaction control. For this reason, I would prefer to have the declarative tx support from EJB applied to managed beans before we address this. The issue for that is CDI-27. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Reza Rahman commented on CDI-121: --------------------------------- I agree. As long as there is an underlying JTA transaction/transaction manager, it doesn't matter where the transaction actually comes from or how that higher level API looks like. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] George Gastaldi commented on CDI-121: ------------------------------------- +1 to previous comment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

That would be great :-) As Reza says, now we have @Transactional proposed for the platform, this scope makes a lot more sense. On 15 Feb 2012, at 08:26, Rick Hightower wrote:

OK, keep me posted - I'll chime in as needed. On 2/15/2012 3:55 PM, Rick Hightower wrote:

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Reza Rahman edited comment on CDI-121 at 2/16/12 5:54 PM: ---------------------------------------------------------- Only @Transactional is being defined in JTA. The older EJB CMT annotations will remain in EJB. @TransactionScoped would belong in CDI. As far as dependencies of @TransactionScoped, there is only the existing JTA API (both for implementation and TCK) -- that's certainly the case for the Resin prototype mentioned above. was (Author: rezarahman): Only @Transactional is being defined in JTA. The older EJB CMT annotations will remain in JTA. @TransactionScoped would belong in CDI. As far as dependencies of @TransactionScoped, there is only the existing JTA API (both for implementation and TCK). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-121: ----------------------------------- @Transactional might also be used without JTA. It would also make the JTA spec dependent on the Interceptor spec - not sure if you are aware of that! @Transactional without the TxAttribute is useless btw. I thought Linda already has plans to add those as well, isn't? http://java.net/projects/javaee-spec/lists/users/archive/2011-12/message/2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Pete Muir edited comment on CDI-121 at 2/17/12 8:00 AM: -------------------------------------------------------- @Transactional is being developed as part of a JTA maintenance release. It will live in the package javax.transaction. If you have any issue with this, please contact Linda DeMichel with your feedback (please cc me). Putting comments on this issue won't help :-) I think the current plan is for @Transactional to be meta-annotated with @InterceptorBinding. If you see a problem with this, then there is an alternative option, which is for it to be made an interceptor binding at CDI deployment time using the CDI SPI. Again, Linda is the person to address this feedback to. Currently all scopes are defined in CDI. I'm perfectly open to addressing whether they should be moved out, but that is another discussion. On this basis, @TransactionScoped is being considered as part of CDI. @Transactional is proposed to have a single member, transactionType, which will be an enum of TransactionType. TransactionType is identical TransactionAttributeType, and indeed @Transactional is identical to @TransactionAttribute. However the plan is to add new, identical annotations and NOT to move the existing TransactionAttribute and TransactionAttributeType. This can't be done due to backwards compatibility requirements. There is also an extensive discussion on how EJB CMT should interact with the new @Transactional, which I would strongly recommend getting involved with, as currently we are having to choose between a set of bad options. was (Author: pmuir): @Transactional is being developed as part of a JTA maintenance release. It will live in the package javax.transaction. If you have any issue with this, please contact Linda DeMichel with your feedback (please cc me). Putting on this issue won't help :-) I think the current plan is for @Transactional to be meta-annotated with @InterceptorBinding. If you see a problem with this, then there is an alternative option, which is for it to be made an interceptor binding at CDI deployment time using the CDI SPI. Again, Linda is the person to address this feedback to. Currently all scopes are defined in CDI. I'm perfectly open to addressing whether they should be moved out, but that is another discussion. On this basis, @TransactionScoped is being considered as part of CDI. @Transactional is proposed to have a single member, transactionType, which will be an enum of TransactionType. TransactionType is identical TransactionAttributeType, and indeed @Transactional is identical to @TransactionAttribute. However the plan is to add new, identical annotations and NOT to move the existing TransactionAttribute and TransactionAttributeType. This can't be done due to backwards compatibility requirements. There is also an extensive discussion on how EJB CMT should interact with the new @Transactional, which I would strongly recommend getting involved with, as currently we are having to choose between a set of bad options. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-121?page=com.atlassian.jira.plugin.sy... ] Reza Rahman commented on CDI-121: --------------------------------- Completely agree with Pete. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira