wrapper-user

[Wrapper-user] Wrapper's current working directory

[Anthony F. <ant...@co...>]

First off, I must say this is one of the nicest Java service wrappers I have 
yet to use. It's flexibility and ease-of-use are unmatched! Kudos and thanks 
to Leif and the Wrapper team for making it available.

I think I may be missing something with configuration that I'm hoping someone 
has some suggestions for.

My standard practice has always been to write config files for my Java 
applications such that paths are relative to the "home" directory of the 
application. I also like to put executables (including Wrapper) in a "bin" 
directory. I know Wrapper is designed to always use the executable directory 
as the working directory and that relative paths can be used in wrapper.conf 
which is great because I can count on it.

My problem is that all of my non-wrapper.conf config files also need to be 
"aware" of the location of the executable and specify relative paths with a 
'../' prefix. The solution I've come up with is to add a "app.home" system 
property that gets used as the base to all relative paths throughout my 
application. This is a little cumbersome though since this needs to be done 
everywhere throughout the application. Is it possible to set the Java 
process's notion of the current working directory to this "home" directory or 
am I missing something else entirely?

Thanks for the help,
-Tony

Re: [Wrapper-user] Wrapper's current working directory

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

Anthony,

Early versions of the Wrapper did not used to set the current directory.
But the problem was that this made it very difficult to use relative paths
when working with the Wrapper.

Here is the problem:
If you first cd into a C:\myapp\bin directory and then run the Wrapper
then your current directory will be C:\myapp\bin and a reference to the
wrapper configuration file of ..\conf\wrapper.conf will work correctly.

But if your current directory is C:\myapp, and you launch the Wrapper
using a reference like bin\Myapp.bat then the above reference to the
conf file will fail as the ..\conf\wrapper.conf reference would resolve to
C:\conf\wrapper.conf, which is not correct.

To make things worse, when you install the wrapper as an NT service,
the current working directory will be C:\Windows\service32.

For this reason, you pretty much had to use absolute paths with earlier
versions of the Wrapper.  This unfortunately made it more difficult to
install software that used the Wrapper as the installer would have to go
through and set all of the absolute paths in the application at install 
time.

This is a common problem to all Windows, UNIX and other applications
and it would have been Ok, to force users to follow that standard.

But I found it annoying and wanted to fix it.  The easiest install 
program in
my book is one where you just unzip an archive file unto the directory of
your choice and have everything work!   Many applications, work this way
no problem but you have to run the application from a specific location
otherwise the relative paths all fail to resolve.

Originally, I wanted to have a configurable working directory in the
wrapper.conf file.  But there was a chicken and the egg problem.  You
need to be able to locate the wrapper.conf file before it can be loaded.
And to do that, you have to have a fixed starting point.   So I decided to
just have the Wrapper binary always force its working directory to be the
same as its location.

One option that I considered was to have the Wrapper behave as it does
now with respect to locating the wrapper.conf file, but then once it was
loaded change over to using a working directory configured in the conf file.
Bu that seemed like it would just get confusing for users without actually
giving any new functionality.   The problem there is that you can define
properties from the command line as well.  And paths in those properties
would be using a different base location than that used to locate the
wrapper.conf file.  For example:
Wrapper.exe -c ../conf/wrapper.conf 
wrapper.java.additional.1=-Dconf.file=conf/wrapper.conf
In the end I decided that this is one area where it would be best to limit
flexibility and just stick to forcing the location of the working directory.

For any decision I could have made, there would always be someone
who wanted to do something slightly different .  But this functionality is
the most flexible in my opinion.   It will support any application directory
structure that a user may want.   The scripts that ship with the wrapper
assume a directory structure where the Wrapper binary is located in the
bin directory, but there is nothing stopping the user from modifying the
scripts so that the Wrapper binary can be located elsewhere.  You just
have to follow the rule that all relative paths are relative to its new
location.

The UNIX side works slightly differently than the Windows platform in
that the current directory is set by the shell scripts rather than the 
binary
so in that way, they are a little more flexible.

If you create an environment variable in your wrapper.conf file with the
following value, you can then use that throughout the rest of the
config file to set all your other paths.
set.APP_HOME=../
wrapper.java.classpath.1=%APP_HOME%/lib/wrapper.jar

I think this is a lot less cluttered however:
wrapper.java.classpath.1=../lib/wrapper.jar

Hope this explanation helps.  Let me know if you have any suggestions on
improving how this works and I'll give them some thought.

Cheers,
Leif

Anthony Frey wrote:

> First off, I must say this is one of the nicest Java service wrappers 
> I have yet to use. It's flexibility and ease-of-use are unmatched! 
> Kudos and thanks to Leif and the Wrapper team for making it available.
> I think I may be missing something with configuration that I'm hoping 
> someone has some suggestions for.
>
> My standard practice has always been to write config files for my Java 
> applications such that paths are relative to the "home" directory of 
> the application. I also like to put executables (including Wrapper) in 
> a "bin" directory. I know Wrapper is designed to always use the 
> executable directory as the working directory and that relative paths 
> can be used in wrapper.conf which is great because I can count on it.
>
> My problem is that all of my non-wrapper.conf config files also need 
> to be "aware" of the location of the executable and specify relative 
> paths with a '../' prefix. The solution I've come up with is to add a 
> "app.home" system property that gets used as the base to all relative 
> paths throughout my application. This is a little cumbersome though 
> since this needs to be done everywhere throughout the application. Is 
> it possible to set the Java process's notion of the current working 
> directory to this "home" directory or am I missing something else 
> entirely?
>
> Thanks for the help,
> -Tony

