Ant Is Cool

September 6th, 2005

I think I've reached the point in my programming career where I'm about as lazy as you can get. Fortunately I've also started heavily leveraging the power of ant recently as a cross-platform, heavily Java oriented, shell scripting tool.  Shell scripting isn't really the right word for it though because it's really the declarative nature of ant files that makes it work so much better than shell scripts, python, ruby etc.  I don't think about how to do things I just say what I want done and it happens.

Despite how much you can do with so little code in things like ruby, python, perl etc ant takes it to a whole new level with the ability to incrementally compile Java code with one "statement", create jars or copy files with fairly complex include/exclude criteria (not to mention automatically excluding things like CVS directories) and so on.  It's just designed for building stuff.

Combine that with things like the FTP task and Subversion or CVS integration, the ability to exec other programs and integration with Eclipse and I'm in heaven.

The first thing I do when I have professional services work for a client is create a build script that packages up everything neatly and uploads it to our web server for them to grab. Developing EditLive! for XML solutions starts with a script to compile any Java code and build jars to plug in via advanced APIs then open a new instance of IE pointing at the solution.  I can now run applets as easily as I can standalone applications which is a huge boon.

I've even gone as far as implementing our deployment system as a JSP front end to an ant script. The JSP front end lets you pick the values for a few variables (like which product and version to deploy) and which target in the build file to run then hands it off to ant.  The actual rules for deploying products to various places is then just a series of declarative statements in an ant build file.  No need to redeploy the webapp.

Then again, redeploying the webapp isn't exactly difficult.  I have an ant script that packages it up on my local machine then deploys it over to the production server with a couple of keystrokes in Eclipse.  Of course, making it that easy to put something into production probably isn't such a good idea for systems that aren't non-critical systems for internal developers.

I do wish that there was a better Java API for running ant though.  I'm currently running it by exec'ing it in a new process but it would be much nicer to have an API like:

File buildFile = new File("...");
new Ant(buildFile).achieveTarget("upload"); 

I think there are programatic Java APIs for ant but I'm pretty sure they weren't too straight forward.  I probably should look into them again in more detail though.

Promptless Logins For J2EE?

September 6th, 2005

Dear lazyweb,

I'm writing a J2EE (well technically JSP/Servlets but no EJBs) webapp which has two goals:

  1. Secure authentication is required.  Unauthorized users shouldn't be able to access anything except a login page.
  2. Easy access for authenticated users.  ie: Don't prompt users for their password every time they open a new browser instance and don't time out logins.  Prompting the first time they access the system using a particular browser/computer is okay though.  Even prompting once per day would be okay though not ideal.

I realize that these goals tend to conflict to a degree - ie: it's far more secure to log users out every so often so that if someone gets access to a machine they logged in from they don't get access automatically. We'll have to live with that risk and so lets just assume that the systems users are accessing the system from are secure or users are smart enough to always click logout when they're finished.

The whole system will be run over https.

How do you do it?

You can set the session timeout to 0 and it will last forever, but a new session is created when the user opens a new browser instance so you not only have to log in again but now you have a memory leak.  As far as I can tell I have to roll my own system using a cookie that expires sometime in the next millennium and just hope no-one guesses the magical key it holds.  I'm lazy though so I'd prefer to not have to implement my own system and getting it working in a way that can leverage the features of whatever servlet container it happens to be running in would be a major bonus.