VMware for Java development and testing
I just got a beta announcement for VMware Workstation v6.0 which looks to have some pretty nifty new features. This release adds Vista support, multi-head support (different monitor per VM or single VM on mutli monitors), headless support (run a VM in the background without Workstation UI), and a set of automation APIs to allow scripted or programmatic interaction with the VM.
In addition, one of the features I thought sounded interesting is what they call the “Virtual Debugger” for VS and Eclipse. From what I gather, this means an Eclipse plugin that uses the automation APIs to start a VM, deploy a Java program to the VM, and communicate between the Eclipse remote debugger and the Java app in the VM. I am sure all of this is possible today with 5.5, but the productivity aspect of the Eclipse integration sounds pretty cool, not to mention that I bet it does more than I mention here.
On that note, if you aren’t using VMware Workstation, you probably should be. I think it is easily one of the most useful software tools that I use and I don’t think I could live without it for QA and integration testing. I spend a lot of time evangelizing VMware to my clients and friends in the Java world and it just amazes me that more people aren’t using it.
By the way, for $299 you can get a VMTN subscription that includes a bunch of VMware software for development and testing. Go get it.
Commons-logging classloader woes
In the past year or so I have had a recurring nightmare in dealing with Apache’s comons-logging project and its pervasive (and I think misguided) use by a lot of open source projects. The difficulties are well known to those who have had issues using it within web apps on many different web containers, but I think a lot of people are still in the dark about how bad some of these problems are.
I think the memory leak issues have been resolved by simple means, but the use of the dynamic discovery mechanism continues to baffle me to this day. I think this only accurately works in simple java applications that all share a simple classloader mechanism. The problems with commons-logging classloader tricks first showed up in servlet containers because of the classloader heirarchy and I have spent many hours working through those issues in the past year or maybe even two. Today some of us in the OSGi community have run across it again trying to use commons-logging within OSGi frameworks (more specifically, libraries that use commons-logging).
Lather, rinse, repeat…
I have pretty much had it with commons-logging and long ago started using the slf4j library and its toolbox of hacks to get around the dynamic discovery mechanism. Slf4j is similar to commons-logging except that you specify your logging imeplementation by including a log adapter as a jar file so the linking is static. On top of that, slf4j includes a facade that also imeplements the commons logging API so that you can take out commons-logging altogether and use slf4j instead. Obviously this is mainly useful because many, many open source projects blindly use commons-logging even though it is known to have had these issues for quite some time. I have done this many times in the past year with great success, so if you even remotely suspect commons-logging causing problems in your app, I suggest reading this page and give it a shot.
