[Geoserver-devel] GEOSERVER_HOME

GeoServer GeoServer Developer
1

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-beta2

dave

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

2

Ok, I'll defer to you. I would say the general way I like to work
things is be able to do the easiest thing possible (like if you have
Jetty and we can do things super easy with environmental variables),
but if that doesn't work, then have good fallbacks. Like we can have
one way that works with Jetty, that we try first, and if that doesn't
work, fall back on the totally independant war way.

From Jody's report on saving
(http://sourceforge.net/mailarchive/forum.php?thread_id=6854788&forum_id=7425):

'
They make use of two things:
- edit the confluence-init.properties file in /WEB-INF/classes to
indicate a writeable directory (writeable by the server)
- the ability to upload a zip file

..

Opps reading forward they say the confluence-init.properties file does
not work for a pure WAR installation.
Loks like they set up a bit of a search (lets recast this in terms of
GeoServer):
1. System properties (ie start the application with
-Dgeoserver.home=/path/to/your/geoserver/home
2. geoserver-init.properties (ie edit a file after the war has been
unziped by servlet)
3. Servlet context (customize the web.xml deployment descriptor to
include a <context-param> called geoserver.home

Apparently some application servers will let you play with System
properties, or context params
'

So yeah, with the binary installs I think we can even make use of
environmental variables and the scripts pass those in as the java
system properties. With the war install go to the generic ways you've
been finding (and this is just my suggestion, you're implementing, so I
do defer to you, if it's too much of a bitch)

Also uploading a zip file of the configuration could be cool - indeed
would make the 'deploy geoserver' button on udig a lot easier, no?

Chris

Quoting dblasby@anonymised.com:

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-beta2
>>
>>dave
>

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

3

dblasby@anonymised.com wrote:

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 env vairables are often managed by the container, many provide an API. This reperesents one option
that may be the easiest for your users depending on there container.

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 think you are talking about preferences? It was a problem in that the library was making an assumption about what it was allowed to do. Some
containers, or applets, cannot make use of the preferences facility.

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).

Um web.xml is *the* place where we are supposed to do this, once again many servlet containers all one
to edit the web.xml file. If your users is using one of those containers this will represent the easiest option
for them.

2. allow them to modify geoserver_home in the web interface (ie. type in
a new location)

I don't think there is a standard API allowing you to edit your web.xml file and get the container to rescan it.
This *is* something the application server is supposed to allow access to. The -D env thing is really just a hack,
that some servers make easier then the use of web.xml.

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).

Some application servers will not expand the war, that is your instructions on how to locate the web.xml file
and modifiy it will not work everywhere.

I really want to make sure that this works for everyone - not just jetty
or a hand-full of containers.

I once again recommend the origional list (from confluence) emailed a while back. I have a few books I can look in
as well if you would like.
Jody