Re: Servlet WAR file and path names

[Jason Hunter <jh...@acm.org>]

(Moved to tomcat-dev from tomcat-user)

Craig R. McClanahan wrote:
> 
> although there's no restriction on a particular URL returned by
> getResource() supporting write access (that's what an HTTP PUT
> normally does, after all).

But as I said, the file URLs used by Tomcat (and standard in the JDK)
don't support write.  So it's not a general solution for local files.

> For short term temporary use, a servlet container is required to

But not all files are temporary.  Some should withstand a server
restart.

> For long term storage, the current recommendation is to use
> databases, directory servers, EJBs, or some other resource that is
> accessible from a servlet based application.  It's not obvious that
> the servlet API itself needs to provide this facility, given the 
> other options available.

So if an author were to, say, write a Counter servlet in Chapter 3 that
persisted its count using init/destroy as a way to demonstrate the
servlet lifecycle, that author would need to write code accessing a
database?  Seems like overkill.

It's not just a "textbook" issue.  Lots of sites don't use databases. 
See this month's JavaWorld for an article by Alex Chaffee proposing
people use XML files instead for small to medium data storage needs to
avoid the overhead and complexity inherent in using an RDBMS.  It'd be
nice if we had a story to support that.  

Originally the URL mechanism was going to allow writes.  That helped
convince us on the expert group it was the right design.  But Tomcat
isn't implementing write capability for files.  I'm wondering, should
we?  Should we try to use the URL mechanism for writing?  How would we
deal with synchronization?  Is there something better API 2.3 could
provide?

-jh-