Re: [Wrapper-user] Dynamically passing arguments in wrapper.conf

[Silent K. <the...@gm...>]

Leif,

Thanks for pointing me to the environmental variable feature in the 
wrapper. I will try to work my
way around using that.

As for your comments about not having relative paths in an application, 
I completely agree with you. In
fact, I have taken a lot of caution in making sure that everything is 
relative. Application installation should
be free flow and should be flexible enough to run from anyway. Eclipse 
is one great example for that.

Coming to my issue, the only pain point I have is RMI. While specifying 
RMI codebase, as far as I have
tried, it does not accept relative paths in the codebase. It requires 
full paths. Because of this reason, I am
forced to use hard coded paths in the wrapper configuration file. All 
other arguments to my application
are relative from where the application has been installed. If you have 
any experience in RMI and know
about the codebase issues, please let me know.

>> Implementing UNIX like inline execution of external commands seems 
>> like it would get complicated quickly, so unless something like that is really 
>> really needed I would like to avoid it.


I think the idea of having inline execution of commands in the 
configuration file might be an overkill. I was
a bit greedy and wanted more for myself. I think it makes more sense in 
the configuration file being just that
- a configuration file.

Thanks,
SK


Leif Mortenson wrote:

>SK,
>    The Wrapper already supports expansion of environment variables 
>within the
>configuration file.  It uses the Windows syntax on all platforms to make the
>configuration file as portable as possible.
>    For example:
>wrapper.java.command=%JAVA_HOME%/bin/java
>
>    See the following docs for more details:
>http://wrapper.tanukisoftware.org/doc/english/props-envvars.html
>
>    Implementing UNIX like inline execution of external commands seems 
>like it
>would get complicated quickly, so unless something like that is really 
>really needed
>I would like to avoid it.
>
>    As for your install, I would suggest that you consider modifying 
>your application
>to work off of relative rather than absolute directory paths.   That is 
>what I always
>do.
>    When running Java standalone, the current directory depends on how 
>the JVM
>was launched so relative paths can be a nightmare.   But when using the 
>Wrapper,
>the user directory is always set to the location of the Wrapper.exe 
>file.   If you make
>all of your paths relative to that location then your application will 
>work reliable no
>matter how it is launched.
>    This also greatly simplifies your install as it can basically just 
>be a expanded zip
>file.  The user can also move the application around without breaking it 
>as long as it
>is stopped when moved.
>
>    Cheers,
>    Leif
>
>Silent Killer wrote:
>
>  
>
>>Hi all,
>>
>>I am a happy user of Java Service Wrapper, using it in several 
>>components. But I have a few queries regarding the use of the 
>>configuration file.
>>
>>Is it possible to use environmental variables in the config file 
>>(wrapper.conf)? For example, one of the command line arguments that I 
>>am using is now of the form,
>>
>>wrapper.java.additional.1=-Dbase=C:\installroot
>>
>>But installroot is something that is decided by the user while 
>>installing the product. In such a case, is it possible to dynamically 
>>change the value of my argument in the configuration file? I can see 
>>two possible ways of doing it.
>>
>>Option1: Set an environmental variable during installation. Something 
>>like MyProductInstallHome which points to C:\installroot. And I should 
>>be able to set the property in the configuration file as
>>
>>wrapper.java.additional.2=-Dbase=%MyProductInstallHome%
>>
>>Option2: Allow batch commands in the configuration file. So that I can 
>>do something like
>>
>>wrapper.java.additional.2=-Dbase=%cd%\..
>>
>>(what I mean here is that %cd% should give me the current directory, 
>>which in my case is C:\installroot\config and \.. will take me one 
>>level up so that I can get to the correct install root.
>>
>>I hope I have been clear in my request so far.
>>
>>Out of the two options I have stated above, is any of them possible? 
>>If at all possible, I would prefer the second option so that I do not 
>>have to rely on environmental variables.
>>
>>Or I am completely off track here? Is there some other way to handle 
>>dynamic arguments?
>>
>>Any pointers on this would be greatly appreciated.
>>
>>Thanks,
>>SK
>>    
>>