Revisions

Back in the days when I switched over from Delphi (the day that Delphi died) I felt the overwhelming amount of frameworks for pretty much everything was giving me a headache. And I think everyone out there will agree with me. Hibernate, Spring MVC, Spring Integration, Spring Data, Spring Mobile, Spring WS, Spring Batch, Hazelcast, EhCache, C3P0, a whole range of Apache Commons - just to name a few prominent ones. Oh boy can this be a pain in the royal butt to learn all of them. An then there's the ever changing world we live in where new versions of open source frameworks come out like crazy. Pretty much a 100 times a year one can get something new to learn, try out, fiddle with, get angry with or embrace.

When I first started using Spring all it was for me was the dependency injection framework with stupid XML config and training that takes forever, costs a fortune and makes no sense. Remember, I came from a world where documentation was pristine (for both Turbo Pascal and Delphi), examples came in spades and the classes started with a T and all interfaces with I. All the separation of concern, testability and other ilities were not so needed in the Delphi world. Also inheritance was in the zone (now we all know it's bad and should be avoided). With Java everything was different and I felt lost.

I turned my attention to something I though would be a little bit more familiar - the .NET framework and C# language. Oh boy was I happy to see the notion of properties built into the language (so missed in Java). I though I've had the world by the balls with this one: modern platform, fantastic language (created by the same guy who created Pascal and Delphi) so I was right at home.

At that time job opportunities for C# web application developers were scarce and so I was sort of forced to stay with Java. At first I hated it with a passion (http://www.ihatejsf.com). In the mean time along came Guice and showed me why dependency injection makes sense and how to do it right. After some time I learned to live with it mostly because I discovered that there's more to it that meets the eye. Basically I learned about Groovy and Grails. That was the sweet spot for me: elegant and dynamic language, similar to Java but oh so much more powerful and a framework that finally doesn't suck like JSF did. That was the best time ever!

With time wisdom came and I started looking around what else can be done with this thing. That was the time when JavaEE 6 came out with Glassfish 3 (man you really have got to love something that's called Glassfish, don't you?). Finally all the stupid things like web.xml went away, web services creation started to be a breeze and all was cool again. Then I leared about EJB3 and all that comes with it. Can't say I was happy with what I saw after living on Grails, Guice and Spring for a while.

Now it's years later. I'd describe myself as TDD junkie with a healthy dose of polyglot programming skills. I've learned a great deal about the so called Spring programming model. I've learned a lot about Spring and the modules it brings to the fold. I learned not to hate XML. I've learned Ruby and got acquainted with Sinatra. Every day is a new challenge and every day I learn more. The more I learn the less I write and the more I integrate.

During all that time there has been only one constant: Internet. All I know, all I ever learned beyond the 6502 assembler, 68k assembler, Pascal, Turbo Vision, Delphi and VCL (which I learned ages ago from dead-tree books) came from the Internet. This is the best, most demanding and absolutely the most rewarding university in the world. All this because of open source projects and awesome communities that make the world go around these days.

It's a beautiful time to be a programmer!

Do we really need another build tool?

Recently I've been getting to know Maven a little bit better. Underneath all the XML fuzz there's a really good, well designed and extremely modular application that does pretty much everything one can ask for (and then some).

With Maven things are simple: bloated XML contains every possible setting for every possible plugin, every possible dependency and what have you. You might hate the fact that it is XML. I say screw it - let's try to live with it.

On many occasions the XML nature has been the corner stone for many people to start developing their own build tools. I'd say their repulsion came from Ant and if so it wasn't totally unjustified. I hate Ant with a passion when it comes to building Java projects. Ant is great for cross-platform imperative tasks (download this, unzip, make a link, go get coffee) but Java projects are a completely different beast. It's not that you can't do it with Ant but rather that it takes forever to do everything (not to mention that everyone is doing it differently).

Like I said people's repulsion to XML configuration files pushed some of them into the hands of Groovy (my absolutely favorite language) to create Gradle. One of my very good friends, Szczepan Faber, works on this tool and I am grateful for his efforts. It makes the landscape of build tools a lot more interesting. It's from diversity that the progress comes in this case.

Being all Groovy geek and loving the language and what one can do with it I must say I am a little bit confused as to why I'd use Gradle. I mean I get that the build file is terse, that the default source/target compiler makes more sense, that I can declare 10 dependencies in one line... But what about plugin support?

From my personal perspective the idea of creating a new tool from scratch is pure nonsense. Maven is the de-factor standard in Java world and not without reason. It does what it does and does it good. Where Maven lacks in features is imperative programming but that can easily be overcome with either custom Maven plugins or GMaven plugin. For me it'd make a lot more sense if Gradle adopted the Maven API for plugins and build on that to gain the much needed functionality into the fold before it is missing.

Like I said before, I get that one can feel intimidated by all the XML in Maven builds. I get that one can mess things up with Maven really bad. I also get that Gradle, Buildr and others might be better in some cases. What I hate about the overall landscape is that the plugins for build systems aren't compatible and even if I'd like to use Gradle to build my next gen rocking cool enterprise java application I'd dead in the water pretty soon because the EAR/EJB archive support in Gradle is non-existent. I hope this changes some day...

Have a nice day!

Tomcat Clustering and a pile of problems

I've been trying to familiarize myself with Tomcat's clustering capabilities today. At the end of it I succeeded but the experience was way less than pleasant. But let's start from the beginning...

At first all seemed really nice: Sunday afternoon, not much to do, some thoughts around playing with Tomcat for the sake of finding out what it's capable of.. Basically the idyll. So I though wouldn't it be nice if I learned how to setup a Tomcat cluster? I already done some horrible things to Tomcat in the past (Single Sing On for instance) but I've never tried clustering. How about that? And so I started what anybody would do - to read the configuration files. No - I'm kidding :) I started to Google for some clustering HOWTO to see if I'm alone in what I'm trying to accomplish. Fortunately it turned out to be a pretty well described topic with some ready-to-copy-and-paste examples. Highly encouraged by what I found myself copying parts of what I found in that miserable HOWTO into configuration of my 2 Tomcats that are supposed to form "the cluster". After about 2 minutes of frantic alt-tabbing, CTRL+C/CTRL+V-ing I arrived at the glamorous point where I was able to start at least one of the Tomcat's to see if the configuration even allows to the server to start. Well, it started, all right. But it didn't work.

