Just bundle it..

I used to work at the operations department. These days I work in the software development department. So I'm in a situation where I deliver products to my old co-workers and because of this I usually think an extra step when it's time for product delivery. I want the product to install smoothly and any upgrades should be simple to perform. Finding bugs/problems during deployment is never fun. Service windows are short.

For the application I'm working on right now I'm toying with the thought of bundling everything in the war-file. What we have is a fairly simple web application with a number of servlets, service classes etc. There are also a number of batch jobs and some JMX MBeans and it's all wired up so that it relies on the application server providing a transaction handler. There are also a ton of configuration strings stored in the database and sprinkled out through a few configuration files.

I'm thinking it would be cool, and possibly useful, to distribute a self-contained war file that comes with it's own datasources and transaction handler (Atomikos), it's own batch processing stuff (Quartz) and a built in JMX-server (not sure which one to use) and the whole thing even comes with a built in servlet engine (Winstone) With all of that in place the operation staff only has to do the following to run it

$ java -jar application.war

Possibly with a few added environment variables to point out external configuration files. Things like database URLs, usernames, passwords, AJP ports etc are probably best left outside the war file.

If I was still in operations I would be delighted to see an application designed like this. I know Hudson (CI software) works like this and I think it's really neat.

Football season

The 2009/10 season of Premier League kicks off on the 15th of August. I'm starting to get all excited and worked up. It'a a difficult season to predict. I am, of course, an Arsenal fan and I'm trying to keep my expectations at a realistic level.

The loss of striker Adebayor will of course be noticed but how much will we notice the return of Tomas Rosicky ? I think he was injured most of last season and if he has managed to get back into shape I'm sure he will strengthen the midfield and add to the creativity together with Fabregas and Arshavin. Actually, a starting line of Rosicky, Nasri (injured at the moment), Arshavin and Fabregas sounds quite formidable. And the fact that we also have players like Denilson, Eboue, Diaby and Ramsey on the bench feels reassuring.

The addition of Thomas Varmaelen to the defensive line is also good news. I'll admit I had never heard of him before even though he was the team captain of Ajax!

But how will Arsenal manage on the offense without the Adebayor? Will it be enough with Eduardo, Van Persie, Bendtner and the youngsters Carlos Vela and Theo Walcott? I would love to see Wenger sign Huntelaar from Real Madrid as an addition to that line.

The first game of the season is an away game against Everton. That's an opponent that deserves respect. I can't remember if they ended 5th or 6th last season but they sure have a strong team and I don't think they lost any key players. I heard rumours of Lescott leaving but I don't know if that deal went through.

Speaking of deals, what are Man City up to? They've managed to snatch a pretty impressive bunch of players from different leagues. Can they make the team work together or will they fall flat?

Of the top four I think Chelsea has managed to come through the Silly Season without loosing any key players. I haven't been following the deals so closely but I heard rumours that Lampard and Terry might be leaving but as far as I know they haven't signed for new teams. With Manchester United suffering a few big losses and Liverpool maybe selling a few key players I actually think Chelsea might win this years league.

Java - a resource hog?

I was playing around a bit with groovy on grails today when I noticed the following in the Activity Monitor. Quite impressive huh? ;-)

Form authentication, LoginException and JSPs

This is another one of those posts I hope google will pick up and index for all of those who find themselves in a situation similar to the one I found myself in today...

We've developed an application that lives in a JBoss server. In order to access the application you need to login with a username and a password. A pretty common scenario I would imagine. We handle this by delegation to a subclass of the login module DatabaseServerLoginModule provided by JBoss. Our subclass overrides the method getUsersPassword() and does some extra SQL-stuff and we've also put in some more validation etc in this method. There's probably a bit too much in there. Some of the validations will throw LoginException when some of the criterias are not met. If an exception is thrown this will propagate through the whole login mechanism and the user will be met by the page defined in the page form-error-page directive in the login-config section of your web.xml file.

