Yes I am aware that JEE has evolved hugely and have used Glassfish, the days of it's over complexity are gone. I still don't see much of a business case for it unless I have need of EJBs to provide distributed transactions, or message queues and so forth.
Rewriting the wheel for transactions would be a little crazy I guess. If I do have to go the route of implement XA I'll certainly give JEE more consideration, although I'm still interested in what can be achieved with stand alone bitronix. I'll check out FlowLogix later, thank you. John ----- Original Message ----- From: Lenny Primak To: Tapestry development Sent: Tuesday, August 27, 2013 5:25 PM Subject: Re: Transactions and AfterCommit John, have you really, actually looked at the state of JEE these days? It's trivial to set up, trivial to develop in, and IMHO, easier to learn than many other things in Java. Yes, the "old pre-JEE5 days were bad" but JEE 5,6,7 are a whole different animal. You can get it up and running in less than 10 minutes (Glassfish) and it's much easier than trying to cobble up the same environment from different pieces. Also, we developed a module (FlowLogix) that integrates most things JEE with Tapestry and Shiro. I have seen this again and again, my customers have the perception of "JEE bad/complicated" and spending at least 5x the time trying to cobble up an environment that tries (unsuccessfully) to replicate what JEE is doing. On Aug 27, 2013, at 3:49 AM, John wrote: > I'm reluctant to move my small/medium sized pure Tapestry project into a JEE environment even though I am updating accross multiple databases and have non-trivial needs for transactions. I don't see sufficient justifcation to use JEE unless there is substantial need of EJBs. > > So far I have got away with using CommitAfter and some more manual coding to handle the transactions. The main reason CommitAfter sucks IMO is because it is coded on the interface and so breaks the rule about hiding implementation. For that reason alone IMO it needs to be addressed. > > If I do decide to go into XA I will use Bitronix or similar over JEE and code my transactions manually in the implementing classes, unless more demand for EJB arises. > > John > > > ----- Original Message ----- > From: Taha Hafeez Siddiqi > To: Tapestry development > Sent: Sunday, August 25, 2013 1:17 AM > Subject: Re: Transactions and AfterCommit > > > I have used spring and JEE in the past and I don't think every project needs them. The transaction support comes with a lot-n-lots of dependencies (at least at that time it was the case :)) and some people don't like it. > > All we need is a support for @Transactional->Required /readonly. I think if we support them, most of common requirements are met. > > regards > Taha > > On 25-Aug-2013, at 4:18 AM, Lenny Primak <lpri...@hope.nyc.ny.us> wrote: > >> I would leave everything as is now. >> Tapestry should not try to implement or re-implement full transaction support. >> This has already been done with JEE or spring. If a user wants this support, they should just use what already exists out there. >> >> >> On Aug 24, 2013, at 3:18 PM, "Thiago H de Paula Figueiredo" <thiag...@gmail.com> wrote: >> >>> On Sat, 24 Aug 2013 09:39:11 -0300, Taha Siddiqi <tawus.tapes...@gmail.com> wrote: >>> >>>> Hi everyone >>> >>> Hi! >>> >>>> There are two @CommitAfters and both work differently from each other. >>> >>> This is a problem >>> >>> Here's my suggestion: >>> >>> 1) Leave the @CommitAfter implementations the way they are now for backward-compatibility reasons. >>> 2) Mark them as deprecated. >>> 3) Use EJB's @TransactionAttribute annotation instead of tapestry-hibernate and tapestry-jpa defining different annotations. >>> 4) Implement the different transaction attribute types described in http://docs.oracle.com/cd/B32110_01/web.1013/b28221/servtran002.htm. >>> >>> Question: use JTA? I don't know. >>> >>> -- >>> Thiago H. de Paula Figueiredo >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: dev-h...@tapestry.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: dev-h...@tapestry.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
