Justin,

> USB stick with enough space on it this is not an issue, but after a recent
> bad experience with USB sticks in labs, not having a CD to fall back on
> is suicide in my opinion :).

What was the problem with USB sticks?

-S.


2008/8/22 Justin Deoliveira <[EMAIL PROTECTED]>

> Hi all,
>
> This is something that has been floating around in my head for quite
> some time and I wanted to throw some ideas out and see what people think
> of them.
>
> So the use case here is be able to run GeoServer "live", that is
> straight off a CD or a USB stick. The problem is however that, as many
> know, GeoServer needs write access to be able to run. Now with a USB
> stick with enough space on it this is not an issue, but after a recent
> bad experience with USB sticks in labs, not having a CD to fall back on
> is suicide in my opinion :).
>
> To find the instances I started GeoServer with an unwritable data
> directory and it blew up with issues related to logging, writable file
> checks, data like shapefiles locking and writing out index files, and more.
>
> Past startup there is also the obvious fact that without a writable data
> directory there would be no ability to save any changes made via the web
> ui. Not ideal in a workshop situation.
>
> So... my thought about the easiest way to get around this situation
> would be to somehow tell GeoServer to use the temporary O/S space, or
> use the users home directory for the data dir.
>
> My first thought on how to do this is to use "special" values for the
> GEOSERVER_DATA_DIR parameter. Something like:
>
> -DGEOSERVER_DATA_DIR=[TMP] or -DGEOSERVER_DATA_DIR=[HOME]
>
> Then the GeoServerDataDirectory.init() method would recognize these
> values and set the data directory path accordingly.
>
> So continuing on with this, what about content inside the data
> directory? If you start geoserver with an "empty" data directory it
> still chokes. So my thought was to have GeoServerDataDirectory.init()
> not only set the path based on the special values, but also initialize
> the directory structure (only on the first run of course).
>
> It seems logical to me to just use the minimal data directory in this
> case, which is just a skeleton catalog.xml and services.xml, and 4 sld
> files. However... in a workshop situation this is also not ideal, since
> we are going to want people to have a data directory which has been
> pre-configured.
>
> So my thought to get around this would be to support an additional
> startup parameter, called something like "GEOSERVER_DATA_DIR_TEMPLATE".
> The value of the parameter is a path to a data directory... however
> instead of using that path directly, the behavior is instead to copy the
> contents of it to temporary O/S space / home directory. So startup would
> look something like:
>
> -DGEOSERVER_DATA_DIR=[TMP]
> -DGEOSERVER_DATA_DIR_TEMPLATE=E:\GeoServer\data_dir
>
> End of rant. Feedback welcome :).
>
> -JD
>
> --
> Justin Deoliveira
> Software Engineer, OpenGeo
> http://opengeo.org
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to