Now, in order to actually show some information about the LoginException we have to define a Valve first. This was completely new to me and I wasn't very hopeful. But after some reading I figured that the following information should go into the file WEB-INF/context.xml

<?xml version="1.0" encoding="UTF-8"?>
<Context>
<Valve className="org.jboss.web.tomcat.security.FormAuthValve"/>
<Manager className="org.apache.catalina.session.StandardManager"
pathname=""/>
</Context>

Once that information was in the file the exception from the login module became available through the attribute j_exception on the users session and we could present the user with a valid reason for the failed login.

Yes, I know that there is a common belief that when it comes to logins and security you should not really tell the user what went wrong. Giving away too much information might actually help the bad guys trying to get in. I agree. But in this case my vote doesn't count.

Some of the links in the above post lead to outdated versions/pages. The above was implemented on JBoss 4.2 on Java 1.5

Refactoring time

Okay, it's refactoring time at work! Or, too be honest, I shouldn't call it refactoring. Without a systematic approach and proper test coverage you can't really claim to be doing refactoring. You're simply "changing stuff".

Anyway, I'm changing a lot of stuff. The application I'm working on is a tangled mess of non-thread-safe, non communicative code that was written a few years back by some people who were very pressed for time and, to be honest, not very good at java programming. But hey, it's been working fine for a few years now and the reason we're rewriting some parts is to show our client that spending money on maintaining code is a good thing.

Right now I'm focusing on breaking up the application into separate layers. I'm bringing in tons of new classes that will be useful throughout the application. The previous model focused mostly on use cases and the objects used for use case A were not reused in use case B, so there is quite a lot of duplicate code in there but because the code is so non communicative it's difficult to see the duplicate parts.

Since the application wasn't really layered to begin with there are tons of places with tightly coupled code. I'm taking the sledge hammer approach to this and just smashing those couplings. Why should the class that's responsible for retrieving data need to know stuff about html forms? And why is the html code for producing drop down menus hidden way back in a utitily function of a servlet? And why are there so many scriplet tags in the JSPs? I'm busy writing taglibs now..

My time estimate for doing this job is way off. I've probably underestimated it by 50% or so. But I think that's mostly due to me having to rewrite more than I expected at first because of all the intricate dependencies. Once they are gone I think we'll be back on track again and even if I'd missed by 200% it would still be worth the effort. Once this job is done we'll have a good solid foundation to build general purpose functions on and we can start to replace all the use case based functionality.

My friends through this journey are:

• The Spring framework - thanks for those jdbc templates and the error handling!
  
• Atomikos - thanks for the XA!
  

Spring, DB2 and Atomikos

A while back I had a really hard time finding out how to configure a DB2 XA datasource using Spring and Atomikos. So this is for all you other people battling DB2. Posting this on a google blog will hopefully make google pick it up :-)

<bean id="dataSourceSelmaXA" class="com.atomikos.jdbc.AtomikosDataSourceBean" destroy-method="shutdown">
  <property name="xaDataSourceClassName"><value>com.ibm.db2.jcc.DB2XADataSource</value></property>
  <property name="uniqueResourceName"><value>UNIQUENAME</value></property>
  <property name="xaProperties">
    <props>
      <prop key="serverName">HOSTNAME</prop>
      <prop key="portNumber">PORTNE</prop>
      <prop key="databaseName">DBNAME</prop>
      <prop key="user">USER</prop>
      <prop key="password">PASS</prop>
      <prop key="driverType">4</prop>
     </props>
  </property>
</bean>

Make sure you use driverType 4. Otherwise you'll most likely need a local DB2 client installation. That's what the error messages lead me to believe anyway.

Automatic tests

This is just a post to share a link. See http://java.dzone.com/videos/configure-your-ide-run-your for a guide to how you can automatically run your unit tests from within Eclipse. Editing and saving and having the automatic compiler fire off your unit tests is quite clever and I'm guessing it will save me a couple of hundred clicks every day