Oct 28, 2012 5:14:09 PM org.apache.catalina.ha.deploy.FarmWarDeployer start
SEVERE: FarmWarDeployer can only work as host cluster subelement!

Oh what the heck is this? I though.Wasn't the example from original documentation? I was always banking on those to be really of good quality and now this dissapointment? There's a number of things wrong with the example (and as it turned out with the original server.xml as well). But let's start from the beginning.

server.xml and it's comments

There is a dark place in server.xml that shows how to configure a cluster in Tomcat.

      <!--For clustering, please take a look at documentation at:
          /docs/cluster-howto.html  (simple how to)
          /docs/config/cluster.html (reference documentation) -->
      <!-- <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/> -->

So I removed the comment in two instances but it turned out not to be what I expected. Well it did something (not sure what exactly) but it wasn't all that inspiring. There is however a reference to further documentation. I followed that and then the frantic copy/paste activity started. All was quite nice up until I started Tomcat and saw the SEVERE I mentioned before. Back to Google. And then some. Finally I arrived at this discussion where I learned that the <Cluster> element is supposed to be nested within the <Host> element and not where it was suggested by the original server.xml file. Go figure. Anyways, I moved the section down to the Host and this time

Oct 28, 2012 5:01:34 PM org.apache.catalina.ha.deploy.FarmWarDeployer start
INFO: Cluster FarmWarDeployer started.

Great Scott! It will work now! And so I copied my beloved distributable, servlet-api-3.0-enabled hello.war into the /tmp/war-listen folder hoping to see Tomcat spring to work, install the application and make my day. But nothing happened! The example in Tomcat documentation specifies watchEnable="false" by default. What was going through the mind of that someone who wrote it is beyond my understanding of the universe. Anyways, after I changed it to true finally something started to happen.

Since Tomcat ain't for the faint-hearted I was presented with a puzzle:

Oct 28, 2012 5:29:36 PM org.apache.catalina.ha.deploy.FarmWarDeployer fileModified
INFO: Installing webapp [/hello] from [/tmp/war-deploy1/hello.war]
Oct 28, 2012 5:29:36 PM org.apache.catalina.ha.deploy.FarmWarDeployer remove
INFO: Cluster wide remove of web app [/hello]

What the heck? Cluster wide what? I just installed this application, didn't I? I mean thought it will be enough to copy the file in the proper folder and that should be it, should it not?

As it turns out it does work quite nicely if you specify the deployDir to where Tomcat expects to auto deploy applications (by default webapps, or rather ${catalina.base}/webapps). After I changed that, copied the Cluster configuration to the second Tomcat, started both and copied the hello.war application to /tmp/war-listen both Tomcats have received the proper nourishment and started talking my language.

Summary

There's a number of lessons learned from this encounter. First and foremost Tomcat is just awesome. It's so unbelievably small yet so feature-packed. It just makes my day. While debugging Tomcat configuration issues it really helps to start it (at least under Linux) not by ./startup.sh but ./catalina.sh run. This way you'll have the console to view the logs and to terminate it all in case you're not happy with what you see. And last but not least: Google is your friend. I mean it. It is the one thing all this could not be possible without in terms of knowledge sharing.

Have a nice day!

Maven and Tomcat 7

You might be unaware of this but Maven is capable of running Tomcat 7 as embedded container. The maven-tomcat-plugin has been moved under the Apache Foundation umbrella and is being developed further. The current version is 2.0, packing in both versions of Tomcat, 6 and 7. Setting it up is explained here. All the configuration is very similar to the original one and your IDE will help you out there (at least Eclipse does).

Finally... It's been way to long to wait for an update on this one.

GitHub, Travis and status image

Since not so long ago GitHub provides an opportunity to build OpenSource projects on Travis CI. The integration is quite stunning and includes among other things:

• Single sign-on with GitHuub
• Automatic build setup with a single mouse click
• Status image generation

Well, I tried to setup build of my Spring examples today and Markdown gave ma a little bit of a hard time to figure out how to put together an image link to by build status. Finally I stumbled upon this stackoverflow.com question but the brackets were all wrong. Here's what it should look like:

[![_alt_text_](_image_url_)](_link_)

With the parentheses instead of brackets all works nice :)

And live is good again :)