Re: [Wrapper-user] One more patch...

[Leif M. <le...@ta...>]

Christian,
    This is a good idea, but I would like to avoid adding complexity to 
the command
line.  How would you feel about adding a section like the following to 
the primary
wrapper.conf:

wrapper.include.1=../conf/wrapperbar.conf
wrapper.include.2=../conf/wrapperfoo.conf

    The files mentioned in the include section would then be read in if 
they existed.
Any properties that had already been set would then be overridden.

    Properties specified on the command line would be set before include 
files.
This would make it possible to set an include file from the command line 
using
the standard mechanism for setting configuration properties.  You would not
be able to nest includes.

    Would something like this work for you?

    I decided to rename the 2.3.0 release to 3.0.0 because there are several
significant changes.  (Hopefully all compatible)

    The list of new features just keeps on growing for this release.  I 
have 2 or 3
other features that need to make it in as well, but all this has caused this
release to slip quite a ways already.   I will look at adding this, but 
it might end
up in a 3.0.1 release.

Cheers,
Leif

Christian Beedgen wrote:

>hi there -- lot's of cool stuff recently! I understand there is a
>release coming up soon, so here is something that I personally find very
>useful: cascading configurations. if there is interest, I would be
>delighted to see this included in the upcoming version.
>
>cascading configurations: very simple hack, basically it allows to
>specify additional configuration files that are loaded after the main
>configuration file. if an additional configuration file specifies a
>property that is already specified, the value is replaced with the value
>from the additional configuration file. if the property hasn't been
>specified, it is simply added.
>
>this is very useful if you have to query for certain parameters upon
>installation of an app (via an installer or wizard) -- instead of
>rewriting the config file, everything that has been queried from the
>user can simply be put in an additional configuration file. this also
>helps to a certain degree for upgrading, ie. a new base configuration
>file can be shipped, but changes that have already been made to an
>existing installation will remain in the additional configuration and
>don't get lost (as long as the format of the properties does not
>drastically change, that is, but still...). it's also useful if you have
>to deal with different JVMs (for example IBM on AIX, Sun on Linux),
>since for example -server as a JVM parameter makes the IBM JVM very
>unhappy from my experience.
>
>here is how this works in my implementation:
>
>./wrapper ../conf/wrapper.conf include.1=../user.conf.1
>include.2=../user.conf.2 
>
>and so on. the order that additional configuration properties are
>applied is (of course) include.1, include.2, ...
>
>attached are 4 files (wrapper.h, wrapper.c, wrapper_unix.c,
>wrapper_win.c) that are changed to implement the described
>functionality. the implementation is quick and dirty, but works for me.
>it was originally done against 2.2.9, but I just got the latest beta for
>2.3.0 (link was in Leif's mail from Mon, 20 Jan 2003 19:39:03 +0900) and
>moved the changes over there -- this is hopefully making it easier to
>diff against the current version of the code (plus my 2.2.9 was polluted
>by other stuff; also, I'm sorry for being too stupid and lazy to learn
>how to use diff and patch). since I can make very good use of this
>functionality, I would be happy to see this going into the codebase --
>this safes me from having to maintain a private fork ;) -- I am neither
>in love with my implementation nor with the names I chose for functions
>and parameters, so feel free to change all that to comply with your
>naming scheme and general ideas if you want.
>
>
>thanks,
>
>
>chr.
>  
>