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

[Fredrik I. <fre...@st...>]

Citerat fr=E5n  Leif Mortenson <le...@ta...>:

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

I don't question writing the wrapper in C. My question is more like why o=
ne=20
cannot make one wrapper release with binaries needed for all platforms. I=
 mean,=20
storage space for the few MB:s needed is not a problem theese days.

>     Your main question was about the wrapper.conf file and having to=20
> 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=20
> 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=20
> course some
> properties which are ignored on UNIX or Windows platforms.  These=20
> include the
> NT service properties, which are obviously only used under Windows, and
> the
> daemonize property which is only used on UNIX.
>=20
>     Integrating the Wrapper into your application does have the drawbac=
k
>=20
> of requiring
> you to start making platform specific binary releases of your=20
> application.  But this
> is only to include the Wrapper binary code.  All of your code, includin=
g
> the
> wrapper.conf file will be 100% platform independent.
>     For customer applications, I usually like to avoid problems caused
>=20
> by the customer
> running a different JRE by simply including a JRE in my application=20
> release.  This
> obviously increases the release size, but so far it has been well worth
> it.
>=20
>     The following is a directory structure that I typically use for Jav=
a
>=20
> applications.
> .../app/bin
> .../app/conf
> .../app/lib
> .../app/jre
> .../app/<etc>
>=20
>     The Wrapper.exe, App.bat, InstallApp-NT.bat,=20
> 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=20
> rest of the
> application's configuration files.
>     The Wrapper.dll (Windows), libwrapper.so(UNIX),=20
> libwrapper.jnilib(MacOSX)
> and wrapper.jar files all go into the lib directory along with the rest
>=20
> 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=20
> are relative to the bin
> directory.  This will make your application very portable.
>=20
> Let me know if you have any further questions or suggestions.
>=20
> Cheers,
> Leif

If one includes the jre, I see a problem with my idea. The installation w=
ould=20
become very large with 5-10 jre:s for different platforms.=20

In February I wrote an application that I wanted to be able to run on Win=
dows,=20
Linux and Solaris. I downloaded the wrapper for those platforms and manua=
lly=20
merged the files into one release. That meant renaming the binaries "real=
path",=20
"testwrapper" and "wrapper", as those are identical in name on Linux and=20
Solaris, and to manually go through the installation scripts making sure =
that=20
they called the correct file. The problem is that doing this manually for=
 each=20
new version of wrapper, I know I am going to make a misstake sooner or la=
ter.
Also, there was no real reason why my code would not run on aix our hpux,=
 but I=20
was to lazy to include those as I thougt it was not likely that anyone wo=
uld run=20
it on those platforms.

If all platform specific files got a name that included the platform name=
, then=20
only one wrapper distribution would be necessary, instead of 8. If one=20
absolutely do not want support for more than one platform, one can delete=
 all=20
files with a name including another platform.=20

/Fredrik

> Fredrik Israelsson wrote:
>=20
> >Hello
> >First of all, I want to thank you for wrapper, giving functionality
> that should=20
> >have been supported by Sun a long time ago IMHO.
> >
> >I have a theoretical question. What is the main problem(s) that keeps
> wrapper=20
> >from becoming a single release (with a single config-file) for all
> platforms=20
> >supported?
> >
> >One of my main arguments for using java is platform portability. When =
I
> make a=20
> >service/daemon, I would like it to be able to run on as many platforms
> as=20
> >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=20
> >there different downloads available?
> >
> >Regards
> >Fredrik Israelsson
> > =20
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>=20