On 6/4/07, Aron Sogor <aron@theatlantis.net> wrote:
For embedding DS it would not be cool to use system properties, or at
least you should be able to define/overwrite _all_ those variables in
the server.xml too, and system properties would only be a fall back.

I believe this is covered, since if the properties are not specified the code falls back to the current behavior, but at least you will have the option to locate the data elsewhere as well.



Alex Karasulu wrote:
> Hi Chris,
> On 6/3/07, *Chris Custine* <chris.custine@gmail.com
> <mailto: chris.custine@gmail.com>> wrote:
>     Hi Everyone,
>     As most of you know, part of the installers and daemon rework I am
>     doing involves detaching the data storage directory from the main
>     install image so that the data can be stored seperately to ease
>     upgrading and running multiple server instances.  Currently all of
>     the data dir, log dir, etc. are statically configured to be
>     relative to the base install dir.  To make this more dynamic and
>     configurable I propose to add some java system properties that can
>     be passed to each instance and use sensible defaults if none are
>     set.  Current server.xml files will continue to work because the
>     partition dir will still be relative from the base data dir that
>     is specified.
> That worked out well :).
>     For Linux/Unix, I believe the correct default will be
>     /var/lib/apacheds, but I am not so sure about WIndows.  At this
>     point I am thinking about keeping the data in the base install dir
>     as a default for WIndows.
> I agree and it makes sense for Windows since usually apps just deposit
> all their stuff in their
> installation folders in "Program Files".  There is no standard around
> this like there is in Linux
> which goes to show you just how little thought the Windows people give
> to multiuser systems
> and server applications.
>     I will start documenting all of this better in the next few days
>     but I wanted to see if anyone has any thoughts on this part before
>     I continue.
> Thanks,
> Alex