[
http://jira.jboss.com/jira/browse/JBSEAM-1144?page=comments#action_12359040 ]
Christian Bauer commented on JBSEAM-1144:
-----------------------------------------
There are two sides to this:
- I have nothing against exposing the transaction service as a Seam component if that is
what fits best into the overall architecture. Whatever makes the system more cohesive is
fine.
- How will users perceive and use this extension (independent from how it's
implemented) and what are the long term effects. They will continue using whatever legacy
code they have. Our component will wrap it. There is no migration path because we do
everything for them, wrap and hide their legacy code. They will not realize that they
should use JTA - from a users perspective everything works fine. They will start new
projects using org.hibernate.Transaction and Spring transaction management. The JTA
vendors will not realize their stuff should be made easier to use because nobody is using
it. You will never be able to remove these components. The time is _now_ to break this
circle, we only get a chance like this every 5 years.
Michael, note that I am not saying that we should not implement what you have done, it
will certainly be integrated into Seam. The question is how we communicate it to users.
IMO it should be hidden as good as possible behind a "migrate to JTA" manual.
But, from experience I know that if we all forget to agree on this at this stage, it will
not happen and the wrapper will just creep into the documentation with the negative
effects I describe.
Btw, some colleagues are currently working on an extension to the main Hibernate tutorial
that describes how to install JBoss TS with JTA, right after Hello World. The overview for
the other JTA providers posted yesterday on the forum is also a great resource we need to
leverage for this kind of documentation. Let's do what we can on this front before
this component is committed.
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