Soapbox Rants and Raves

I was searching for some information on using the Eclipse IvyDE plug-in and found a post that reminded me of some work I did last summer. For the most part, I’m happy with the way the IvyDE plug-in works, but sometimes you have to be a little tolerant of its usability issues. Every so often, IvyDE seems to forget about my configuration and refuses to add libraries to the class path. My only option is to remove Ivy Dependency Manager and re-add it to the class path.  One problem that I’ve been unable to solve, is the integration of an Eclipse Web Tools Platform (WTP) project and Ivy; I cannot get the Ivy resolved libraries added into a “Dynamic Web Project”, making them available to the Tomcat. I have tried a dozen different configurations and settings with no success. Hopefully, I will get this working in the near future. If anyone has this working, please give me some tips!

The real thought behind this post was echoed in this post by Daniel Spiewak, So Long WTP, Embedded Jetty For Me. I was really fired up about Jetty last summer. When compared to my experience developing Weblogic-based applications, the utter simplicity and flexibility of Jetty was amazing. I was working on a custom Servlet-based web service framework and decided to do my development with Jetty. I created a very small Java program that configured Jetty to deploy my Servlet, in about 20 lines of code! The best part is there was no special Eclipse project type, no special environment, and zero deployment work; making debugging and testing especially easy.  I never used the word embedded when I talked about Jetty, but that was exactly what I wanted. I always deployed in the Weblogic container because of our corporate standards. I should have explored this a little more, further highlighting the point that Weblogic and all of its complexity is truly unnecessary.

Following the BEA Bible, you end up with specific machines, specific file systems, specific networking, and hardwired clusters. Combine that with an environment that is highly controlled, it can take a dozen change control tickets and multiple days to bring up a new instance. Not exactly what I call agile or responsive. How cool is would it be to just drop a WAR file on a machine (any available machine), launch java to bring up a web server, add it to the load balancer and instantly expand your processing capacity? Pretty powerful idea, I think.

Embedding a web server is a good idea when building a web-based application, both for development and operational reasons. A good example is the Hudson Continuous Integration tool. Hudson is distributed as a single WAR file that you can pop in any Servlet container; but it also includes an embedded web server. This approach is becoming more and more common, as several open-source and commercial products are shipping their products with embedded web servers. The real benefit is flexibility. It literally took me seconds to get Hudson up and running; no messing around with Tomcat, no configuring security realms, no anything! It allowed me to focus on Hudson, rather than the environment to make it work. Down the road, if I want to deploy Hudson in the standard application server environment, it should be an easy switch, This is quite different from my recent experience installing a few open-source code review tools; installing multiple Python packages, configure an Apache web server, setting up database servers, etc. I don’t think I have to say much more; the better choice is pretty obvious.

It is pretty hard to beat the Eclipse WTP – Apache Tomcat integration as a development environment, but directly embedding Jetty into your environment (no WTP) would make the environment even simpler. I have been trying to encourage teammates to develop from a container independent perspective, demonstrating higher productivity with no additional risk to the project. If we can move from large, monolithic applications to smaller, self contained services, the attractiveness of Jetty goes way up. The flexibility of running a moderately sized collection of small, independent services, verses a small tightly coupled clusters of monoliths, has to be an attractive architectural vision.

Unfortunately, many corporations don’t eagerly embrace open-source software solutions, preferring to pay for name recognition and guaranteed support. I personally feel that Jetty is a viable option, but it seems to be relatively unknown to most developers. Apache Tomcat and JBoss have a much higher exposure level, giving them more perceived viability. Jetty is no slouch, check out the Powered by Jetty page. Hopefully, this and Daniel’s post demonstrate there are alternatives to the J2EE Silver Bullet, and that we don’t really need to do everything by the J2EE book. There are a lot of simple alternatives out there for us to take advantage of, all we have to do is keep an open mind!