Re: [Wrapper-user] conf question: referencing defined properties

[<da...@ix...>]

In article <3E6...@ta...>,
Leif Mortenson  <wra...@li...> wrote:
>Mike,
>I think you can solve your current problem by doing the following:
>
>1) As I said in my previous post. Define all of the elements of your
>classpath into a
>single property like this:
>---
>wrapper.java.classpath.2=C:/installation1/lib/*.jar

1) Not all .jar files are in the same directory.
2) Not every .jar file in a directory should be in the startup classpath.

I'm a firm believer in explicitly enumerating everything.

>:startup
>"%_APP_HOME%\bin\Wrapper.exe" -c %_WRAPPER_CONF%
>wrapper.java.classpath.2=%_MYAPP_HOME%/lib/*.jar

Took me a while to figure out that had gotten word wrapped.  :-/

>The only way to make this work is to pass through the command line
>properties twice. Once before the conf file is loaded and once after.
>The environment variables would be handled on the first pass and all
>others would be handled on the second. Not very pretty, but unless
>I can think of another way to do this without breaking the conf files
>of existing users, it is the way it would have to be done.

Priority queues/heaps/heirarchial properties.

Have two classes of properties:  those set by CLI, those set by FILE.
Within a class, the last value always takes precedence.  However, when
reading a value, check CLI first, and if none exists, use FILE.

Actually, you could do three classes: ENV, CLI, FILE.

First, load all envvar into class ENV.  Then load all command line
parameters into class CLI.  Load properties from .conf into FILE as they
are encountered.

Whenever you use a property, first check class CLI, then FILE, then ENV.
And have the %foo% syntax reference a property instead of only an
environment variable.  Well, ok always CLI first, but I could see arguments
for going either way on FILE vs ENV next.

Hmmm.   Looking at the code, this shouldn't be too hard (I've done this
type of thing before :-).  Looks like the only things that would need to be
changed would be getInnerProperty(), evaluateEnvironmentVariables(),
setInnerProperty(), addProperty(), addPropertyPair().  Then add a bit of
code to walk the envvar list and add those, move the command line loading
further up in the program, and done.  Well, modulo any bugs of course.

Ack!  Why are you casting malloc?  You're not using a C++ compiler are you?
For shame!

Hmmm.  One could even somewhat easily add in support for exporting
environment variables.  Something like wrapper.env.export.N=envvarname

So one could do something like:

app_home=something_of_interest

wrapper.java.classpath.X=%app_home%/lib/foo.jar

wrapper.env.export.Y=app_home

That support could pretty easily be added to
wrapperBuildJavaCommandArrayInner(), though making it it's own function
would be nicer (no since making a really long function longer).

Hmmm... it doesn't look like all properties are automatically passed to the
java process.  Is that correct?  (Again, I'm thinking about ant where that
is an option, and making sure I'm not getting confused about my
applications).

If you like this approach I can probably whip up a patch later today.

mrc
-- 
     Mike Castle      da...@ix...      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc