tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ruthenbeck <>
Subject Re: Best Logging practices
Date Wed, 19 Feb 2003 23:15:56 GMT
At 02:43 PM 2/19/2003, you wrote:
> >      One thought though; for web applications you're supposed to get
> > external resources by configuring them in the web.xml and using
> > ServletContext.getResourceAsStream().  This only supports input
> > streams, but I've always sort of felt it should support output streams
> > as well.  Or that there should be some similar mechanism, so that at
> > least the point where you're crossing the web application boundary is
> > explicitly and clearly defined in a standard central location for such
> > information.
>But, once you're cracking open the web.xml, then you might as well point it
>to a directory or JDBC instance.
>The real issue is, of course, that it's SUPPOSED to be difficult to write
>things, as writing things "consumes resources" on the host machine, compared
>to reading, which is non-destructive.
>I do agree, however, that it would be nice to have some persistent area

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 forced, 
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 

In a large application, I'd agree that writing to resources inside the .war 
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 application 
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.

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.

My apologies as this is getting off topic and is better suited for a spec 
discussion forum, but I see this problem repeatedly and had to put my 2 
cents in...


Justin Ruthenbeck
Software Engineer, NextEngine Inc.
Confidential -

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

View raw message