tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven J. Owens" <>
Subject Re: Best Logging practices
Date Wed, 19 Feb 2003 22:53:50 GMT
On Wed, Feb 19, 2003 at 02:43:50PM -0800, Will Hartung 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.

     I don't care where it actually gets stored, I'd just like a nice,
tightly defined control point, pretty much the same reasoning behind
getResourceAsStream to begin with - you're inevitably *going* to need
to get at external things, so instead of just living with people
breaking the model to go outside, provide a mechanism to allow them to
define external resources, and put it in the main configuration area.

     The fact that you have to crack open web.xml is orthogonal to
that reasoning - though it still points back to my earlier complaint
about jars and webapps and editing the contents.
> 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.

     Is that really the reasoning behind it?  
> I do agree, however, that it would be nice to have some persistent area
> available.
> Minimally, it would be nice if the container was supposed to offer up a
> persitent implemenation of the Preferences API, or a writeable JNDI
> implementation.

     This, definitely.  JNDI is used in the spec for database
connection pooling.  I'm not actually familiar with the preferences
API, though I'm glad it's been added (and I hope they did it right).
I'd lean towards a secondary web.xml file, similar role to web.xml,
and maybe gotten at via the preferences API, but meant for a
preferences sort of use - i.e. WEB-INF/web.xml controls the main
configuration of the webapp, WEB-INF/preferences.xml controls the
user-configurable aspects of the webapp.

> However, to be fair, I think a lot of that motivation is being sucked into
> the J2EE side of the equation. It's a real question how long Servlets will
> be stand alone at all.

     Interesting.  If by J2EE you mean simply adding EJBs to the
equation, I've seen significant reluctance to use EJBs in the
industry, though I wouldn't be surprised to find forces on the vendor
side pushing in that direction regardless.  If you mean all of the
other bits that go into a J2EE implementation (JNDI, JMS, etc)...
well, I have to say, those are handy, and most of the work I do takes
place in a context where it makes sense to have those bits available
too.  But I think it'd be bad for servlets to be inextricably bound to

Steven J. Owens

"I'm going to make broad, sweeping generalizations and strong,
 declarative statements, because otherwise I'll be here all night and
 this document will be four times longer and much less fun to read.
 Take it all with a grain of salt." - Me at

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

View raw message