(I'm resending this because my email looks like it might have issues -
sorry if you get this twice)
Chris,
Using an environment variable (or a "java -D....") is certainly
possible, but I think it could be a pain to actually administer - since
the user might not have access to the actual servlet runtime
environment. Also, I dont think you cannot persist changes from inside
geoserver.
The java properties is another option - there was a discussion on the
geotools list (wrt to the crs stuff) about all the problems it was
causing. I'm not sure if this was a generic problem or just something
miss-configured for that particular instance.
I went looking for how to do this - most people just say stick this in a
configuration file or talk to a configuration server somewhere. The
whole idea of a WAR is that its independent!
One possibility is to:
1. put geoserver_home in a .properties or .xml (or even web.xml). Users
can modify this when they build the .war. We can even have a little
java program that will update a .war file with a new geoserver home
(for people who dont want to build it with ant).
2. allow them to modify geoserver_home in the web interface (ie. type in
a new location)
3. we can try to update the place we store geoserver_home. If we can,
great! otherwise we tell the user that their modification will be
"overwritten" next time they start the server and we tell them how to
make in permanent (ie. update the war).
I really want to make sure that this works for everyone - not just jetty
or a hand-full of containers.
dave
Chris Holmes wrote:
Hey;, I'll dig into this more, but do check how confluence does it.
Jody
wrote an email, called soemthing like thoughts about saving. You also
could just download confluence and look at it.Also with the jetty stuff it's pretty easy to pass in arguments - you
can
read enviromental variables and set them as java properties. Also,
couldn't you pass in properties directly in some way, instead of having
to
set the .properties file in the jar? Java does allow that in some way,
though it might be tricky through servlet containers. Ok, I'll look
into
this and try to figure out a plan, but the way I was envisioning it was
a
GEOSERVER_HOME environmental variable. Perhaps it will only be able to
work with our binary installs, but even then I think it'd be worthwhile
to
have - it's how people are used to setting home directories, no?
On Thu, 31 Mar 2005 dblasby@anonymised.com wrote:
I'm just looking into the "GEOSERVER_HOME" issue.
Currently, all the geoserver configuration is read from a set of
directories inside your .WAR file. (the entire data/ directory and the
WEB-INF/catalog.xml file)This has two main issues:
1. Some servlet contains do not allow you to modify the contents of
the
.WAR. This means you can never save your configuration.
2. If you have multiple configuration, its difficult to choose which
one
you want to deploy, and difficult to "backup" any configuration.
I'm proposing a simple way of dealing with this - allow setting a
"GEOSERVER_HOME" that would allow reading & writing to a directory
that
is NOT in the WAR.
Basically, the directory would look like this:
my_geoserver_config/catalog.xml -- datastore definitions
my_geoserver_config/data/ -- directory of featuretypes, styles,
etc... (same as the current server/geoserver/data directory).Once the GEOSERVER_HOME directory is known, geoserver can just read &
persist its configuration into that directory.Unfortunately, its difficult to specify the GEOSERVER_HOME directory!
I'm, therefore, suggesting two ways to specify it:
1. setup a .properties file in the geoserver.jar file. This would
contain the location of the GEOSERVER_HOME directory. If you want to
use another directory, just modify the the .properties and rebuild the
WAR. This is a bit of a pain since you have to re-build the WAR if
you
want to change your geoserver_home directory, but it is better than
whats currently there.
2. update the web gui so that it allows someone to "type in" a new
GEOSERVER_HOME. This is nice, but it means you'll have to do this
*every* time you restart geoserver!It would be nice if these two methods would just allow you to update
the
GEOSERVER_HOME in the .properties file, but (as already mentioned)
some
servlet containers will not allow you modify any of the files in the
WAR!!The default should be the same as whats currently happening - it
should
use the data directory inside the WAR. If the user wants to update
it,
then they'll have to either update the .properties file or type in a
new directory.What do you think?
dave
ps. this will be done in the 1.3.0RC1 - there isnt enough time for the
1.3.0-beta2dave
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
----- End forwarded message -----
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/