On Mon, 2 Apr 2001, Milt Epstein wrote:

> On Mon, 2 Apr 2001, Scott Walter wrote:
> 
> > Hi,
> > 
> > I want to get your guys/girls input on the following:
> > 
> > I am building an app that will run under Tomcat and in
> > the future J2EE app servers.  Currently I am storing
> > parameters for connecting to a database (i.e. jdbc
> > url, driver, etc.) inside a .properties file.  
> > 
> > When the app is started for the first time I want the
> > user to enter values for db parameters and then to
> > write them to the property file.
> > 
> > Currently I am reading the properties file off the
> > classpath via getResource().  Is there anyway that I
> > can figure where exactly on the file system where the
> > properties file is located at so I can write to it in
> > the correct location???
> > 
> > I took a look at the Jive open source project and they
> > have the user put the location where the file exists
> > on the file system as an entry in the properties file,
> > I would like a more elegant solution.
> 
> FWIW, resources found via getResource() can be written to, when
> appropriate.  I have an article written by Jason Hunter (author of
> O'Reilly's Servlets book) from JavaWorld Dec. 1998 that covers the
> changes from servlet spec 2.0 to 2.1 (I don't have the exact URL, but
> you should be able to find it from that info), and it talks about this
> there (page 7, near the bottom, "Writing to an abstract resource").
> Take a look at that for details.
> 

Note that while it is *possible* the URL returned to you by
getResource() will be writeable, this is definitely not guaranteed.  For
example, if your container runs the webapp directly out of a WAR file, it
is highly unlikely that you will be able to do this.

There is no elegant portable solution to writeable resources within the
servlet API.  This was discussed by the expert group during the
development of the 2.3 spec, but unfortunately no consensus was
reached.  Using the absolute pathname of a disk file is probably the
closest thing to a portable solution.

Craig McClanahan


Reply via email to