[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1144) Make org.jboss.seam.util.Transactions a seam component
[ http://jira.jboss.com/jira/browse/JBSEAM-1144?page=comments#action_12358911 ]
Christian Bauer commented on JBSEAM-1144:
-----------------------------------------
"However, the biggest problem I have with the strict use of JTA in Seam it's
dependence on JNDI. There may be many great JTA runtimes available but they become a beast
(with the exception of microcontainer) to configure when it comes to trying to correctly
expose them with JNDI not to mention your datasources that must be wrapped and exposed
through JNDI as well. "
Then let's fix that. We should _not_ wrap a standard API. The "benefits" you
list are all just nice words, wrapping does not make things more portable (if what you
wrap is by definition already an interface), more lightweight (what does that mean?),
easier to configure (making JTA providers easier to configure makes stuff easier to
configure) and it does reduce dependencies (on what? jta-api.jar?)
Folks, it is time to put more pressure on vendors who provide JTA services. They need to
make their stuff easier to setup and use. The solution is not another layer of transaction
wrapping in Seam, you end up with an horrendous stack that you will _never_ be able to
deprecate.
And there is no such thing as "applications that don't need JTA". Seriously,
realize that this is the standard interface in Java! What else do you want to use? JDBC?
EntityTransaction? Spring magic?
If you want to set transaction boundaries, you do this with JTA or you have a container
that understands @TransactionAttribute. I even think the addition of @Transactional in
Seam was a serious mistake and I don't know why Gavin (who does know better) added
it.
Make org.jboss.seam.util.Transactions a seam component
------------------------------------------------------
Key: JBSEAM-1144
URL: http://jira.jboss.com/jira/browse/JBSEAM-1144
Project: JBoss Seam
Issue Type: Feature Request
Components: Core
Affects Versions: 1.2.1.GA
Reporter: Michael Youngstrom
Fix For: 1.3.0.BETA1
Attachments: seam-tx-2.zip, seam-tx.patch
I know this is probably a loaded issue but please hear me out. :) It would be nice if
org.jboss.seam.util.Transactions was replaced with a Seam Component just like everything
else in Seam. This would allow for pluggable Transaction Management providers and pave
the way for support for Spring Managed Transactions, JPA Local Transactions, and true
Hibernate Local Transactions. This will allow Seam applications to run without a
dependency on microcontainer in tomcat and allow for tighter Framework integration with
spring and others.
I would personally be more than willing to do the work of making the an initial
JTATransaction component(s) as a replacement for org.jboss.seam.util.Transactions and
would also create a SpringTransaction component as a proof of concept for extending the
Transaction component.
One problem I can see off hand is we may have to interact with a transaction in some
places where a Seam ApplicationContext is not available. However, I wonder if confining
Seam transactions to a seam call might help simplify matters anyway? For example
transaction cleanup could take place in the @Destroy of the transaction component instead
of in the ExceptionFilter?
Also, this wouldn't be looked at as a JTA replacement but rather a service
abstraction. Just like any other java webapp if you're using enterprise services such
as EJBs or JCA JTA would be required. if you're running on tomcat or some other
simple web container a resource local transaction manager (Spring's abstraction,
JPA's, or Hibernate's) can be used.
I'm sure there are tons of other problems I'm not looking at but worst case
scenario this issue would be a great place to document them and to refer rejected feature
requests. (for example JBSEAM-1118)
What do you think?
Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira