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

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

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
---
This by itself will reduce the number of places that must be changed
down to one.

2) You can further clean things up as follows:
Change the above classpath entry to the following as a note:
---
# The following is defined from the command line:
#wrapper.java.classpath.2=%MYAPP_HOME%/lib/*.jar
---
Then modify the InstallApp-NT.bat and App.bat scripts as follows:
---
@echo off
rem
rem Find the application home.
rem
if "%OS%"=="Windows_NT" goto nt

echo This is not NT, so please edit this script and set _APP_HOME manually
set _APP_HOME=..

goto conf

:nt
rem %~dp0 is name of current script under NT
set _APP_HOME=%~dp0
rem : operator works similar to make : operator
set _APP_HOME=%_APP_HOME:\bin\=%


rem
rem Verify MYAPP_HOME
rem
:conf
set _WRAPPER_CONF="%_APP_HOME%\conf\wrapper.conf"

set _MYAPP_HOME="%~f1"
if not %_MYAPP_HOME%=="" goto startup

echo Usage:
echo App.bat {Application home}
goto end


rem
rem Run the application.
rem At runtime, the current directory will be that of Wrapper.exe
rem
:startup
"%_APP_HOME%\bin\Wrapper.exe" -c %_WRAPPER_CONF%
wrapper.java.classpath.2=%_MYAPP_HOME%/lib/*.jar
if not errorlevel 1 goto end
pause

:end
set _APP_HOME=
set _WRAPPER_CONF=
set _MYAPP_HOME=
---
You can no longer specify the conf file from the command line, but it
should work
for you.

Will this work? or do you still feel that the ability to set environment
variables
are needed? There have been a few people who requested the ability to set
environment variables in the past, but there have always been other ways to
do what they want.

I have avoided doing it up until now because of problems that arise with the
setting of properties from the command line. Let me know if the above solves
your problem, and either way, I will give this some more thought.

My current thinking is to do something like:
set_env.APP_HOME=/usr/lib/apphome
Where APP_HOME is created with the value of /usr/lib/apphome
This would then become an actual environment variable so a new syntax
for their expansion in other properties would not be needed.

The problem is how to handle this on the command line. Currently, properties
take the last value set. So the command line properties are set last. In the
case of the environment variables, they would need to be set first. My
first
thought was to make the property values sticky so that their first value
would
be maintained, then set the command line properties first. But the
problem with
that is that it would break things for existing users, especially those
using include
files to override defaults set elsewhere in the conf file.

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.

Cheers,
Leif

Mike Castle wrote:

>In article <3E6...@ta...>,
>Leif Mortenson  <wra...@li...> wrote:
>  
>
>>I am not sure I am grasping what it is you want to do. At what point do
>>you want the
>>replacements to happen? At run time? If so, what is the difference
>>between what you
>>are asking for and an environment variable?
>>    
>>
>
>At run time.
>
>Ok, lets say I am distributing a product that has a file that has
>something like this:
>
>wrapper.java.classpath.1=../lib/wrapper.jar
>wrapper.java.classpath.2=%MYAPP_LIB%/Utils.jar
>wrapper.java.classpath.3=%MYAPP_LIB%/Engine.jar
>...
>wrapper.java.classpath.25=%MYAPP_LIB%/Help.jar
>
>Now, let's say the user has 3 different installations in different
>directories doing different things.
>
>Well, I have to go into the conf files and search and replace MYAPP_LIB
>with MYAPP_LIB_1, and MYAPP_LIB_2.  I might as well not bother with
>environment variables then.
>
>But, instead, if I could do something like:
>
>MYAPP_LIB=C:\installation1\....\lib
>
>wrapper.java.classpath.1=../lib/wrapper.jar
>wrapper.java.classpath.2=${MYAPP_LIB}/Utils.jar
>wrapper.java.classpath.3=${MYAPP_LIB}/Engine.jar
>...
>wrapper.java.classpath.25=${MYAPP_LIB}/Help.jar
>
>Then I only have to modify one line in each file.  This is less prone to
>error, could even be constrained to a #include <location.conf> type of
>file, that would limit what a user has to modify down to one file that has
>just a couple of lines.
>
>In a unix implementation, I could just do something like have the init
>script set up different environment variables for each installtion (well, I
>think, I've not actually used wrapper there, yet).  But I don't have that
>option with NT services.  I'd like to keep the .conf files that I
>distribute as pristine as possible, only having to change a couple of lines
>(or, as I pointed out, an include file would be better).
>
>I'm certainly not set on the ant-like syntax, I just figured it was something
>common enough to be a good example.
>
>mrc
>  
>