tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Hartung" <>
Subject Re: Best Logging practices
Date Thu, 20 Feb 2003 00:12:13 GMT
> From: "Justin Ruthenbeck" <>
> Sent: Wednesday, February 19, 2003 3:15 PM
> Subject: Re: Best Logging practices

> I'm sure this is a contentious topic ripe for disagreement, but I see no
> reason why a .war file should be read-only.  The point of packaging your
> application in such a way is to make a single cohesive unit that is
> deployable across various vendors, right?  Then why should users be
> if they don't want, to store application-SPECIFIC data outside of that
> application.  Seems to me that it only moves us away from our original
> intention.

My view is that the WAR file is identical to an EXE file (on Windows). A
single, atomic unit that represents the application. Looked at in this way,
you'll notice that most (if not all) applications never see the "inside" of
the EXE file. They simply don't care.

The reason that a WAR is not writeable is that there is simply no guarantee
that the WAR is placed upon a writeable medium. One (albeit contrived)
example is that the WAR could be shared across several different servers
running simultaneously. So, in a Unix environment, you might have the WAR
file in /usr/local/war/App.war. And its permissions might simply
be -r--r--r--. Since there is no guarantee that the container even explode
the WAR file, here you have a case that would prevent your application from

Also, in this example, you'd have a problem with multiple servers updating
shared state in the common WAR.

The other extreme may be that the WAR is buried in ReadOnly FLASH on a small
embedded server someplace. All sorts of scenarios come to mind as to why a
WAR could be read only.

> In a large application, I'd agree that writing to resources inside the
> file has limited advantages -- it's not like you want to store data inside
> the war file instead of a database.  But even large applications (such as
> the one I'm working on) can eventually acquire awareness of their
> surroudings and environment that they discover over time.  If you force
> users to supply this information by setting param values in the web.xml or
> using external xml configuration files or properties files, then you've
> lost the simplicity of a single application archive.  Since the
> has no portable place to store this data, you're stuck specifying a
> location outside the war and we're back to the same problem.

Yup! Pain in the neck. Plus, you can not provide a "configuration free" web
interface to adjust those parameters. You will always need at least ONE
parameter from the user (where and how can I persist information). If they
need to supply The One parameter, might as well toss in the rest as well.

> Seems better to me to allow an application to change its own configuration
> in cases like this -- regardless of whether the app is packed or
> unpacked.  Think of this as application meta-data -- data that an
> application would want to store persistently and, for sake of consistency,
> should be stored along with other application configuration information
> inside the war.  For small applications with very limited data, this could
> even be a central data store and would allow the movement of applications
> between servers and hosts without the need to worry about file
> compatibility, directory structures, or permissions.

Now, I'm not really up to speed on this (I only know it exists, and I've
read a couple paragraphs of the spec).

In many ways the new Preferences API handles some of this. It seems that the
Pref API is supplied, and implemented by JDK 1.4. I suppose that it's
configurable in some way at the JVM level, being as it's supposed to be
backend neutral.

But it seems like it offers a "free", simple Windows Registry-esque
functonality to Java programs, including WARs. If you don't mind limiting
your WAR to JDK 1.4+, then you have this capability now: a simple mechanism
to save configuration options and what not. This mechanism addresses a lot
of issues for WARs I think.

I, too, would like to have a "standard" mechanism to help configure WARs
that is external to the WAR, yet perhaps maintained by the container. For
example, (maybe Tomcat does this, I'd have to look), it would be nice to
have access to the JNDI namespace (like env-entry's) at, say, the Context
level within the container that lets you specify local configuration options
without cracking the WAR. The trick, of course, would be to not have the
WARs env-entry's overwrite the locally specified ones.

But, if the Preferences API is guaranteed to persist some small amount of
information, portably, across implementations, then that can be a good
start. You can have the defaults buried in your WAR, persist them into
preferences, and then have your app pop up a configuration page as soon as
it's started to ask for the magic "Where to save LOTS of data" parameters.

I think that access to volumes of persistent data will always be a
application specific configuration issue. Someone will always have to
provide some kind of information (Directory name, JDBC URL, JNDI, whatever).
You'll never be able to assume (portably) that you have persistent volume
storage available without configuration.


Will Hartung

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message