Re: [Wrapper-user] Cascading Configuration Files

[Christian B. <kr...@di...>]

Leif:

thanks a bunch for reacting so quickly and favorably to this feature
request. 

I see one pro, one con here:

Pro: the nesting might be cool -- for my actual use case it's actually
not really that important.

Con: the missing ability to specify the includes on the command line
(well, I will need to look at the 3.0 beta sources to see if this is
actually true) -- if I can't specify the includes on the command line,
my use case falls apart, pretty much. here is the problem that I am
trying to solve: On AIX, I use the IBM VM, on all other platforms the
Sun VM. The Sun VM wants its -server switch (plus additional tuning for
the GC) -- however, these switches make the IBM VM barf (it doesn't just
ignore them, unfortunately). so here is what I'm doing: I have a base
config, and a platform specific config. the platform specifc config
provides the values for wrapper.java.additional.x (.1=-server for Sun,
.1=-Dsomething=else for IBM). in my launch.sh script, I simple decide
based on `uname`, then invoke either 

"wrapper wrapper.config include.1=wrapper.config.sun
include.2=wrapper.config.user" 

or 

"wrapper wrapper.config include.1=wrapper.config.aix
include.2=wrapper.config.user"

and so on (I hope having two includes doesn't qualify for being shot in
backyard ;)))

now without being able to specify the includes on the commandline, I am
pretty much dead in the water here. my first use case (having to include
install/user specific stuff) will still work based on your propasal, but
the second one (platform specific includes) could only be achieved by
playing tricks with filenames -- which I'd rather not do.

thanks,


chr.



> Message: 2
> Date: Sun, 09 Feb 2003 00:59:46 +0900
> From: Leif Mortenson <le...@ta...>
> To:  wra...@li...
> Subject: Re: [Wrapper-user] Cascading Configuration Files
> Reply-To: wra...@li...
> 
> Christian,
>     I changed my mind a little bit about how to implement the 
> cascading 
> configuration files.
> It is all implemented and in CVS, so this will be in the next release.
> 
>     Rather than using property names for include files, I 
> decided to do 
> it on a lower level.
> The property code now has the ability to recognize "#include <file>" 
> lines in the config
> file.  These include files will be processed at the point they are 
> included in the file so
> their contents will override values set earlier and be overridden by 
> values set later.
> By doing it this way, it is possible to nest include files as 
> well.  The 
> nesting level is limited
> to 10 deep as an easy way to avoid include loops.  If anyone 
> thinks they 
> need more
> than 10 levels, they should probably be taken out back and shot for 
> their own good.
> 
>     The files specified are optional, so there will be no 
> errors thrown 
> if an include file can
> not be found or accessed.
> 
>     Here is an example:
> 
> wrapper.conf:
> ---
> #include ../conf/inc1.conf
> wrapper.java.command=java
> wrapper.java.initmemory=16
> wrapper.java.maxmemory=64
> #include ../conf/inc2.conf
> ---
> 
> inc1.conf
> ---
> wrapper.java.initmemory=32
> ---
> 
> inc2.conf
> ---
> wrapper.java.maxmemory=128
> ---
> 
> This will result in the following values being used by the wrapper.
> ---
> wrapper.java.command=java
> wrapper.java.initmemory=16
> wrapper.java.maxmemory=128
> ---
> 
> Let me know how this will work for you or if you have any questions.
> 
> Cheers,
> Leif
> 
> > Christian Beedgen wrote:
> >
> >> 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, ...
> >