[Geoserver-devel] Geoserver configuration woes

GeoServer GeoServer Developer
1

Hi,
am I the only one finding the current geoserver configuration
inconvenient to work with?
I speaking about mvn clean install destroying all the changes you made
in the
geoserver configuration during testing... now, I know that I can set a
data directory, but simply
uncompressing, say, citeWMS.zip somewhere and setting it as the data dir
won't work.

I also tried moving catalog and services into the data dir, without
success, and so on
with other permutations... apparently the pre-cooked data dirs around
can be used
only when installed in the web module, which is not practical in my opinion.

Also, catalog.xml and services.xml should be in the same dir as data, not
in WEB-INF...

Finally, apparently geoserver is unable to setup a data dir on its own
if you point
it to an empty directory... hmmm, what if I want to start up fresh and
clean?

Cheers
Andrea

2

A little :slight_smile:

can I add to this:

* have come up against very fatal error without much help when the DataDIr points to a non-existent directory
* found that feature types sometimes need to be under /data/featureTypes and sometimes under /featureTypes to be picked up by different parts of the system - suggest a quick audit of expectations here. I think the web config put them in a different place to the manual config.

these may have been fixed recently - I havent checked..

Rob A

aaime@anonymised.com wrote:

Hi,
am I the only one finding the current geoserver configuration
inconvenient to work with?
I speaking about mvn clean install destroying all the changes you made
in the
geoserver configuration during testing... now, I know that I can set a
data directory, but simply
uncompressing, say, citeWMS.zip somewhere and setting it as the data dir
won't work.

I also tried moving catalog and services into the data dir, without
success, and so on
with other permutations... apparently the pre-cooked data dirs around
can be used
only when installed in the web module, which is not practical in my opinion.

Also, catalog.xml and services.xml should be in the same dir as data, not
in WEB-INF...

Finally, apparently geoserver is unable to setup a data dir on its own
if you point
it to an empty directory... hmmm, what if I want to start up fresh and
clean?

Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

3

Hi Andrea,

aaime@anonymised.com wrote:

Hi,
am I the only one finding the current geoserver configuration
inconvenient to work with?

Nope, you are not the only one :). Others have expressed their distaste
for this setup as well.

I speaking about mvn clean install destroying all the changes you made
in the
geoserver configuration during testing... now, I know that I can set a
data directory, but simply
uncompressing, say, citeWMS.zip somewhere and setting it as the data dir
won't work.

Well you could always skip the clean part. I dont understand why the
later wont work?

I also tried moving catalog and services into the data dir, without
success, and so on
with other permutations... apparently the pre-cooked data dirs around
can be used
only when installed in the web module, which is not practical in my opinion.

Not sure exactly what you mean here. Can you explain how else you want
to deploy them.

Also, catalog.xml and services.xml should be in the same dir as data, not
in WEB-INF...

Yes, the pre cooked examples follow the old style data directory in
which the services.xml and catalog.xml are under WEB-INF. My rational
was that it was easier to release both the war and the binary install
with the same setup, but the new style is also supported.

Finally, apparently geoserver is unable to setup a data dir on its own
if you point
it to an empty directory... hmmm, what if I want to start up fresh and
clean?

I agree here.

So the reason I came up with these zip files was that I didn't like
seeing a ton of configuration and binary data under the source tree.
When I was in south africa i literally could not check out geoserver.
However it seems to generally not be a fan favorite.

So I would be ok to change back to the old system, but can we please
store the configuration directory somewhere outside of the source tree,
perhaps a minimal one inside of svn like is done with the zip file stuff.

-Justin

Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,45223a85135047731818748!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

4

I also tried moving catalog and services into the data dir, without
success, and so on
with other permutations... apparently the pre-cooked data dirs around
can be used
only when installed in the web module, which is not practical in my opinion.

Not sure exactly what you mean here. Can you explain how else you want
to deploy them.

Also, catalog.xml and services.xml should be in the same dir as data, not
in WEB-INF...

Yes, the pre cooked examples follow the old style data directory in
which the services.xml and catalog.xml are under WEB-INF. My rational
was that it was easier to release both the war and the binary install
with the same setup, but the new style is also supported.

I'd like to completely move away from putting services.xml and catalog.xml separate from the data_dir. I think the approach we should take for the war download is to put the _whole_ data_dir in the war. The default should point at WEB-INF/data_dir. Then we wouldn't need the work arounds for just those in the web-inf.