Re: [Wrapper-user] Wrapper's current working directory

[Anthony F. <an...@re...>]

Leif,

I had a feeling this issue would be a can of worms when I asked it :-). I 
agree, you can't expect it to be perfect for everyone and you have to come 
down on it somewhere. In fact I wish more packages had your perspective on 
installing, my life would be much easier! Quite honestly it's not something 
that I can't live with but I thought I'd ask in case I was missing something.

But as a suggestion, I don't think setting the java process directory might be 
that confusing. If the config parameter were well chosen, 
"wrapper.java.command.directory" for example, it should still be fairly clear 
that this applies only to the java process. Without it the default behavior 
would be the same. That doesn't solve the problem with paths specified as 
additional parameters though.


--Tony

Leif Mortenson wrote:
> Anthony,
> 
> Early versions of the Wrapper did not used to set the current directory.
> But the problem was that this made it very difficult to use relative paths
> when working with the Wrapper.
> 
> Here is the problem:
> If you first cd into a C:\myapp\bin directory and then run the Wrapper
> then your current directory will be C:\myapp\bin and a reference to the
> wrapper configuration file of ..\conf\wrapper.conf will work correctly.
> 
> But if your current directory is C:\myapp, and you launch the Wrapper
> using a reference like bin\Myapp.bat then the above reference to the
> conf file will fail as the ..\conf\wrapper.conf reference would resolve to
> C:\conf\wrapper.conf, which is not correct.
> 
> To make things worse, when you install the wrapper as an NT service,
> the current working directory will be C:\Windows\service32.
> 
> For this reason, you pretty much had to use absolute paths with earlier
> versions of the Wrapper.  This unfortunately made it more difficult to
> install software that used the Wrapper as the installer would have to go
> through and set all of the absolute paths in the application at install 
> time.
> 
> This is a common problem to all Windows, UNIX and other applications
> and it would have been Ok, to force users to follow that standard.
> 
> But I found it annoying and wanted to fix it.  The easiest install 
> program in
> my book is one where you just unzip an archive file unto the directory of
> your choice and have everything work!   Many applications, work this way
> no problem but you have to run the application from a specific location
> otherwise the relative paths all fail to resolve.
> 
> Originally, I wanted to have a configurable working directory in the
> wrapper.conf file.  But there was a chicken and the egg problem.  You
> need to be able to locate the wrapper.conf file before it can be loaded.
> And to do that, you have to have a fixed starting point.   So I decided to
> just have the Wrapper binary always force its working directory to be the
> same as its location.
> 
> One option that I considered was to have the Wrapper behave as it does
> now with respect to locating the wrapper.conf file, but then once it was
> loaded change over to using a working directory configured in the conf 
> file.
> Bu that seemed like it would just get confusing for users without actually
> giving any new functionality.   The problem there is that you can define
> properties from the command line as well.  And paths in those properties
> would be using a different base location than that used to locate the
> wrapper.conf file.  For example:
> Wrapper.exe -c ../conf/wrapper.conf 
> wrapper.java.additional.1=-Dconf.file=conf/wrapper.conf
> In the end I decided that this is one area where it would be best to limit
> flexibility and just stick to forcing the location of the working 
> directory.
> 
> For any decision I could have made, there would always be someone
> who wanted to do something slightly different .  But this functionality is
> the most flexible in my opinion.   It will support any application 
> directory
> structure that a user may want.   The scripts that ship with the wrapper
> assume a directory structure where the Wrapper binary is located in the
> bin directory, but there is nothing stopping the user from modifying the
> scripts so that the Wrapper binary can be located elsewhere.  You just
> have to follow the rule that all relative paths are relative to its new
> location.
> 
> The UNIX side works slightly differently than the Windows platform in
> that the current directory is set by the shell scripts rather than the 
> binary
> so in that way, they are a little more flexible.
> 
> If you create an environment variable in your wrapper.conf file with the
> following value, you can then use that throughout the rest of the
> config file to set all your other paths.
> set.APP_HOME=../
> wrapper.java.classpath.1=%APP_HOME%/lib/wrapper.jar
> 
> I think this is a lot less cluttered however:
> wrapper.java.classpath.1=../lib/wrapper.jar
> 
> Hope this explanation helps.  Let me know if you have any suggestions on
> improving how this works and I'll give them some thought.
> 
> Cheers,
> Leif
> 
> Anthony Frey wrote:
> 
>> First off, I must say this is one of the nicest Java service wrappers 
>> I have yet to use. It's flexibility and ease-of-use are unmatched! 
>> Kudos and thanks to Leif and the Wrapper team for making it available.
>> I think I may be missing something with configuration that I'm hoping 
>> someone has some suggestions for.
>>
>> My standard practice has always been to write config files for my Java 
>> applications such that paths are relative to the "home" directory of 
>> the application. I also like to put executables (including Wrapper) in 
>> a "bin" directory. I know Wrapper is designed to always use the 
>> executable directory as the working directory and that relative paths 
>> can be used in wrapper.conf which is great because I can count on it.
>>
>> My problem is that all of my non-wrapper.conf config files also need 
>> to be "aware" of the location of the executable and specify relative 
>> paths with a '../' prefix. The solution I've come up with is to add a 
>> "app.home" system property that gets used as the base to all relative 
>> paths throughout my application. This is a little cumbersome though 
>> since this needs to be done everywhere throughout the application. Is 
>> it possible to set the Java process's notion of the current working 
>> directory to this "home" directory or am I missing something else 
>> entirely?
>>
>> Thanks for the help,
>> -Tony
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user