Saturday 20 January 2007

Platform for Internet based desktop applications

Lately some people have been predicting that applications that are installed locally on a user's computer are on their way out and will be replaced by online applications. When someone wants to e.g. write a document he surfs off to his favourite word processing site instead of starting MS Word.

There are obviously benefits with this approach.

  • No need to install local copies and keep them updated and functional.

  • Easier to switch between vendors when you don't have to make an upfront investment in a sofware package. (Although I don't doubt that vendors will do everything they can to lock users in..)

  • Software piracy should become more difficult


Currently the best example is probably Google Docs & Spreadsheets. It's an impressive piece of Javascript. But is Javascript really the platform we want to use for implementing quality online software? These sorts of things were clearly not the intended use for the language.

Maybe it's time to bring back Java applets from the dead and brush it up a bit? If online applications are going to be a success I think we need something better than a scripting language on steroids.

Saturday 13 January 2007

Configuring a webapp

One thing I miss in J2EE webapps is a good way to configure the application outside the .war file. I want to be able to ship a .war file together with a properties file that the user can edit without having to unpack and re-pack the .war file. I also want to be able to deploy multiple instances of the same webapp in a container. Each having its own properties file.

There are a number of ways for a webapp to access properties.


  • A file under the web application root using ServletContext.getResource(AsStream)(). The problem with this is obviously that the file is inside the .war file.

  • Through the class path using Class.getResource(AsStream)(). Here you can access files outside the .war file. But there is a problem finding out what file to actually load in a particular webapp. At least if you use the init() method of a servlet. If you deploy several instances of the same webapp the thing that will be different is the context path that they are deployed under. And this information is only available in the HttpServletRequest object, not in the ServletContext.

  • Through system properties. This has the same problems as using the classpath and it may also not always be possible to set system properties parameters when starting the jvm.



I have installed a number of web application where I have had to find a property file deep inside the application server's deployment directories and edit it. Is there really no better way?