Finally, apparently geoserver is unable to setup a data dir on its own
if you point
it to an empty directory... hmmm, what if I want to start up fresh and
clean?

I agree here.

I agree that we should be able to do that. The problem is that there's not a way to just instantiate the blank configuration objects, GeoServer has to read them in. I imagine this wouldn't be too hard to do, and is probably worth the investment. This would also alleviate RobA's problem of super nasty error reports. Instead users would just get a non-configured geoserver.

Ideally one could look up what the data_dir is from the web admin tool, and also be able to upload a new data_dir or point at a different location from the web admin.

So the reason I came up with these zip files was that I didn't like
seeing a ton of configuration and binary data under the source tree.
When I was in south africa i literally could not check out geoserver.
However it seems to generally not be a fan favorite.

So I would be ok to change back to the old system, but can we please
store the configuration directory somewhere outside of the source tree,
perhaps a minimal one inside of svn like is done with the zip file stuff.

I agree with this. The directories in geoserver are incredibly bloated. There should be just the basic one, and a 'minimal' one for (which we could get rid of if we had the ability to load geoserver without a data_dir - it's there just to make sure we can start up).

We should have a repository of data_dirs, and even have separate downloads to get at them.

Chris

-Justin

Cheers
Andrea

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

5

Justin Deoliveira ha scritto:

I speaking about mvn clean install destroying all the changes you made

in the
geoserver configuration during testing... now, I know that I can set a
data directory, but simply
uncompressing, say, citeWMS.zip somewhere and setting it as the data dir
won't work.
    

Well you could always skip the clean part.

Before committing I usually do a mvn clean install from the root folder in order
to try and make sure I don't break the build (that may happen anyways, I just try as hard as I
can to avoid this).

I dont understand why the later wont work?
  

Well, if you uncompress zips as the are, catalog.xml and services.xml are under a WEB-INF folder.
So you have

root
-- WEB-INF
    -- services.xml
    -- catalog.xml
-- data
  -- ...

if you say root is the data directory it won't work because the lookup for services and catalog is
not recursive, if you say WEB-INF it's the data directory data won't be found, if you move
services.xml and catalog.xml on the root feature types won't be found and so on...
Is there a working way to have the stuff out of the sources? Just asking.

Not sure exactly what you mean here. Can you explain how else you want
to deploy them.
  

I want to setup a separate data directory, refer to id with the env variable, and thus avoid the
build to wipe it out.

So I would be ok to change back to the old system, but can we please
store the configuration directory somewhere outside of the source tree,
perhaps a minimal one inside of svn like is done with the zip file stuff.
  

That would be ok for me.
Cheers
Andrea

6

Chris Holmes ha scritto:

Yes, the pre cooked examples follow the old style data directory in
which the services.xml and catalog.xml are under WEB-INF. My rational
was that it was easier to release both the war and the binary install
with the same setup, but the new style is also supported.

I'd like to completely move away from putting services.xml and catalog.xml separate from the data_dir. I think the approach we should take for the war download is to put the _whole_ data_dir in the war. The default should point at WEB-INF/data_dir. Then we wouldn't need the work arounds for just those in the web-inf.

I like the idea of having a single folder to move around. Having the default in WEB-INF/data_dir makes it unaccessible
from the web, which is a good idea, but also creates problems for servers that do not unpack the war.
So, having a separate setting is indeed a good idea too. There is a catch thought... were do we keep that one? :slight_smile:
An env variable seems to be the only location (that is, we cannot store the location in the data dir itself, and the
web application war may not be writable).

Finally, apparently geoserver is unable to setup a data dir on its own
if you point
it to an empty directory... hmmm, what if I want to start up fresh and
clean?

I agree here.

I agree that we should be able to do that. The problem is that there's not a way to just instantiate the blank configuration objects, GeoServer has to read them in. I imagine this wouldn't be too hard to do, and is probably worth the investment. This would also alleviate RobA's problem of super nasty error reports. Instead users would just get a non-configured geoserver.

Well, I guess we can store a minimal config zip inside the war, and unpack it in the folder chosen by the user
if no configuration is found...

Ideally one could look up what the data_dir is from the web admin tool, and also be able to upload a new data_dir or point at a different location from the web admin.

It would be nice, yes, just have no idea how difficult that would be...

So the reason I came up with these zip files was that I didn't like
seeing a ton of configuration and binary data under the source tree.
When I was in south africa i literally could not check out geoserver.
However it seems to generally not be a fan favorite.

