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
>available.
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
intention.
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
____________________________________
Justin Ruthenbeck
Software Engineer, NextEngine Inc.
justinr@nextengine.com
Confidential -
See http://www.nextengine.com/confidentiality.php
____________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
|