BTM 3.0 release preparation

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

BTM 3.0 release preparation

Ludovic Orban-2
All,

Looks like my last complaint about Brett Wooldridge's Bitronix-HP branch (https://github.com/brettwooldridge/bitronix-hp) has now been addressed, which is absolutely fantastic. Thanks again for all that hard work, Brett!

Here's a quick list of the things that need to be done before we can perform a release, at least in my opinion:

 - Add support for Javassist on top of JDK proxies and CGLib ones, Hibernate has been using javassist by default for a long time so it's probably worth supporting that as well.
 - Fix the important bugs. I've re-targeted all the open ones at the new 3.0.0 version but not all of them should be considered.
 - Leave out the NIO disk journal module, I still consider J's work not mature enough to be part of the official release.
 - Merge-in the concurrency changes I made in 2.1.3.
 - Drop support for JDK 1.5, is that still needed?
 - Drop the ZIP distribution, is that still needed?
 - Check that the Tomcat and Jetty lifecycles do work with Tomcat 7 and Jetty 8.

Anyone has anything to say about this plan?

Thanks,
Ludovic
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BTM 3.0 release preparation

Brett Wooldridge-2
Ludovic,

I have checked in a factory that generates Javassist-based proxies.  In my tests, the Javassist-based proxies are about 10-20% faster than the Cglib-based proxies.  Additionally, I changed the auto-detection code to detect when Javassist is available in the classpath and use the Javassist proxy factory.  As before, the user can force which proxy factory to use by setting the 'bitronix.tm.jdbcProxyFactoryClass' property.  The default setting of 'auto' will always choose the fastest available factory for the runtime environment.

With respect to the NIO disk journal, I concur.  I my experience it frequently failed the unit tests.  However, Juergen introduced abstractions which seem worth keeping which leave open the possibility for alternate disk journal implementations in the future.  These abstractions are present in my fork, and have proved harmless over the past year with them in place.

Dropping JDK 1.5 is your call.  I see no particular reason to drop it, other than the inability to use a few concurrency APIs that were introduced in Java 1.6.  Bitronix now compiles successfully in all JDK environments.

I think we can drop the ZIP distribution.

That's my feedback.

Regards,
Brett


On Tue, Dec 4, 2012 at 9:23 PM, Ludovic Orban <[hidden email]> wrote:
All,

Looks like my last complaint about Brett Wooldridge's Bitronix-HP branch (https://github.com/brettwooldridge/bitronix-hp) has now been addressed, which is absolutely fantastic. Thanks again for all that hard work, Brett!

Here's a quick list of the things that need to be done before we can perform a release, at least in my opinion:

 - Add support for Javassist on top of JDK proxies and CGLib ones, Hibernate has been using javassist by default for a long time so it's probably worth supporting that as well.
 - Fix the important bugs. I've re-targeted all the open ones at the new 3.0.0 version but not all of them should be considered.
 - Leave out the NIO disk journal module, I still consider J's work not mature enough to be part of the official release.
 - Merge-in the concurrency changes I made in 2.1.3.
 - Drop support for JDK 1.5, is that still needed?
 - Drop the ZIP distribution, is that still needed?
 - Check that the Tomcat and Jetty lifecycles do work with Tomcat 7 and Jetty 8.

Anyone has anything to say about this plan?

Thanks,
Ludovic

Loading...