Nope - no coupling required :) What I'm proposing is purely restricted to Hibernate's existing dependencies and would work for any TM implementation, not just Atomikos or JOTM.
It is the TM-specific TransactionManagerLookup (or perhaps a TM-specific JTATransactionFactory) that would choose the implementation to use at runtime. On Thu, Jun 19, 2008 at 5:49 PM, Chris Bredesen <[EMAIL PROTECTED]> wrote: > Les Hazlewood wrote: >> >> I agree with you Chris, it does better simulate it. But Hibernate has >> always been deployable outside of a container. Shouldn't it retain >> that philosophy in its code base as well, architecting flexible >> approaches that work seamlessly both in a JEE container and out? >> >> That's my belief... > > Sure, and that's exactly why all this stuff is pluggable. An alternative > would be for the TM projects to incorporate implementations of the Hibernate > classes that most efficiently use their own APIs. MySQL, for example, > provides a JBoss ValidConnectionChecker that is statically linked to their > own driver. Collaboration like this is great, IMHO. > > Does your proposed implementation require Atomikos to be on the classpath in > order to build Hibernate? The use of JNDI decouples Hibernate from the TM > in a well-specified way. > > -Chris > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
