Sysadmin Field Notes

May 25, 2005

Prakash Malani has a good comparison of the various options for configuring weblogic in his blog. He lays out what's available pretty well.

The option I've gone with is the last option presented, templating the config.xml. Using velocity templates, I can control the configuration to come out however I want. This was all built before the offline scripting tools were really available, and the idea of actually having to have the admin server running first is problematic for me.

Maybe it's an artifact of the way I think about web apps, but I think of them as shrinkwrap software. Hand it off to ops, tell them to untar it wherever they want, run the start script and it should just work. In general I think just about every app server ignores configuration; as if a JAR or WAR is the whole application and is all that's required.

What weblogic really needs is a way to have multiple config files so the developers and ops/engineering stuff is split out. The developer's file contains the -names- of the connection pools, JMS queues, etc. that the code depends on, and then the operations file includes the IP addresses, tuning parameters, etc. that ops should control outside of a codebase.

Currently the config.xml is everything, even though the requirements are totally different for various peices of information. It should be possible for the developers to easily provide a contract for what items are required, but the contract is them implemented by a bunch of config settings that dev cares nothing about. "Give us a connection pool named foo, etc."

This is not specific to weblogic, it's basically every app server I've seen., and a lot of things that aren't even app servers really.