Re: [Wrapper-user] Cascading Configuration Files

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

Christian,

>Pro: the nesting might be cool -- for my actual use case it's actually
>not really that important.
>
I actually did not have any use case for this, but it came for free with 
the way I had
implemented it.

>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 ;)))
>
Maybe just with a BBgun :-)
No what you want to do is fair.  I want to get this implemented in a way 
that will be
useful for users.

There are two possible solutions for this:
1) Means no code changes.   You would simply create 3 config files.
wrapper.sun.conf, wrapper.aix.conf, and wrapper.conf
In addition to the platform specific settings, the sun and aix conf 
files would
do nothing other than include the wrapper.conf file.   You would then modify
the commands used to launch the wrapper as follows:
Sun:
  wrapper wrapper.sun.conf
Aix:
  wrapper wrapper.aix.conf
Other:
  wrapper wrapper.conf
I think this is the cleanest solution and you should be able to do 
everything
you want?

2) In addition to leaving things as is, I could add the ability to 
specify include
files on the command line using an include=<file> format.  The include files
would always be loaded as if the had been included at the very end of the
main config file.   Everything in option 1) would still work.

Please let me know your thoughts on each of the above.

As a site note, I also realized this morning that environment variable
expansion in include statements are not currently implemented.  I'll
take care of that before a release.

>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.
>
Dead in the water is no good, we'll get a solution that will keep you 
working.

Cheers,
Leif