So I would be ok to change back to the old system, but can we please
store the configuration directory somewhere outside of the source tree,
perhaps a minimal one inside of svn like is done with the zip file stuff.

I agree with this. The directories in geoserver are incredibly bloated. There should be just the basic one, and a 'minimal' one for (which we could get rid of if we had the ability to load geoserver without a data_dir - it's there just to make sure we can start up).

We should have a repository of data_dirs, and even have separate downloads to get at them.

Indeed, with a wiki page referring to them.
Ok, to sum up these seem to be four separate jira issues:
- store all configuration inside a single folder
- allow the user to start a new configuration on an empty folder
- allow interactive data folder change (hmm... unfortunately this cannot be persisted)
- provide a list of pre-cooked configuration files.

Two more things:
* this is not much work, but it's not 5 minutes either, and a new configuration system
   will render all this work useless;
* do we have a schedule for those?

Cheers
Andrea

7

aaime@anonymised.com wrote:

Chris Holmes ha scritto:

Yes, the pre cooked examples follow the old style data directory in
which the services.xml and catalog.xml are under WEB-INF. My rational
was that it was easier to release both the war and the binary install
with the same setup, but the new style is also supported.

I'd like to completely move away from putting services.xml and catalog.xml separate from the data_dir. I think the approach we should take for the war download is to put the _whole_ data_dir in the war. The default should point at WEB-INF/data_dir. Then we wouldn't need the work arounds for just those in the web-inf.

I like the idea of having a single folder to move around. Having the default in WEB-INF/data_dir makes it unaccessible
from the web, which is a good idea, but also creates problems for servers that do not unpack the war.
So, having a separate setting is indeed a good idea too. There is a catch thought... were do we keep that one? :slight_smile:
An env variable seems to be the only location (that is, we cannot store the location in the data dir itself, and the
web application war may not be writable).

Oh, we already have that. You can pass the argument in to the java process. So for Jetty binary distributions we already pass the environment variable in to java. From tomcat and the like you can pass it in to your java process or set it in web.xml.

I'm only talking about the location in the war for the last default. See more at: http://docs.codehaus.org/display/GEOSDOC/GeoServer+Data+Directory

Finally, apparently geoserver is unable to setup a data dir on its own
if you point
it to an empty directory... hmmm, what if I want to start up fresh and
clean?

I agree here.

I agree that we should be able to do that. The problem is that there's not a way to just instantiate the blank configuration objects, GeoServer has to read them in. I imagine this wouldn't be too hard to do, and is probably worth the investment. This would also alleviate RobA's problem of super nasty error reports. Instead users would just get a non-configured geoserver.

Well, I guess we can store a minimal config zip inside the war, and unpack it in the folder chosen by the user
if no configuration is found...

Ideally one could look up what the data_dir is from the web admin tool, and also be able to upload a new data_dir or point at a different location from the web admin.

It would be nice, yes, just have no idea how difficult that would be...

I'll think about it, I don't _think_ it should be all that hard.

So the reason I came up with these zip files was that I didn't like
seeing a ton of configuration and binary data under the source tree.
When I was in south africa i literally could not check out geoserver.
However it seems to generally not be a fan favorite.

So I would be ok to change back to the old system, but can we please
store the configuration directory somewhere outside of the source tree,
perhaps a minimal one inside of svn like is done with the zip file stuff.

I agree with this. The directories in geoserver are incredibly bloated. There should be just the basic one, and a 'minimal' one for (which we could get rid of if we had the ability to load geoserver without a data_dir - it's there just to make sure we can start up).

We should have a repository of data_dirs, and even have separate downloads to get at them.

Indeed, with a wiki page referring to them.
Ok, to sum up these seem to be four separate jira issues:
- store all configuration inside a single folder

This is done. The only issue is not using the last backup any more. The default way is to put it all in the same directory. I just left the old way of putting the two xml files in the web-inf for transitioning (though Justin made it the default in 1.4.x, so it's crept back - I never communicated my vision that well).

- allow the user to start a new configuration on an empty folder

Yes.

- allow interactive data folder change (hmm... unfortunately this cannot be persisted)

Yes.

- provide a list of pre-cooked configuration files.

Yes.

Two more things:
* this is not much work, but it's not 5 minutes either, and a new configuration system
  will render all this work useless;
* do we have a schedule for those?

Those are a ways away, currently. But I'd say get the defaults right for now. That's all we need for 1.4.0. (may consider starting up with empty folder) We can revisit when we have that out.

Chris

Cheers
Andrea

!DSPAM:1003,452285e1187801336712104!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org