Re: [Wrapper-user] Single wrapper release possible?

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

Fredrik,
    The Wrapper provides several functions which would be impossible to 
implement in
pure Java.  These include interacting with the NT service manager on 
Windows, low
level process control on the UNIX platforms, and the ability to trap 
system signals on
all platforms.
    Another reason for writing the Wrapper in C was to make it light 
weight.  One of
the main reasons that I wrote the Java Service Wrapper in the first 
place was because
I was having problems with unreliable JVMs that kept crashing on me. The 
Wrapper,
as you may know, has the ability to monitor the Java process and restart 
it in the
event of a hang or crash, with very little downtime.  Java is great, but 
it also has a
very large memory footprint and I wanted the Wrapper to be as small as 
possible.
    Perl could have been another option on UNIX systems, but that would 
have placed
a requirement on Perl which I did not want to add.  On Windows, C was 
the only real
choice.  The majority of the Wrapper's C code is cross platform, so C 
became the
final language of choice.

    Your main question was about the wrapper.conf file and having to 
create a new conf
file for each platform.   This should actually not be necessary.   The 
Wrapper was
specifically designed to make the wrapper.conf file portable.  If you 
use forward slashes
in all paths, and use relative paths as much as possible then your conf 
file will work
as is no matter what platform the Wrapper is run on.   There are of 
course some
properties which are ignored on UNIX or Windows platforms.  These 
include the
NT service properties, which are obviously only used under Windows, and the
daemonize property which is only used on UNIX.

    Integrating the Wrapper into your application does have the drawback 
of requiring
you to start making platform specific binary releases of your 
application.  But this
is only to include the Wrapper binary code.  All of your code, including the
wrapper.conf file will be 100% platform independent.
    For customer applications, I usually like to avoid problems caused 
by the customer
running a different JRE by simply including a JRE in my application 
release.  This
obviously increases the release size, but so far it has been well worth it.

    The following is a directory structure that I typically use for Java 
applications.
.../app/bin
.../app/conf
.../app/lib
.../app/jre
.../app/<etc>

    The Wrapper.exe, App.bat, InstallApp-NT.bat, 
UninstallApp-NT.bat(Windows)
or wrapper, app.sh(wrapper) files all go into the bin directory.
    The wrapper.conf file goes into the conf directory along with the 
rest of the
application's configuration files.
    The Wrapper.dll (Windows), libwrapper.so(UNIX), 
libwrapper.jnilib(MacOSX)
and wrapper.jar files all go into the lib directory along with the rest 
of the application's
jar files and any other native libraries.
    The JRE is copied into the jre directory etc.
    Then in the wrapper.conf file, and in your application, all paths 
are relative to the bin
directory.  This will make your application very portable.

Let me know if you have any further questions or suggestions.

Cheers,
Leif

Fredrik Israelsson wrote:

>Hello
>First of all, I want to thank you for wrapper, giving functionality that should 
>have been supported by Sun a long time ago IMHO.
>
>I have a theoretical question. What is the main problem(s) that keeps wrapper 
>from becoming a single release (with a single config-file) for all platforms 
>supported?
>
>One of my main arguments for using java is platform portability. When I make a 
>service/daemon, I would like it to be able to run on as many platforms as 
>possible, out of the box, without having to maintain several config files etc.
>
>Maybe this is possible already? I am not a wrapper expert, but then, why are 
>there different downloads available?
>
>Regards
>Fredrik Israelsson
>  
>