Menu
▾
▴
wrapper-user
|
From: Silent K. <the...@gm...> - 2005-10-12 21:45:53
|
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 |
|
From: Leif M. <le...@ta...> - 2005-10-13 02:49:15
|
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
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
|
|
From: Silent K. <the...@gm...> - 2005-10-13 05:06:34
|
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 >> >> |
|
From: Leif M. <le...@ta...> - 2005-10-13 06:19:14
|
SK, Silent Killer wrote: > 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. Not sure here. What is an example. I have written application making use of RMI but am not sure what you are referring to. My apps were all relative. A big must for apps that need to run on various platforms. Cheers, Leif |
