tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Hartung" <>
Subject Re: WAR format question
Date Tue, 04 Feb 2003 21:46:09 GMT
> From: "Jim Carlson" <>
> Sent: Tuesday, February 04, 2003 12:06 PM
> Subject: Re: WAR format question

>    Thanks.  This answers my question, but I'm still left with the
> impression that I'll need to go beyond the WAR format if I want to write
> to a log or flat file DB (i.e., non-temp application file).  Also, since
> containers don't guarantee support for an unpacked WAR (are there any
> containers that truly don't support this?), putting conf files that
> change after deployment in the WEB-INF seems a little sketchy.  At the
> minimum, it adds the hassle of extracting and re-archiving the conf file
> to every edit.

This is an issue with application deployment in general.

The one thing that the servlet spec does not promise you is a place where
you can permanently store infromation. It gives you a temp directory, but
that information is not guarateed to survive a server restart.

This means that a self-contained WAR of any reasonable complexity can not be
deployed into a Generic Container without direct involvement of a user.

In J2EE terms, this user is considered the "Assembler". It appears to me
that the overall goal was that through the use of the XML files, a Container
Specific tool would be created to facilitate the manipulation of WAR,
probably through a GUI.

Doesn't the Tomcat Admin console do something like this?


Beyond that, however, it is pretty clear the that at the application level,
you really have little access or control over how the WAR itself is

The only time that all of these constraints would really be practical would
perhaps be in the embedded environment. Ideally, one should be able to
deploy a WAR to a compatible cell phone.

>    My impression is that WAR was designed around the best-practices
> scenario of having web app instances that don't save local state to the
> filesystem, but use a DB or some J2EE storage mechanism, for ease of
> clustering.  Such apps would probably get their conf from a JNDI resource.
>    However, I still think that the correct location for log files is
> resolved in this scenario.  Those of you using WAR along with file logs
> -- where do you put them?

Since the spec gives you little latitude over how the WAR is deployed, then
it should be clear that you can not rely upon how the WAR is deployed in
your application, and instead must rely on user specified parameters.

So, the simple answer to "wear do my log files go" is "whereever the user
tells you to put them". One way is to take advantage of the various means
within the WAR file, such as the context parameters or env-entry tags. Of
course this requires either an availble utility, or simply having the user
unjar, edit, and rejar your WAR file.

Another option I would think would be to place a file someplace along the
myriad of classpaths that you app can load with getResource, and use that
for parameters. Of course, you can't count on that.

The biggest problem, however, with both of these techniques is simply that
your application can not manage them directly. The application can not write
back any changes it might want to.

If you application has a plethora of options and configuration parameters,
AND you feel pretty certain that you will have access to some persistent
medium (local file storage or remote database access), then all you would
have the user do is tell you how to get to that persistent storage (pathname
on the local system, or the jdbc URL perhaps). Then you can default your
properites to the persistent medium, and provide your own interface.

If you have no wish to rely on the existence of a peristent storage, then
the user will need to make their changes to the WAR directly.

However, the key is that once you've got your WAR bundled...that's it.
Everything else will need to be routed through the classes in the WAR. You
can't create static content and expect the container to implicitly deliver
it. So, that mean you only need to know about where the resources that you
manage are located, and can care less over where the resources that the
container manages (specifically, your WAR).

The biggest issue with this is that it makes it just that little bit more
harder for novice users to deploy applications. I don't think you could
deliver a simple WAR to random end users running against random containers
and expect the installation process to go smoothly. It's almost easier to
deliver the entire thing (webapp and container) as a stand alone server,
then have an installation program ask the questions and do the work.


Will Hartung

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

View raw message