It’s been nearly six months since BTM 1.2 has been released. A successful project should be releasing often, at least more often than once every six months. This is something I will need to improve with future versions: less new features but shorter release cycle.
Recently the community has been growing steadily even if the users mailing list does not reflect this. It seems that people prefer to contact me directly. I don’t have a problem with that but it makes the project feel unactive while this is absolutely not true.
To cut a long story short, a lot of newcomers sent me comments, reported bugs and asked for new features. I want to make everyone happy if I can so I don’t feel like answering back sorry, please wait until the next release especially when the release cycle is so long.
The feature I like most in 1.3 certainly is the embedded JNDI provider. Thanks to it it is now possible to use BTM only with standard API: only JDBC, JMS, JTA and JNDI APIs are needed to access the transaction manager and its connection pools, be it when running in a standalone JVM or when embedded in a servlet container like Tomcat. The only non-standard required call left is to bootstrap the transaction manager. While this is taken care of by Tomcat when both are integrated or by Spring if you happen to use it there is still a gap if you just want a bare bones JTA implementation. Nevertheless I think this should satisfy Christian Bauer.
Want an example of what it looks like ? Ok, here is one:
// create JNDI context Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "bitronix.tm.jndi.BitronixInitialContextFactory"); Context ctx = new InitialContext(env); // get JDBC datasource with unique name 'jdbc/datasource' DataSource ds = (DataSource) ctx.lookup("jdbc/datasource"); // get UserTransaction UserTransaction ut = (UserTransaction) ctx.lookup("java:comp/UserTransaction"); ctx.close();
Again, I did my best to make this as easy as possible:
- there is no configuration parameter needed to activate this mechanism.
- it consumes zero resource when not used.
- it can work in parallel with any other JNDI provider.
- all resources (JDBC and JMS) are available under their unique name.
- the user transaction is available by default under the standard name
Obviously, any framework or library that can get those resources from a configurable JNDI provider can take advantage of this feature. A good example is Hibernate. I just hope this feature will ease integration with all frameworks that can take advantage of an JTA implementation