wrapper-user — User issues for Wrapper. (Support questions, etc.)

Re: [Wrapper-user] problem loading libwrapper.so

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

Xavier,
    Can you set the wrapper.debug=true property and try this again?  It 
will show a little
more information about why the library could not be loaded.  You may be 
missing a
required system library or something.

Cheers,
Leif

Xavier Toth wrote:
> I'm running on Fedora Core 5 with SELinux in Permissive mode. I've 
> verified that I have the 32 bit version and that the file is owned by 
> the user who my services run as. Is there something I'm missing here?
>
>
> STATUS | wrapper  | 2006/03/28 15:06:10 | --> Wrapper Started as Daemon
> STATUS | wrapper  | 2006/03/28 15:06:11 | Launching a JVM...
> INFO   | jvm 1    | 2006/03/28 15:06:11 | Wrapper (Version 3.2.0) 
> http://wrapper.tanukisoftware.org
> INFO   | jvm 1    | 2006/03/28 15:06:11 |
> INFO   | jvm 1    | 2006/03/28 15:06:11 |
> INFO   | jvm 1    | 2006/03/28 15:06:11 | WARNING - Unable to load the 
> Wrapper's native library 'libwrapper.so'.
> INFO   | jvm 1    | 2006/03/28 15:06:11 |           The file is 
> located on the path at the following location but
> INFO   | jvm 1    | 2006/03/28 15:06:11 |           could not be loaded:
> INFO   | jvm 1    | 2006/03/28 15:06:11 |             
> /opt/jwss/lib/libwrapper.so
> INFO   | jvm 1    | 2006/03/28 15:06:11 |           Please verify that 
> the file is readable by the current user
> INFO   | jvm 1    | 2006/03/28 15:06:11 |           and that the file 
> has not been corrupted in any way.
> INFO   | jvm 1    | 2006/03/28 15:06:11 |           One common cause 
> of this problem is running a 32-bit version
> INFO   | jvm 1    | 2006/03/28 15:06:11 |           of the Wrapper 
> with a 64-bit version of Java, or vica versa.
> INFO   | jvm 1    | 2006/03/28 15:06:11 |           This is a 32-bit JVM.
> INFO   | jvm 1    | 2006/03/28 15:06:11 |           System signals 
> will not be handled correctly.
> INFO   | jvm 1    | 2006/03/28 15:06:11 |
>

[Wrapper-user] problem loading libwrapper.so

[Xavier T. <tx...@gm...>]

I'm running on Fedora Core 5 with SELinux in Permissive mode. I've verified
that I have the 32 bit version and that the file is owned by the user who m=
y
services run as. Is there something I'm missing here?


STATUS | wrapper  | 2006/03/28 15:06:10 | --> Wrapper Started as Daemon
STATUS | wrapper  | 2006/03/28 15:06:11 | Launching a JVM...
INFO   | jvm 1    | 2006/03/28 15:06:11 | Wrapper (Version 3.2.0)
http://wrapper.tanukisoftware.org
INFO   | jvm 1    | 2006/03/28 15:06:11 |
INFO   | jvm 1    | 2006/03/28 15:06:11 |
INFO   | jvm 1    | 2006/03/28 15:06:11 | WARNING - Unable to load the
Wrapper's native library 'libwrapper.so'.
INFO   | jvm 1    | 2006/03/28 15:06:11 |           The file is located on
the path at the following location but
INFO   | jvm 1    | 2006/03/28 15:06:11 |           could not be loaded:
INFO   | jvm 1    | 2006/03/28 15:06:11 |
/opt/jwss/lib/libwrapper.so
INFO   | jvm 1    | 2006/03/28 15:06:11 |           Please verify that the
file is readable by the current user
INFO   | jvm 1    | 2006/03/28 15:06:11 |           and that the file has
not been corrupted in any way.
INFO   | jvm 1    | 2006/03/28 15:06:11 |           One common cause of thi=
s
problem is running a 32-bit version
INFO   | jvm 1    | 2006/03/28 15:06:11 |           of the Wrapper with a
64-bit version of Java, or vica versa.
INFO   | jvm 1    | 2006/03/28 15:06:11 |           This is a 32-bit JVM.
INFO   | jvm 1    | 2006/03/28 15:06:11 |           System signals will not
be handled correctly.
INFO   | jvm 1    | 2006/03/28 15:06:11 |

Re: [Wrapper-user] Problems loading wrapper.dl: missing MSJAVA.DLL - updated

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

Alec,
    That makes me wonder if your system is attempting to locate a Java 
installation on the
system path.  The Sun JVMs should not need that dll.  Try changing your 
wrapper.conf
file to output debug information with wrapper.debug=true.   Then set the 
JVM to an
absolute java binary.  For example:
wrapper.java.command=C:/Sun/j2sdk1.4.2_08/bin/java

    If you have a JAVA_HOME environment variable set, you can also try this:
wrapper.java.command=%JAVA_HOME%/bin/java

    The debug output will include a line which shows the version of java 
being run.

Cheers,
Leif


Ale...@qu... wrote:
> Further consultation with local Windows gurus suggest that it is not 
> necessarily the absence of MSJAVA.dll which causes problems, because this 
> is delay loaded. However, the fact remains that we can run the wrapper 
> quite happily in Windows 2000 and not on Windows XP Professional - and can 
> find no reason for the difference. Any ideas?
>
> Alec Cawley
>
> wra...@li... wrote on 22/03/2006 10:24:00:
>
>   
>> We have had problems, as others have, in loading the wrapper.dll. With 
>>     
> us, 
>   
>> it worked on some systems but not on others. The problem now appears to 
>>     
> be 
>   
>> OS dependent: there is a dependancey on a DLL called MSJAVA.DLL. This is 
>>     
>
>   
>> present on Windows NT and 2000, but not on Windows XP. I conjecture that 
>>     
>
>   
>> this is due to Microsoft's settlement with Sun about their "forking" of 
>> Java. However it may be, this is liley to be a problem to us.
>>
>> I have not yet tried copying over the MSJAVA.DLL - and I am uncertain 
>> about the intellectual property considerations of doing so.
>>
>> Is the an alternative, proper, source of this DLL, or can we rebuiild 
>>     
> not 
>   
>> to use it?
>>     
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>   

Re: [Wrapper-user] Problems loading wrapper.dl: missing MSJAVA.DLL - updated

[<Ale...@qu...>]

Further consultation with local Windows gurus suggest that it is not 
necessarily the absence of MSJAVA.dll which causes problems, because this 
is delay loaded. However, the fact remains that we can run the wrapper 
quite happily in Windows 2000 and not on Windows XP Professional - and can 
find no reason for the difference. Any ideas?

Alec Cawley

wra...@li... wrote on 22/03/2006 10:24:00:

> We have had problems, as others have, in loading the wrapper.dll. With 
us, 
> it worked on some systems but not on others. The problem now appears to 
be 
> OS dependent: there is a dependancey on a DLL called MSJAVA.DLL. This is 

> present on Windows NT and 2000, but not on Windows XP. I conjecture that 

> this is due to Microsoft's settlement with Sun about their "forking" of 
> Java. However it may be, this is liley to be a problem to us.
> 
> I have not yet tried copying over the MSJAVA.DLL - and I am uncertain 
> about the intellectual property considerations of doing so.
> 
> Is the an alternative, proper, source of this DLL, or can we rebuiild 
not 
> to use it?

[Wrapper-user] Problems loading wrapper.dl: missing MSJAVA.DLL

[<Ale...@qu...>]

We have had problems, as others have, in loading the wrapper.dll. With us, 
it worked on some systems but not on others. The problem now appears to be 
OS dependent: there is a dependancey on a DLL called MSJAVA.DLL. This is 
present on Windows NT and 2000, but not on Windows XP. I conjecture that 
this is due to Microsoft's settlement with Sun about their "forking" of 
Java. However it may be, this is liley to be a problem to us.

I have not yet tried copying over the MSJAVA.DLL - and I am uncertain 
about the intellectual property considerations of doing so.

Is the an alternative, proper, source of this DLL, or can we rebuiild not 
to use it?

        Alec cawley

[Wrapper-user] Wrapper error messages

[Juergen H. <jh...@we...>]

Hi,=20Leif.=20The=20following=20code=20makes=20it=20hard=20to=20debug=20pr=
oblems=20when=20you=20
get=20that=20error...

=20=20=20=20/*=20Get=20the=20full=20path=20and=20filename=20of=20this=20pr=
ogram=20*/
=20=20=20=20if=20(realpath(app,=20szPath)=20=3D=3D=20NULL)=20{
=20=20=20=20=20=20=20=20log_printf(WRAPPER_SOURCE_WRAPPER,=20LEVEL_FATAL,=20=

=09=09"Unable=20to=20get=20the=20path-%s",=20getLastErrorText());
=20=20=20=20=20=20=20=20return=201;
=20=20=20=20}

A=20better=20version=20would=20be:

=20=20=20=20=20=20=20=20log_printf(WRAPPER_SOURCE_WRAPPER,=20LEVEL_FATAL,=20=

=09=09"Unable=20to=20get=20the=20path=20for=20'%s'-%s",=20app,=20getLastEr=
rorText
());

This=20might=20be=20true=20for=20other,=20similar=20error=20messages.



Ciao,=20J=FCrgen

Re: [Wrapper-user] Problem loading wrapper.dll

[David R R. <drr...@op...>]

This is the errors I get with wrapper.debug=true

jvm 1    | 1432 [main] INFO  com.orci.VVVIntegrator.MainApp  - 
VVVIntegrator Ready
jvm 1    | WrapperManager class initialized by thread: main  Using 
classloader: null
jvm 1    | Wrapper (Version 3.2.0) http://wrapper.tanukisoftware.org
jvm 1    |
jvm 1    | Wrapper Manager: JVM #1
jvm 1    | Running a 32-bit JVM.
jvm 1    | Wrapper Manager: Registering shutdown hook
jvm 1    | Wrapper Manager: Using wrapper
jvm 1    | Load native library.  One or more attempts may fail if 
platform specific libraries do not exist.
jvm 1    | Loading native library failed: wrapper-windows-x86-32.dll  
Cause: java.lang.UnsatisfiedLinkError: no wrapper-windows-x86-32 in 
java.library.path
jvm 1    | Loading native library failed: wrapper.dll  Cause: 
java.lang.UnsatisfiedLinkError: no wrapper in java.library.path
jvm 1    |
jvm 1    | WARNING - Unable to load the Wrapper's native library 
'wrapper.dll'.
jvm 1    |           The file is located on the path at the following 
location but
jvm 1    |           could not be loaded:
jvm 1    |             
C:\Workspaces\VICADS\VICADS-Security\bin\..\lib\wrapper.dll
jvm 1    |           Please verify that the file is readable by the 
current user
jvm 1    |           and that the file has not been corrupted in any way.
jvm 1    |           One common cause of this problem is running a 
32-bit version
jvm 1    |           of the Wrapper with a 64-bit version of Java, or 
vica versa.
jvm 1    |           This is a 32-bit JVM.
jvm 1    |           System signals will not be handled correctly.
jvm 1    |
jvm 1    | Java Version   : 1.5.0_06-b05 Java HotSpot(TM) Client VM
jvm 1    | Java VM Vendor : Sun Microsystems Inc.
jvm 1    |
jvm 1    | WrapperManager.start(com.orci.VVVIntegrator.MainApp@1ad98ef, 
args["-vxmlUser", "orci", "-vxmlPass", "orci", "-vxmlServer", 
"192.168.100.209"]) called by thread: main


Any thoughts?
David

Leif Mortenson wrote:
> David,
>    I just retested it with 1.5.0_03 and it works fine for me.
>    Try running it with the wrapper.debug=true property set.  This will 
> show a little
> more information about the reason the library could not be loaded.
>
>    Is it the exact same installation as you are using with Java 1.4?  
> There have been
> a couple times in the past where users were having problems due to 
> corrupted
> files.  Doesn't sound like that is the case with you.
>
>    I've only released the 32-bit wrapper for Windows and you are 
> running a
> 32-bit JVM, so that's not the problem.
>
> Cheers,
> Leif
>
> David R Robison wrote:
>> When I run my service in a command line mode, I get the following error:
>>
>> INFO   | jvm 1    | 2006/03/16 13:17:11 | WARNING - Unable to load 
>> the Wrapper's native library 'wrapper.dll'.
>> INFO   | jvm 1    | 2006/03/16 13:17:11 |           The file is 
>> located on the path at the following location but
>> INFO   | jvm 1    | 2006/03/16 13:17:11 |           could not be loaded:
>> INFO   | jvm 1    | 2006/03/16 13:17:11 |             
>> C:\Workspaces\VICADS\VICADS-Security\bin\..\lib\wrapper.dll
>> INFO   | jvm 1    | 2006/03/16 13:17:11 |           Please verify 
>> that the file is readable by the current user
>> INFO   | jvm 1    | 2006/03/16 13:17:11 |           and that the file 
>> has not been corrupted in any way.
>> INFO   | jvm 1    | 2006/03/16 13:17:11 |           One common cause 
>> of this problem is running a 32-bit version
>> INFO   | jvm 1    | 2006/03/16 13:17:11 |           of the Wrapper 
>> with a 64-bit version of Java, or vica versa.
>> INFO   | jvm 1    | 2006/03/16 13:17:11 |           This is a 32-bit 
>> JVM.
>> INFO   | jvm 1    | 2006/03/16 13:17:11 |           System signals 
>> will not be handled correctly.
>>
>> I get this when I run with Java 5. Running with Java 4 does not give 
>> me this error. I've downloaded and installed the latest version of 
>> wrapper. Any thoughts?
>>
>> David Robison
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user

-- 

David R Robison
Open Roads Consulting, Inc.
708 S. Battlefield Blvd., Chesapeake, VA 23322
phone: (757) 546-3401
e-mail: drr...@op...
web: http://openroadsconsulting.com
blog: http://therobe.blogspot.com
book: http://www.xulonpress.com/bookstore/titles/1597816523.htm

 

Re: [Wrapper-user] wont start on boot with gentoo

[Gene <gen...@gm...>]

TGVpZiwKCkkgdGhpbmsgSSBoYXZlIGNvbWUgdXAgd2l0aCBhIHNvbHV0aW9uIChoYWNrKSBmb3Ig
Z2V0dGluZyBteSBqYXZhCnByb2dyYW0gdG8gcnVuIGF0IGJvb3Qgb24gZ2VudG9vLiBJIGZvbGxv
d2VkIHRoZSBpbnN0cnVjdGlvbnMgb24gdGhpcwpwYWdlOiBodHRwOi8vZ2VudG9vLXdpa2kuY29t
L0hPV1RPX01ha2VfYW5fcmNfc2NyaXB0IGFuZCBhbSBub3cgdXNpbmcKdGhlIHN0YXJ0LXN0b3At
ZGFlbW9uIHByb2dyYW0gdG8gY2FsbCB0aGUgcnVuLnNoIHdyYXBwZXIgc2NyaXB0LiBUaGlzCnNl
ZW1zIHRvIGJlIHdvcmtpbmcgb2sgYnkgdGVsbGluZyBpdCB3aGVyZSB0byBmaW5kIHRoZSBwaWQg
ZmlsZSB0aGF0CnRoZSBydW4uc2ggc2NyaXB0IGlzIGdlbmVyYXRpbmcuIFlvdSBjYW4gc2VlIHRo
ZSBzY3JpcHQgYmVsb3cuIE9uZQpwcm9ibGVtIEkgYmVsaWV2ZSBpcyB0aGlzIGlmIHlvdSBkbyBh
IHJlc3RhcnQgdXNpbmcgdGhlIGJlbG93IHNjcmlwdAppdCBraWxscyB0aGUgd3JhcHBlciBwcm9n
cmFtIGFuZCBzcGF3bnMgYSBuZXcgb25lLCB3aGljaCBJIGJlbGlldmUKZG9lc24ndCBoYXBwZW4g
aWYgeW91IGp1c3QgZG8gcnVuLnNoIHJlc3RhcnQgY29ycmVjdD8gSWYgSSBoYXZlIHRvCnJlc3Rh
cnQgdGhlIHByb2dyYW0gd2hpbGUgbG9nZ2VkIGluIGkgY2FuIGp1c3QgZG8gcnVuLnNoIHJlc3Rh
cnQgc28KaXQncyBub3QgYSBiaWcgZGVhbC4KCiMjIyBGaWxlIGluIC9ldGMvaW5pdC5kLyAjIyMK
IyEvc2Jpbi9ydW5zY3JpcHQKCmRlcGVuZCgpIHsKICAgICAgICBuZWVkIG5ldAogICAgICAgIHVz
ZSBsb2dnZXIKfQoKc3RhcnQoKSB7CiAgICAgICAgZWJlZ2luICJTdGFydGluZyBEYXRhYmFzZSBN
YW5hZ2VyIgogICAgICAgIHN0YXJ0LXN0b3AtZGFlbW9uIC0tc3RhcnQgLS1iYWNrZ3JvdW5kIC0t
cGlkZmlsZQovd3JhcHBlci9saW51eC14ODYtNjQvREJNQU5BR0VSLnBpZCAtLWV4ZWMKL3dyYXBw
ZXIvbGludXgteDg2LTY0L3J1bi5zaCAtLSBzdGFydAogICAgICAgIGVlbmQgJD8KfQoKc3RvcCgp
IHsKICAgICAgICBlYmVnaW4gIlN0b3BwaW5nIERhdGFiYXNlIE1hbmFnZXIiCiAgICAgICAgc3Rh
cnQtc3RvcC1kYWVtb24gLS1zdG9wICAtLXBpZGZpbGUgL3dyYXBwZXIvbGludXgteDg2LTY0L0RC
TUFOQUdFUi5waWQKICAgICAgICBlZW5kICQ/Cn0KCnJlc3RhcnQoKSB7CiAgICAgICAgc3RhcnQt
c3RvcC1kYWVtb24gLS1zdG9wICAtLXBpZGZpbGUgL3dyYXBwZXIvbGludXgteDg2LTY0L0RCTUFO
QUdFUi5waWQKICAgICAgICBzbGVlcCA1CiAgICAgICAgc3RhcnQtc3RvcC1kYWVtb24gLS1zdGFy
dCAtLWJhY2tncm91bmQgLS1waWRmaWxlCi93cmFwcGVyL2xpbnV4LXg4Ni02NC9EQk1BTkFHRVIu
cGlkIC0tZXhlYwovd3JhcHBlci9saW51eC14ODYtNjQvcnVuLnNoIC0tIHN0YXJ0Cn0KCkdlbmUK
Ck9uIDMvMTcvMDYsIExlaWYgTW9ydGVuc29uIDxsZWlmQHRhbnVraXNvZnR3YXJlLmNvbT4gd3Jv
dGU6Cj4gR2VuZSwKPiAgICAgV2hlbiBpcyB0aGUgb3V0cHV0IHNob3duIGluIHRoZSBtZXNzYWdl
cyBsb2cgZmlsZSBnZW5lcmF0ZWQuICBBcmUKPiB0aG9zZSBydW5zIGZyb20gd2hlbiB5b3UgcmFu
ICIvZXRjL2luaXQuZC9wcm9ncmFtIGNvbnNvbGUiIGFuZAo+ICIvZXRjL2luaXQuZC9wcm9ncmFt
IHN0YXJ0IiBmcm9tIHRoZSBjb21tYW5kIGxpbmUgbWFudWFsbHk/Cj4gICAgIEFyZSB5b3Ugc2Vl
aW5nIHRoZSB3cmFwcGVyLmxvZyBmaWxlIGluIHRob3NlIGNhc2VzPwo+Cj4gICAgIFdoZW4geW91
IHJlYm9vdCwgdGhlIHN5c3RlbSB3aWxsIGxhdW5jaCB0aGUgaW5pdCBzY3JpcHRzIGFzIHJvb3QK
PiBzbyBpdCBpcyB1bmxpa2VseSB0aGF0IHRoZXJlIHdpbGwgYmUgYW55IHBlcm1pc3Npb24gcHJv
YmxlbXMgdW5sZXNzIHlvdQo+IGhhdmUgY29uZmlndXJlZCBhIHJ1biBhcyB1c2VyIGluIHRoZSB3
cmFwcGVyIHNoZWxsIHNjcmlwdC4KPgo+ICAgICBUaGUgb25seSB0aGluZyBJIGNhbiB0aGluayBv
ZiBhdCB0aGUgbW9tZW50IGlzIHRoZSBydW4gbGV2ZWwgbGlua3MuCj4gU2ltcGx5IHBsYWNpbmcg
YSBzY3JpcHQgaW4gdGhlIGluaWQuZCBkaXJlY3RvcnkgZG9lcyBub3QgbWVhbiB0aGF0IHRoZQo+
IHNjcmlwdCB3aWxsIGJlIHJ1biBhdCBzdGFydHVwIGFuZCBzaHV0ZG93biAgWW91IHN0aWxsIG5l
ZWQgdG8gc2V0IHVwCj4gdGhlIHN5c3RlbSB0byBydW4gdGhlIHNjcmlwdCBhdCB0aGUgdmFyaW91
cyBzeXN0ZW0gcnVuIGxldmVscy4gIE5vdAo+IHN1cmUgZXhhY3RseSBob3cgdGhpcyBpcyBjb25m
aWd1cmVkIGZvciBnZW50b28uICBUYWtlIGEgbG9vayBhdCB0aGUKPiBmb2xsb3dpbmcgcGFnZXMg
Zm9yIGV4YW1wbGVzIG9uIERlYmlhbiBhbmQgU29sYXJpcy4gICBJZiB5b3UgZmlndXJlCj4gb3V0
IHRoZSBjb3JyZWN0IHdheSB0byBkbyB0aGlzIG9uIEdlbnRvbywgSSdkIGxvdmUgdG8gc2V0IHVw
IGEKPiBHZW50b28gcGFnZSBhcyB3ZWxsLgo+IGh0dHA6Ly93cmFwcGVyLnRhbnVraXNvZnR3YXJl
Lm9yZy9kb2MvZW5nbGlzaC9sYXVuY2gtbml4Lmh0bWwjYm9vdAo+Cj4gQ2hlZXJzLAo+IExlaWYK
Pgo+IEdlbmUgd3JvdGU6Cj4gPiBSdW5uaW5nIG15IHByb2dyYW0gZnJvbSBnZW50b28gYXQgdGhl
IGNvbnNvbGU6Cj4gPiAgICAgICAvZXRjL2luaXQuZC9wcm9ncmFtIHN0YXJ0Cj4gPiB3b3JrcyBm
aW5lIGJ1dCB3aGVuIGkgcmVib290IGl0IHdpbGwgbm90IHN0YXJ0LCBpdCB3b24ndCBldmVuIGdl
bmVyYXRlCj4gPiB0aGUgd3JhcHBlci5sb2cuCj4gPiBJJ3ZlIHB1dCBpbiB0aGUgZnVsbCBwYXRo
IHRvIGphdmEgaW4gd3JhcHBlci5jb25mCj4gPgo+ID4gVGhpcyBpcyB3aGF0J3MgaW4gL3Zhci9s
b2cvbWVzc2FnZXMKPiA+Cj4gPiBNYXIgMTcgMDE6NTQ6MjEgZGJtYW5hZ2VyIERCTUFOQUdFUls3
MDc3XTogLS0+IFdyYXBwZXIgU3RhcnRlZCBhcyBDb25zb2xlCj4gPiBNYXIgMTcgMDE6NTQ6MjEg
ZGJtYW5hZ2VyIERCTUFOQUdFUls3MDc3XTogTGF1bmNoaW5nIGEgSlZNLi4uCj4gPiBNYXIgMTcg
MDE6NTQ6NDggZGJtYW5hZ2VyIERCTUFOQUdFUls3MDc3XTogSU5UIHRyYXBwZWQuICBTaHV0dGlu
ZyBkb3duLgo+ID4gTWFyIDE3IDAxOjU0OjQ5IGRibWFuYWdlciBEQk1BTkFHRVJbNzA3N106IDwt
LSBXcmFwcGVyIFN0b3BwZWQKPiA+IE1hciAxNyAwMTo1NTowNCBkYm1hbmFnZXIgREJNQU5BR0VS
WzcxODBdOiAtLT4gV3JhcHBlciBTdGFydGVkIGFzIERhZW1vbgo+ID4gTWFyIDE3IDAxOjU1OjA0
IGRibWFuYWdlciBEQk1BTkFHRVJbNzE4MF06IExhdW5jaGluZyBhIEpWTS4uLgo+ID4gTWFyIDE3
IDAxOjU5OjI1IGRibWFuYWdlciBEQk1BTkFHRVJbNzE4MF06IFRFUk0gdHJhcHBlZC4gIFNodXR0
aW5nIGRvd24uCj4gPiBNYXIgMTcgMDE6NTk6MjYgZGJtYW5hZ2VyIERCTUFOQUdFUls3MTgwXTog
PC0tIFdyYXBwZXIgU3RvcHBlZAo+ID4KPiA+IEknbSBub3QgYSBsaW51eCBleHBlcnQgc28gSSBj
b3VsZCBiZSBqdXN0IGRvaW5nIHNvbWV0aGluZyB2ZXJ5IGR1bWIhCj4gPiBUaGFua3MgZm9yIGFu
eSBzdWdnZXN0aW9ucy4KPiA+Cj4gPiBHZW5lIEhhcnQKPiA+IE4Y77+9SFNe77+96ZqKWO+/ve+/
ve+/vSfvv73vv73vv71177+977+9PO+/vdqC77+9Lu+/ve+/ve+/vXnvv70i77+9Cxzvv70qbe+/
vXglanguagfvv73vv73vv71e77+916d2xqnvv71Y77+9atio77+9yKfvv73vv70ebe+/vd2a77+9
77+977+9dibvv73vv73Xp3bvv71e77+9K++/ve+/ve+/ve+/vWrvv71a77+977+977+9e2F677+9
77+977+9Xu+/ve+/vWjvv73vv73grovvv71u77+977+977+9Ke+/vXto77+9GO+/ve+/ve+/vRzv
v73Yp++/vder77+9K2jvv70obe+/ve+/ve+/ve+/ve+/vVrvv73vv70falka77+9d++/ve+/vcel
cmfvv715JO+/ve+/ve+/vU944bidA27vv71tHWrvv73vv71e77+977+9atqm77+977+977+9x6vv
v73vv73vv73vv714Je+/ve+/vVbvv73vv71peu+/ve+/vXrvv71i77+977+9LO+/ve+/ve+/vXnv
v70r77+977+93rYbbe+/ve+/ve+/ve+/vSst77+977+9Lu+/vcef77+977+9Hu+/ve+/vX/vv70r
Le+/ve+/vWLvv73Yp37vv73vv71peu+/ve+/vWVyPT0KPgo+Cj4KPiAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gVGhpcyBTRi5OZXQgZW1h
aWwgaXMgc3BvbnNvcmVkIGJ5IHhQTUwsIGEgZ3JvdW5kYnJlYWtpbmcgc2NyaXB0aW5nIGxhbmd1
YWdlCj4gdGhhdCBleHRlbmRzIGFwcGxpY2F0aW9ucyBpbnRvIHdlYiBhbmQgbW9iaWxlIG1lZGlh
LiBBdHRlbmQgdGhlIGxpdmUgd2ViY2FzdAo+IGFuZCBqb2luIHRoZSBwcmltZSBkZXZlbG9wZXIg
Z3JvdXAgYnJlYWtpbmcgaW50byB0aGlzIG5ldyBjb2RpbmcgdGVycml0b3J5IQo+IGh0dHA6Ly9z
ZWwuYXMtdXMuZmFsa2FnLm5ldC9zZWw/Y21kPWxuayZraWQ9MTEwOTQ0JmJpZD0yNDE3MjAmZGF0
PTEyMTY0Mgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Cj4gV3JhcHBlci11c2VyIG1haWxpbmcgbGlzdAo+IFdyYXBwZXItdXNlckBsaXN0cy5zb3VyY2Vm
b3JnZS5uZXQKPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby93
cmFwcGVyLXVzZXIKPgoKCi0tCkV1Z2VuZSBIYXJ0CkNlbGw6IDQ0My02MDQtMjY3OQo=

Re: [Wrapper-user] wont start on boot with gentoo

[Gene <gen...@gm...>]

TGVpZiwKCldoZW4gSSBydW4gIi9ldGMvaW5pdC5kL3Byb2dyYW0gY29uc29sZS9zdGFydC9zdG9w
L3Jlc3RhcnQvc3RhdHVzIgptYW51YWxseSBhZnRlciBsb2dnaW5nIGluIGFzIHJvb3QsIHRoZSBw
cm9ncmFtIHdvcmtzIGNvcnJlY3RseSBhbmQgdGhlCmxvZyBmaWxlcyBhcmUgZ2VuZXJhdGVkIGFz
IGV4cGVjdGVkLiBJIGJlbGlldmUgdGhlIC92YXIvbG9nL21lc3NhZ2VzCmZpbGUgaXMgb25seSB3
cml0dGVuIHRvIGR1cmluZyBib290dXAuIEknbSBzdGlsbCB0cnlpbmcgdG8gZmlndXJlIG91dAp3
aHkgaXQgd29uJ3Qgc3RhcnQgd2hlbiBJIHJlYm9vdC4gSSBkaWRuJ3Qgc3BlY2lmeSBiZWZvcmUg
YnV0IGkgZGlkIGRvCiJyYy11cGRhdGUgYWRkIHByb2dyYW0gZGVmYXVsdCIgdG8gYWRkIHRoZSBp
bml0LmQgc2NyaXB0IHRvIHRoZQpkZWZhdWx0IHJ1bnRpbWUgbGV2ZWwgYXMgc3BlY2lmaWVkIGlu
IHRoZSBnZW50b28gZG9jdW1lbnRhdGlvbi4gU2VlCmh0dHA6Ly93d3cuZ2VudG9vLm9yZy9kb2Mv
ZW4vaGFuZGJvb2svaGFuZGJvb2steDg2LnhtbD9wYXJ0PTImY2hhcD00CmZvciBkZXRhaWxzLgoK
QSBzZWFyY2ggb24gZ29vZ2xlIHJldmVhbGVkIHRoYXQgc29tZW9uZSBtYXkgYmUgYXR0ZW1wdGlu
ZyB0byBjcmVhdGUgYQpnZW50b28gZWJ1aWxkIGZvciB0aGUgc2VydmljZSB3cmFwcGVyLiBIZXJl
IGlzIGEgbGluayB0byBhIHBhdGNoIGZpbGU6Cmh0dHA6Ly9nZW50b29leHBlcmltZW50YWwub3Jn
L3N2bi9qYXZhL2dlbnRvby1qYXZhLWV4cGVyaW1lbnRhbC9kZXYtamF2YS9qYXZhLXNlcnZpY2Ut
d3JhcHBlci9maWxlcy9qYXZhLXNlcnZpY2Utd3JhcHBlci0zLjEuMi1nZW50b28ucGF0Y2gKRG8g
dGhlc2UgY2hhbmdlcyBsb29rIGxpa2UgdGhleSBtaWdodCBhY3R1YWxseSBtYWtlIGEgZGlmZmVy
ZW5jZSBhdApib290IHRpbWU/IEl0IGFscmVhZHkgc2VlbXMgdG8gd29yayBvbmNlIGxvZ2dlZCBp
bi4gRllJIHRoZSBwbGF0Zm9ybQppcyBhbWQ2NCBnZW50b28sIGFuZCBJIGhhdmUgc3VjY2Vzc2Z1
bGx5IGdvdHRlbiB0aGUgbGF0ZXN0IDMuMiB2ZXJzaW9uCndvcmtpbmcgb24gdGhlIG1hY29zeCBw
bGF0Zm9ybSB1c2luZyBhIFN0YXJ0dXBJdGVtLgoKVGhhbmtzIGZvciBhbnkgaGVscCEKR2VuZQoK
T24gMy8xNy8wNiwgTGVpZiBNb3J0ZW5zb24gPGxlaWZAdGFudWtpc29mdHdhcmUuY29tPiB3cm90
ZToKPiBHZW5lLAo+ICAgICBXaGVuIGlzIHRoZSBvdXRwdXQgc2hvd24gaW4gdGhlIG1lc3NhZ2Vz
IGxvZyBmaWxlIGdlbmVyYXRlZC4gIEFyZQo+IHRob3NlIHJ1bnMgZnJvbSB3aGVuIHlvdSByYW4g
Ii9ldGMvaW5pdC5kL3Byb2dyYW0gY29uc29sZSIgYW5kCj4gIi9ldGMvaW5pdC5kL3Byb2dyYW0g
c3RhcnQiIGZyb20gdGhlIGNvbW1hbmQgbGluZSBtYW51YWxseT8KPiAgICAgQXJlIHlvdSBzZWVp
bmcgdGhlIHdyYXBwZXIubG9nIGZpbGUgaW4gdGhvc2UgY2FzZXM/Cj4KPiAgICAgV2hlbiB5b3Ug
cmVib290LCB0aGUgc3lzdGVtIHdpbGwgbGF1bmNoIHRoZSBpbml0IHNjcmlwdHMgYXMgcm9vdAo+
IHNvIGl0IGlzIHVubGlrZWx5IHRoYXQgdGhlcmUgd2lsbCBiZSBhbnkgcGVybWlzc2lvbiBwcm9i
bGVtcyB1bmxlc3MgeW91Cj4gaGF2ZSBjb25maWd1cmVkIGEgcnVuIGFzIHVzZXIgaW4gdGhlIHdy
YXBwZXIgc2hlbGwgc2NyaXB0Lgo+Cj4gICAgIFRoZSBvbmx5IHRoaW5nIEkgY2FuIHRoaW5rIG9m
IGF0IHRoZSBtb21lbnQgaXMgdGhlIHJ1biBsZXZlbCBsaW5rcy4KPiBTaW1wbHkgcGxhY2luZyBh
IHNjcmlwdCBpbiB0aGUgaW5pZC5kIGRpcmVjdG9yeSBkb2VzIG5vdCBtZWFuIHRoYXQgdGhlCj4g
c2NyaXB0IHdpbGwgYmUgcnVuIGF0IHN0YXJ0dXAgYW5kIHNodXRkb3duICBZb3Ugc3RpbGwgbmVl
ZCB0byBzZXQgdXAKPiB0aGUgc3lzdGVtIHRvIHJ1biB0aGUgc2NyaXB0IGF0IHRoZSB2YXJpb3Vz
IHN5c3RlbSBydW4gbGV2ZWxzLiAgTm90Cj4gc3VyZSBleGFjdGx5IGhvdyB0aGlzIGlzIGNvbmZp
Z3VyZWQgZm9yIGdlbnRvby4gIFRha2UgYSBsb29rIGF0IHRoZQo+IGZvbGxvd2luZyBwYWdlcyBm
b3IgZXhhbXBsZXMgb24gRGViaWFuIGFuZCBTb2xhcmlzLiAgIElmIHlvdSBmaWd1cmUKPiBvdXQg
dGhlIGNvcnJlY3Qgd2F5IHRvIGRvIHRoaXMgb24gR2VudG9vLCBJJ2QgbG92ZSB0byBzZXQgdXAg
YQo+IEdlbnRvbyBwYWdlIGFzIHdlbGwuCj4gaHR0cDovL3dyYXBwZXIudGFudWtpc29mdHdhcmUu
b3JnL2RvYy9lbmdsaXNoL2xhdW5jaC1uaXguaHRtbCNib290Cj4KPiBDaGVlcnMsCj4gTGVpZgo+
Cj4gR2VuZSB3cm90ZToKPiA+IFJ1bm5pbmcgbXkgcHJvZ3JhbSBmcm9tIGdlbnRvbyBhdCB0aGUg
Y29uc29sZToKPiA+ICAgICAgIC9ldGMvaW5pdC5kL3Byb2dyYW0gc3RhcnQKPiA+IHdvcmtzIGZp
bmUgYnV0IHdoZW4gaSByZWJvb3QgaXQgd2lsbCBub3Qgc3RhcnQsIGl0IHdvbid0IGV2ZW4gZ2Vu
ZXJhdGUKPiA+IHRoZSB3cmFwcGVyLmxvZy4KPiA+IEkndmUgcHV0IGluIHRoZSBmdWxsIHBhdGgg
dG8gamF2YSBpbiB3cmFwcGVyLmNvbmYKPiA+Cj4gPiBUaGlzIGlzIHdoYXQncyBpbiAvdmFyL2xv
Zy9tZXNzYWdlcwo+ID4KPiA+IE1hciAxNyAwMTo1NDoyMSBkYm1hbmFnZXIgREJNQU5BR0VSWzcw
NzddOiAtLT4gV3JhcHBlciBTdGFydGVkIGFzIENvbnNvbGUKPiA+IE1hciAxNyAwMTo1NDoyMSBk
Ym1hbmFnZXIgREJNQU5BR0VSWzcwNzddOiBMYXVuY2hpbmcgYSBKVk0uLi4KPiA+IE1hciAxNyAw
MTo1NDo0OCBkYm1hbmFnZXIgREJNQU5BR0VSWzcwNzddOiBJTlQgdHJhcHBlZC4gIFNodXR0aW5n
IGRvd24uCj4gPiBNYXIgMTcgMDE6NTQ6NDkgZGJtYW5hZ2VyIERCTUFOQUdFUls3MDc3XTogPC0t
IFdyYXBwZXIgU3RvcHBlZAo+ID4gTWFyIDE3IDAxOjU1OjA0IGRibWFuYWdlciBEQk1BTkFHRVJb
NzE4MF06IC0tPiBXcmFwcGVyIFN0YXJ0ZWQgYXMgRGFlbW9uCj4gPiBNYXIgMTcgMDE6NTU6MDQg
ZGJtYW5hZ2VyIERCTUFOQUdFUls3MTgwXTogTGF1bmNoaW5nIGEgSlZNLi4uCj4gPiBNYXIgMTcg
MDE6NTk6MjUgZGJtYW5hZ2VyIERCTUFOQUdFUls3MTgwXTogVEVSTSB0cmFwcGVkLiAgU2h1dHRp
bmcgZG93bi4KPiA+IE1hciAxNyAwMTo1OToyNiBkYm1hbmFnZXIgREJNQU5BR0VSWzcxODBdOiA8
LS0gV3JhcHBlciBTdG9wcGVkCg==

Re: [Wrapper-user] wont start on boot with gentoo

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

Gene,
    When is the output shown in the messages log file generated.  Are
those runs from when you ran "/etc/init.d/program console" and
"/etc/init.d/program start" from the command line manually?
    Are you seeing the wrapper.log file in those cases?

    When you reboot, the system will launch the init scripts as root
so it is unlikely that there will be any permission problems unless you
have configured a run as user in the wrapper shell script.

    The only thing I can think of at the moment is the run level links.
Simply placing a script in the inid.d directory does not mean that the
script will be run at startup and shutdown  You still need to set up
the system to run the script at the various system run levels.  Not
sure exactly how this is configured for gentoo.  Take a look at the
following pages for examples on Debian and Solaris.   If you figure
out the correct way to do this on Gentoo, I'd love to set up a
Gentoo page as well.
http://wrapper.tanukisoftware.org/doc/english/launch-nix.html#boot

Cheers,
Leif

Gene wrote:
> Running my program from gentoo at the console:
> 	/etc/init.d/program start
> works fine but when i reboot it will not start, it won't even generate
> the wrapper.log.
> I've put in the full path to java in wrapper.conf
>
> This is what's in /var/log/messages
>
> Mar 17 01:54:21 dbmanager DBMANAGER[7077]: --> Wrapper Started as Console
> Mar 17 01:54:21 dbmanager DBMANAGER[7077]: Launching a JVM...
> Mar 17 01:54:48 dbmanager DBMANAGER[7077]: INT trapped.  Shutting down.
> Mar 17 01:54:49 dbmanager DBMANAGER[7077]: <-- Wrapper Stopped
> Mar 17 01:55:04 dbmanager DBMANAGER[7180]: --> Wrapper Started as Daemon
> Mar 17 01:55:04 dbmanager DBMANAGER[7180]: Launching a JVM...
> Mar 17 01:59:25 dbmanager DBMANAGER[7180]: TERM trapped.  Shutting down.
> Mar 17 01:59:26 dbmanager DBMANAGER[7180]: <-- Wrapper Stopped
>
> I'm not a linux expert so I could be just doing something very dumb!
> Thanks for any suggestions.
>
> Gene Hart
> N�HS^�隊X���'���u��<�ڂ�.���y�"��*m�x%jx.j���^�קvƩ�X�jب�ȧ��m�ݚ���v&��קv�^�+����j�Z���{az���^��h��஋�n���)�{h�����ا�׫�+h�(m�����Z��jY�w��ǥrg�y$���Oxḝn�mj��^��jڦ���ǫ����x%��V��iz��z�b��,���y�+��޶m����+-��.�ǟ�����+-��b�ا~��iz��er==

[Wrapper-user] wont start on boot with gentoo

[Gene <gen...@gm...>]

UnVubmluZyBteSBwcm9ncmFtIGZyb20gZ2VudG9vIGF0IHRoZSBjb25zb2xlOgoJL2V0Yy9pbml0
LmQvcHJvZ3JhbSBzdGFydAp3b3JrcyBmaW5lIGJ1dCB3aGVuIGkgcmVib290IGl0IHdpbGwgbm90
IHN0YXJ0LCBpdCB3b24ndCBldmVuIGdlbmVyYXRlCnRoZSB3cmFwcGVyLmxvZy4KSSd2ZSBwdXQg
aW4gdGhlIGZ1bGwgcGF0aCB0byBqYXZhIGluIHdyYXBwZXIuY29uZgoKVGhpcyBpcyB3aGF0J3Mg
aW4gL3Zhci9sb2cvbWVzc2FnZXMKCk1hciAxNyAwMTo1NDoyMSBkYm1hbmFnZXIgREJNQU5BR0VS
WzcwNzddOiAtLT4gV3JhcHBlciBTdGFydGVkIGFzIENvbnNvbGUKTWFyIDE3IDAxOjU0OjIxIGRi
bWFuYWdlciBEQk1BTkFHRVJbNzA3N106IExhdW5jaGluZyBhIEpWTS4uLgpNYXIgMTcgMDE6NTQ6
NDggZGJtYW5hZ2VyIERCTUFOQUdFUls3MDc3XTogSU5UIHRyYXBwZWQuICBTaHV0dGluZyBkb3du
LgpNYXIgMTcgMDE6NTQ6NDkgZGJtYW5hZ2VyIERCTUFOQUdFUls3MDc3XTogPC0tIFdyYXBwZXIg
U3RvcHBlZApNYXIgMTcgMDE6NTU6MDQgZGJtYW5hZ2VyIERCTUFOQUdFUls3MTgwXTogLS0+IFdy
YXBwZXIgU3RhcnRlZCBhcyBEYWVtb24KTWFyIDE3IDAxOjU1OjA0IGRibWFuYWdlciBEQk1BTkFH
RVJbNzE4MF06IExhdW5jaGluZyBhIEpWTS4uLgpNYXIgMTcgMDE6NTk6MjUgZGJtYW5hZ2VyIERC
TUFOQUdFUls3MTgwXTogVEVSTSB0cmFwcGVkLiAgU2h1dHRpbmcgZG93bi4KTWFyIDE3IDAxOjU5
OjI2IGRibWFuYWdlciBEQk1BTkFHRVJbNzE4MF06IDwtLSBXcmFwcGVyIFN0b3BwZWQKCkknbSBu
b3QgYSBsaW51eCBleHBlcnQgc28gSSBjb3VsZCBiZSBqdXN0IGRvaW5nIHNvbWV0aGluZyB2ZXJ5
IGR1bWIhClRoYW5rcyBmb3IgYW55IHN1Z2dlc3Rpb25zLgoKR2VuZSBIYXJ0Cg==

Re: [Wrapper-user] Problem loading wrapper.dll

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

David,
    I just retested it with 1.5.0_03 and it works fine for me.
    Try running it with the wrapper.debug=true property set.  This will 
show a little
more information about the reason the library could not be loaded.

    Is it the exact same installation as you are using with Java 1.4?  
There have been
a couple times in the past where users were having problems due to corrupted
files.  Doesn't sound like that is the case with you.

    I've only released the 32-bit wrapper for Windows and you are running a
32-bit JVM, so that's not the problem.

Cheers,
Leif

David R Robison wrote:
> When I run my service in a command line mode, I get the following error:
>
> INFO   | jvm 1    | 2006/03/16 13:17:11 | WARNING - Unable to load the 
> Wrapper's native library 'wrapper.dll'.
> INFO   | jvm 1    | 2006/03/16 13:17:11 |           The file is 
> located on the path at the following location but
> INFO   | jvm 1    | 2006/03/16 13:17:11 |           could not be loaded:
> INFO   | jvm 1    | 2006/03/16 13:17:11 |             
> C:\Workspaces\VICADS\VICADS-Security\bin\..\lib\wrapper.dll
> INFO   | jvm 1    | 2006/03/16 13:17:11 |           Please verify that 
> the file is readable by the current user
> INFO   | jvm 1    | 2006/03/16 13:17:11 |           and that the file 
> has not been corrupted in any way.
> INFO   | jvm 1    | 2006/03/16 13:17:11 |           One common cause 
> of this problem is running a 32-bit version
> INFO   | jvm 1    | 2006/03/16 13:17:11 |           of the Wrapper 
> with a 64-bit version of Java, or vica versa.
> INFO   | jvm 1    | 2006/03/16 13:17:11 |           This is a 32-bit JVM.
> INFO   | jvm 1    | 2006/03/16 13:17:11 |           System signals 
> will not be handled correctly.
>
> I get this when I run with Java 5. Running with Java 4 does not give 
> me this error. I've downloaded and installed the latest version of 
> wrapper. Any thoughts?
>
> David Robison
>

[Wrapper-user] Problem loading wrapper.dll

[David R R. <drr...@op...>]

When I run my service in a command line mode, I get the following error:

INFO   | jvm 1    | 2006/03/16 13:17:11 | WARNING - Unable to load the 
Wrapper's native library 'wrapper.dll'.
INFO   | jvm 1    | 2006/03/16 13:17:11 |           The file is located 
on the path at the following location but
INFO   | jvm 1    | 2006/03/16 13:17:11 |           could not be loaded:
INFO   | jvm 1    | 2006/03/16 13:17:11 |             
C:\Workspaces\VICADS\VICADS-Security\bin\..\lib\wrapper.dll
INFO   | jvm 1    | 2006/03/16 13:17:11 |           Please verify that 
the file is readable by the current user
INFO   | jvm 1    | 2006/03/16 13:17:11 |           and that the file 
has not been corrupted in any way.
INFO   | jvm 1    | 2006/03/16 13:17:11 |           One common cause of 
this problem is running a 32-bit version
INFO   | jvm 1    | 2006/03/16 13:17:11 |           of the Wrapper with 
a 64-bit version of Java, or vica versa.
INFO   | jvm 1    | 2006/03/16 13:17:11 |           This is a 32-bit JVM.
INFO   | jvm 1    | 2006/03/16 13:17:11 |           System signals will 
not be handled correctly.

I get this when I run with Java 5. Running with Java 4 does not give me 
this error. I've downloaded and installed the latest version of wrapper. 
Any thoughts?

David Robison

-- 

David R Robison
Open Roads Consulting, Inc.
708 S. Battlefield Blvd., Chesapeake, VA 23322
phone: (757) 546-3401
e-mail: drr...@op...
web: http://openroadsconsulting.com
blog: http://therobe.blogspot.com
book: http://www.xulonpress.com/bookstore/titles/1597816523.htm

 

[Wrapper-user] 3.2.0 Bug in batch files

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

Hi all,
A user just posted a fairly significant bug that he located in version
3.2.0.
The new batch files will not work correctly if they are located on a
path which
contains spaces. Ie. Under the Program Files directory.

If you attempt to do so, you will see output like the following:

12:55:51.53 C:\Program Files\myapp>bin\MyApp.bat
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
Unable to locate a Wrapper executable using any of the following names:
C:\Program Files\myapp\bin\wrapper-windows-x86-32.exe
C:\Program Files\myapp\bin\wrapper-windows-x86-64.exe
C:\Program Files\myapp\bin\wrapper.exe
Press any key to continue . . .

This is being caused by a simple lack of quotes in the batch files.
The fix will be in a 3.2.1 version. In the mean time, use the new set
of files in the attached zip file. The archive name has been renamed
to avoid problems with some mail filters.

Cheers,
Leif

Re: [Wrapper-user] Wrapper 3.2.0 Release

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

David,
    Thanks for pointing this out.  The site has been corrected.

Cheers,
Leif

da...@sm... wrote:
> Leif, you are lord of all things Java serviced!
>
> Another properties page, but this one is slightly wrong:
>
> http://wrapper.tanukisoftware.org/doc/english/prop-ntservice-password.html#prompt 
>
>
> It says that the command prompt will look like this:
>
> XXXX
>
> And what appears is just the setting for the property, not what would be
> displayed (infact it is a duplicate of the information just above it).
>
> Can't wait to get my hands dirty again!
>
> Many thanks,
>
> David Hayes

Re: [Wrapper-user] Wrapper 3.2.0 Release

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

Juergen,
    Thanks for pointing this out.  I had written the page, but it was 
not included in the
Cocoon config file and wasn't getting generated.  I'll update the site 
later today.

    Cheers,
    Leif

Juergen Hermann wrote:
> On Tue, 14 Mar 2006 13:35:00 +0900, Leif Mortenson wrote:
>
>   
>> The web site has also been updated to reflect the features of the 3.2.0
>> release. There are a few areas such as the delta-pack and java security
>> model which are not yet documented. 
>>     
>
> http://wrapper.tanukisoftware.org/doc/english/prop-lockfile.html
>
> is also missing, in case you missed that.
>
>
>
> Ciao, Jürgen
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>   

Re: [Wrapper-user] Wrapper 3.2.0 Release

[<da...@sm...>]

Leif, you are lord of all things Java serviced!

Another properties page, but this one is slightly wrong:

http://wrapper.tanukisoftware.org/doc/english/prop-ntservice-password.html#prompt

It says that the command prompt will look like this:

XXXX

And what appears is just the setting for the property, not what would be
displayed (infact it is a duplicate of the information just above it).

Can't wait to get my hands dirty again!

Many thanks,

David Hayes

Re: [Wrapper-user] Wrapper 3.2.0 Release

[Juergen H. <jh...@we...>]

On=20Tue,=2014=20Mar=202006=2013:35:00=20+0900,=20Leif=20Mortenson=20wrote=
:

>The=20web=20site=20has=20also=20been=20updated=20to=20reflect=20the=20fea=
tures=20of=20the=203.2.0
>release.=20There=20are=20a=20few=20areas=20such=20as=20the=20delta-pack=20=
and=20java=20security
>model=20which=20are=20not=20yet=20documented.=20

http://wrapper.tanukisoftware.org/doc/english/prop-lockfile.html

is=20also=20missing,=20in=20case=20you=20missed=20that.



Ciao,=20J=FCrgen

Re: [Wrapper-user] Wrapper 3.2.0 Release

[Andy P. <an...@po...>]

Great work, much appreciated - thanks again.

Andy

On 14 Mar 2006, at 04:35, Leif Mortenson wrote:

> Hello all,
> I was finally able to get the long awaited 3.2.0 release of the  
> Java Service
> Wrapper out the door. There are a few platforms missing from this  
> release
> which had been in the 3.1.2 release, but I am hoping to be able to  
> fill
> them in
> over the next few weeks. There were also several additions.
>
> This release will support a new "delta-pack" version which contains  
> the
> binaries of all releases. It will be released in a month or so once  
> the
> above
> missing packages have been filled in.
>
> There have been a very large number of changes in this release. Please
> take a look at the release notes for a full list:
> http://wrapper.tanukisoftware.org/doc/english/release-notes.html
>
> In addition to the wrapper_src and wrapper_src_with_doc_src  
> distributions,
> there is now an additional wrapper_prerelease distribution which is  
> used by
> people wishing to create a wrapper release distribution for an as yet
> unreleased platform. This has the benefit over being built from  
> source that
> everything other than the c binaries will be identical for all  
> releases.
> Try running "./build32.sh release" or "./build64.sh release" as  
> appropriate.
> If a makefile does not yet exist for the platform, the build will  
> report the
> expected platform name. An appropriate makefile can then be added  
> to the
> src/c directory before rerunning the build.
>
> The web site has also been updated to reflect the features of the  
> 3.2.0
> release. There are a few areas such as the delta-pack and java  
> security
> model which are not yet documented. I will try to get those filled  
> in over
> the coming weeks.
> http://wrapper.tanukisoftware.org/doc/english/introduction.html
>
> As always, a lot of work has gone into getting this version of the  
> Wrapper
> together and ready for a release. Please consider support its ongoing
> development:
> http://wrapper.tanukisoftware.org/doc/english/donate.html
>
> Post back if there are any questions.
> Enjoy
>
> Cheers,
> Leif
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] Wrapper 3.2.0 Release

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

Hello all,
I was finally able to get the long awaited 3.2.0 release of the Java Service
Wrapper out the door. There are a few platforms missing from this release
which had been in the 3.1.2 release, but I am hoping to be able to fill
them in
over the next few weeks. There were also several additions.

This release will support a new "delta-pack" version which contains the
binaries of all releases. It will be released in a month or so once the
above
missing packages have been filled in.

There have been a very large number of changes in this release. Please
take a look at the release notes for a full list:
http://wrapper.tanukisoftware.org/doc/english/release-notes.html

In addition to the wrapper_src and wrapper_src_with_doc_src distributions,
there is now an additional wrapper_prerelease distribution which is used by
people wishing to create a wrapper release distribution for an as yet
unreleased platform. This has the benefit over being built from source that
everything other than the c binaries will be identical for all releases.
Try running "./build32.sh release" or "./build64.sh release" as appropriate.
If a makefile does not yet exist for the platform, the build will report the
expected platform name. An appropriate makefile can then be added to the
src/c directory before rerunning the build.

The web site has also been updated to reflect the features of the 3.2.0
release. There are a few areas such as the delta-pack and java security
model which are not yet documented. I will try to get those filled in over
the coming weeks.
http://wrapper.tanukisoftware.org/doc/english/introduction.html

As always, a lot of work has gone into getting this version of the Wrapper
together and ready for a release. Please consider support its ongoing
development:
http://wrapper.tanukisoftware.org/doc/english/donate.html

Post back if there are any questions.
Enjoy

Cheers,
Leif

RE: [Wrapper-user] SUSE 9 on 64bit zSeries machine

[Andreas W. <And...@ag...>]

Hi David,=20

the ceil function is normally in the math library.
You should add it to the linker line in the proper makefile:

$(COMPILE) -lm ...

Hope it helps,
Andreas

-----Original Message-----
From: wra...@li... =
[mailto:wra...@li...] On Behalf Of =
da...@sm...
Sent: Donnerstag, 9. M=E4rz 2006 15:30
To: wra...@li...
Subject: [Wrapper-user] SUSE 9 on 64bit zSeries machine

I am wanting to deploy an app onto a 64bit zSeries IBM machine, running =
SUSE 9.
The standard build files expectedly don't work, and when I try to run =
the build.sh, I get the following build errors.

/tmp/ccgjLbxa.o(.text+0x4ce): In function =
`wrapperStartPendingSignalled':
: undefined reference to `ceil'
/tmp/ccgjLbxa.o(.text+0x528): In function =
`wrapperStartPendingSignalled':
: undefined reference to `ceil'
/tmp/ccgjLbxa.o(.text+0x5fa): In function `wrapperStopPendingSignalled':
: undefined reference to `ceil'
/tmp/ccgjLbxa.o(.text+0x50b6): In function `wrapperProtocolRead':
: undefined reference to `ceil'
/tmp/ccgjLbxa.o(.text+0x5144): In function `wrapperProtocolRead':
: undefined reference to `ceil'

I know that Leif, you don't have direct access to this kind of =
architecture, but you can sign up for a 30 day free access (and not the =
kind where you
have to cancel your subscription or you are charged extortionately) at =
http://www-03.ibm.com/servers/enable/site/testdrive/zseries/

This is the system I am currently trying to install against, to later =
install onto a real local zSeries.

Many thanks for any help anybody can provide,

David Hayes


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting =
language that extends applications into web and mobile media. Attend the =
live
webcast and join the prime developer group breaking into this new coding =
territory!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D=
121642
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

[Wrapper-user] SUSE 9 on 64bit zSeries machine

[<da...@sm...>]

I am wanting to deploy an app onto a 64bit zSeries IBM machine, running SUSE 9.
The standard build files expectedly don't work, and when I try to run the
build.sh, I get the following build errors.

/tmp/ccgjLbxa.o(.text+0x4ce): In function `wrapperStartPendingSignalled':
: undefined reference to `ceil'
/tmp/ccgjLbxa.o(.text+0x528): In function `wrapperStartPendingSignalled':
: undefined reference to `ceil'
/tmp/ccgjLbxa.o(.text+0x5fa): In function `wrapperStopPendingSignalled':
: undefined reference to `ceil'
/tmp/ccgjLbxa.o(.text+0x50b6): In function `wrapperProtocolRead':
: undefined reference to `ceil'
/tmp/ccgjLbxa.o(.text+0x5144): In function `wrapperProtocolRead':
: undefined reference to `ceil'

I know that Leif, you don't have direct access to this kind of architecture, but
you can sign up for a 30 day free access (and not the kind where you have to
cancel your subscription or you are charged extortionately) at
http://www-03.ibm.com/servers/enable/site/testdrive/zseries/

This is the system I am currently trying to install against, to later install
onto a real local zSeries.

Many thanks for any help anybody can provide,

David Hayes

Re: [Wrapper-user] Unable use wrapper linux in RHEL 4

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

Cyrene,
Once again, the documentation is a great place to start.
http://wrapper.tanukisoftware.org/doc/english/launch-nix.html

There is not a specific description for how to do this with RedHat.  But the
final registration of run levels is standard for that platform.

Cheers,
Leif

Cyrene Law wrote:
> Hi Leif,
>
> Yup, i has been succeessfully make the wrapper auto start the service 
> in windows.But i have no idea to make it auto start in Linux 
> especially in RHEL4.
>
> Can you give me guideline to do so?
>
> Regards,
> Cyrene
>
> On 3/9/06, *Leif Mortenson* <le...@ta... 
> <mailto:le...@ta...>> wrote:
>
>     Cyrene,
>         Yes the wrapper can do that.  See this page:
>     http://wrapper.tanukisoftware.org/doc/english/launch-win.html#service
>
>     Cheers,
>     Leif
>
>     Cyrene Law wrote:
>     > Leif,
>     >
>     > thanks,problem is fixed when i change my class  to public class. Any
>     > solution to make this service auto start when computer start?
>     >
>     >
>     > Regards.
>     > cyrene
>     >
>     > On 3/8/06, *Leif Mortenson* <le...@ta...
>     <mailto:le...@ta...>
>     > <mailto:le...@ta...
>     <mailto:le...@ta...>>> wrote:
>     >
>     >     Cyrene,
>     >         Your main method is correct, but the testfile class is
>     not public.
>     >     Change
>     >     class testfile {
>     >     to
>     >     public class testfile{
>     >
>     >         I was able to reproduce this with a class in the root
>     package
>     >     as you
>     >     are doing, but
>     >     it appears to work fine as a public class even if the public
>     token is
>     >     omitted when the
>     >     class is located in a package...  That seems wrong.
>     >         If I attempt to run the class from java directly then it
>     works in
>     >     both cases... Anyone
>     >     know about any documentation where this is described.
>     >
>     >     Cheers,
>     >     Leif
>     >
>     >     Cyrene Law wrote:
>     >     > Hi Leif,
>     >     >
>     >     > Thanks for your reply.Below is my testfile.java.I jar up the
>     >     testfile
>     >     > and try to learn use Java Service Wrapper.
>     >     >
>     >     > ======================================
>     >     > import java.util.*;
>     >     > import java.io.*;
>     >     >
>     >     >
>     >     > class testfile{
>     >     >     public static void main(String args[]){
>     >     >         System.out.println("testing test file");
>     >     >         Calendar cal = new GregorianCalendar();
>     >     >
>     >     >     // Get the components of the date
>     >     >     int era = cal.get(Calendar.ERA);               //
>     0=BC, 1=AD
>     >     >     int year = cal.get(Calendar.YEAR);             // 2002
>     >     >     int month = cal.get(Calendar.MONTH);           // 0=Jan,
>     >     1=Feb, ...
>     >     >     int day = cal.get(Calendar.DAY_OF_MONTH);      // 1...
>     >     >     int dayOfWeek = cal.get (Calendar.DAY_OF_WEEK); //
>     1=Sunday,
>     >     2=Monday,
>     >     >
>     >     >         try {
>     >     >         File file = new File("cyrene.txt");
>     >     >
>     >     >         // Create file if it does not exist
>     >     >         boolean success = file.createNewFile();
>     >     >         if (success) {
>     >     >             // File did not exist and was created
>     >     >             int hour12 = cal.get
>     (Calendar.HOUR);            // 0..11
>     >     >     int hour24 = cal.get( Calendar.HOUR_OF_DAY);     // 0..23
>     >     >     int min = cal.get(Calendar.MINUTE);             // 0..59
>     >     >     int sec = cal.get(Calendar.SECOND);             // 0..59
>     >     >     int ms = cal.get(Calendar.MILLISECOND );         // 0..999
>     >     >     int ampm = cal.get(Calendar.AM_PM);             //
>     0=AM, 1=PM
>     >     >         String ts=
>     Integer.toString(day)+"/"+Integer.toString(month)+
>     >     >         "/"+Integer.toString(year)+"
>     "+Integer.toString(hour12)+
>     >     >         ":"+Integer.toString(min)+":"+Integer.toString(sec);
>     >     >         Writer output = null;
>     >     >     try {
>     >     >       //use buffering
>     >     >       //FileWriter always assumes default encoding is OK!
>     >     >       output = new BufferedWriter( new FileWriter(file) );
>     >     >       output.write( ts );
>     >     >     }
>     >     >     finally {
>     >     >       //flush and close both "output" and its underlying
>     FileWriter
>     >     >       if (output != null) output.close();
>     >     >     }
>     >     >         } else {
>     >     >             // File already exists
>     >     >         }
>     >     >     } catch (IOException e) {
>     >     >     }
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >     }
>     >     > }
>     >     > ======================================
>     >     >
>     >     > I don't know how to use Method 3.So i use method 1.I
>     >     successfully use
>     >     > Method 1 in Windows XP.I really got problem use wrapper in
>     RHEL 4.
>     >     > Here i also enclose my wrapper.zip as your reference about my
>     >     setting.
>     >     >
>     >     > Yours sincerely,
>     >     > Cyrene
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > On 3/8/06, *Leif Mortenson* < le...@ta...
>     <mailto:le...@ta...>
>     >     <mailto:le...@ta...
>     <mailto:le...@ta...>>
>     >     > <mailto: le...@ta...
>     <mailto:le...@ta...>
>     >     <mailto:le...@ta...
>     <mailto:le...@ta...>>>> wrote:
>     >     >
>     >     >     Cyrene,
>     >     >         It looks like you are setting everything up on the
>     >     Wrapper side
>     >     >     correctly.  But
>     >     >     I am guessing that the problem is with your testfile
>     >     class.  Does
>     >     >     it have a
>     >     >     public static main method?  The error is saying that the
>     >     class is
>     >     >     found
>     >     >     and loaded
>     >     >     but that the main method could not be found.
>     >     >
>     >     >     Cheers,
>     >     >     Leif
>     >     >
>     >     >     Cyrene Law wrote:
>     >     >     > i downloaded the wrapper_linux_3.1.2, i create a jar
>     file
>     >     named
>     >     >     > testfile.jar and put it into 'lib' folder which contain
>     >     wrapper.jar
>     >     >     > and libwrapper.so.I also make the testfile.jar as
>     execute
>     >     (chmod +x)
>     >     >     >
>     >     >     > Then i copy the sh.script.in <http://sh.script.in>
>     <http://sh.script.in>
>     >     <http://sh.script.in>
>     >     >     <http://sh.script.in <http://sh.script.in>
>     <http://sh.script.in
>     >     <http://sh.script.in>>> into the  'bin'
>     >     >     > folder, and named it as 'testfile' and chmod +x for
>     >     'testfile'.I
>     >     >     only
>     >     >     > edit the
>     >     >     > APP_Name="testfile"
>     >     >     > APP_LONG_NAME="my testfile"
>     >     >     >
>     >     >     > Then i copy the ' wrapper.conf.in
>     <http://wrapper.conf.in> <http://wrapper.conf.in>
>     >     <http://wrapper.conf.in <http://wrapper.conf.in>>
>     >     >     < http://wrapper.conf.in>' to 'conf'
>     >     >     > folder and rename it as.I add:
>     >     >     > wrapper.java.classpath.2=../lib/testfile.jar
>     >     >     > wrapper.app.parameter=testfile
>     >     >     >
>     >     >     > (because my main file is testfile.class)
>     >     >     >
>     >     >     > After that,i try to run it:
>     >     >     > ./testfile console
>     >     >     >
>     >     >     > it displays error:
>     >     >     > WrapperSimpleApp:Encountered an error running main:
>     >     >     > java.lang.IlegalAccessException: class
>     >     >     > org.tanukisoftware.wrapper.wrapperSimleApp cannot
>     access a
>     >     member of
>     >     >     > class testfile with modifier 'public static'
>     >     >     >
>     >     >     > if i edit the 'wrapper.conf ' as below:
>     >     >     >
>     wrapper.java.mainclass=org.tanukisoftware.wrapper.test.main
>     >     >     >
>     >     >     > it displays error:
>     >     >     > Exception in thread 'main' java
>     >     >     >
>     >     .lang.NoClassDefFoundError:org/tanukisoftware/wrapper/test/main
>     >     >     >
>     >     >     >
>     >     >     > What steps are wrong during the process?
>     >     >     >
>     >     >     > Can you send me a detail guide and example using
>     java service
>     >     >     > wrapper?Urgently wanted.My email is
>     cyr...@gm... <mailto:cyr...@gm...>
>     >     <mailto:cyr...@gm... <mailto:cyr...@gm...>>
>     >     >     <mailto:cyr...@gm...
>     <mailto:cyr...@gm...> <mailto: cyr...@gm...
>     <mailto:cyr...@gm...>>>
>     >     >     > <mailto: cyr...@gm...
>     <mailto:cyr...@gm...>
>     >     <mailto:cyr...@gm... <mailto:cyr...@gm...>>
>     <mailto: cyr...@gm... <mailto:cyr...@gm...>
>     >     <mailto:cyr...@gm... <mailto:cyr...@gm...>>>>
>     >     >     >
>     >     >     > Thank you in advanced.
>     >     >     >
>     >     >     >
>     >     >
>     >     >
>     >
>     >
>
>

Re: [Wrapper-user] Unable use wrapper linux in RHEL 4

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

Cyrene,
    Yes the wrapper can do that.  See this page:
http://wrapper.tanukisoftware.org/doc/english/launch-win.html#service

Cheers,
Leif

Cyrene Law wrote:
> Leif,
>
> thanks,problem is fixed when i change my class  to public class. Any 
> solution to make this service auto start when computer start?
>
>
> Regards.
> cyrene
>
> On 3/8/06, *Leif Mortenson* <le...@ta... 
> <mailto:le...@ta...>> wrote:
>
>     Cyrene,
>         Your main method is correct, but the testfile class is not public.
>     Change
>     class testfile {
>     to
>     public class testfile{
>
>         I was able to reproduce this with a class in the root package
>     as you
>     are doing, but
>     it appears to work fine as a public class even if the public token is
>     omitted when the
>     class is located in a package...  That seems wrong.
>         If I attempt to run the class from java directly then it works in
>     both cases... Anyone
>     know about any documentation where this is described.
>
>     Cheers,
>     Leif
>
>     Cyrene Law wrote:
>     > Hi Leif,
>     >
>     > Thanks for your reply.Below is my testfile.java.I jar up the
>     testfile
>     > and try to learn use Java Service Wrapper.
>     >
>     > ======================================
>     > import java.util.*;
>     > import java.io.*;
>     >
>     >
>     > class testfile{
>     >     public static void main(String args[]){
>     >         System.out.println("testing test file");
>     >         Calendar cal = new GregorianCalendar();
>     >
>     >     // Get the components of the date
>     >     int era = cal.get(Calendar.ERA);               // 0=BC, 1=AD
>     >     int year = cal.get(Calendar.YEAR);             // 2002
>     >     int month = cal.get(Calendar.MONTH);           // 0=Jan,
>     1=Feb, ...
>     >     int day = cal.get(Calendar.DAY_OF_MONTH);      // 1...
>     >     int dayOfWeek = cal.get(Calendar.DAY_OF_WEEK); // 1=Sunday,
>     2=Monday,
>     >
>     >         try {
>     >         File file = new File("cyrene.txt");
>     >
>     >         // Create file if it does not exist
>     >         boolean success = file.createNewFile();
>     >         if (success) {
>     >             // File did not exist and was created
>     >             int hour12 = cal.get(Calendar.HOUR);            // 0..11
>     >     int hour24 = cal.get( Calendar.HOUR_OF_DAY);     // 0..23
>     >     int min = cal.get(Calendar.MINUTE);             // 0..59
>     >     int sec = cal.get(Calendar.SECOND);             // 0..59
>     >     int ms = cal.get(Calendar.MILLISECOND );         // 0..999
>     >     int ampm = cal.get(Calendar.AM_PM);             // 0=AM, 1=PM
>     >         String ts=Integer.toString(day)+"/"+Integer.toString(month)+
>     >         "/"+Integer.toString(year)+" "+Integer.toString(hour12)+
>     >         ":"+Integer.toString(min)+":"+Integer.toString(sec);
>     >         Writer output = null;
>     >     try {
>     >       //use buffering
>     >       //FileWriter always assumes default encoding is OK!
>     >       output = new BufferedWriter( new FileWriter(file) );
>     >       output.write( ts );
>     >     }
>     >     finally {
>     >       //flush and close both "output" and its underlying FileWriter
>     >       if (output != null) output.close();
>     >     }
>     >         } else {
>     >             // File already exists
>     >         }
>     >     } catch (IOException e) {
>     >     }
>     >
>     >
>     >
>     >
>     >     }
>     > }
>     > ======================================
>     >
>     > I don't know how to use Method 3.So i use method 1.I
>     successfully use
>     > Method 1 in Windows XP.I really got problem use wrapper in RHEL 4.
>     > Here i also enclose my wrapper.zip as your reference about my
>     setting.
>     >
>     > Yours sincerely,
>     > Cyrene
>     >
>     >
>     >
>     >
>     >
>     >
>     > On 3/8/06, *Leif Mortenson* < le...@ta...
>     <mailto:le...@ta...>
>     > <mailto:le...@ta...
>     <mailto:le...@ta...>>> wrote:
>     >
>     >     Cyrene,
>     >         It looks like you are setting everything up on the
>     Wrapper side
>     >     correctly.  But
>     >     I am guessing that the problem is with your testfile
>     class.  Does
>     >     it have a
>     >     public static main method?  The error is saying that the
>     class is
>     >     found
>     >     and loaded
>     >     but that the main method could not be found.
>     >
>     >     Cheers,
>     >     Leif
>     >
>     >     Cyrene Law wrote:
>     >     > i downloaded the wrapper_linux_3.1.2, i create a jar file
>     named
>     >     > testfile.jar and put it into 'lib' folder which contain
>     wrapper.jar
>     >     > and libwrapper.so.I also make the testfile.jar as execute
>     (chmod +x)
>     >     >
>     >     > Then i copy the sh.script.in <http://sh.script.in>
>     <http://sh.script.in>
>     >     <http://sh.script.in <http://sh.script.in
>     <http://sh.script.in>>> into the  'bin'
>     >     > folder, and named it as 'testfile' and chmod +x for
>     'testfile'.I
>     >     only
>     >     > edit the
>     >     > APP_Name="testfile"
>     >     > APP_LONG_NAME="my testfile"
>     >     >
>     >     > Then i copy the ' wrapper.conf.in <http://wrapper.conf.in>
>     <http://wrapper.conf.in>
>     >     < http://wrapper.conf.in>' to 'conf'
>     >     > folder and rename it as.I add:
>     >     > wrapper.java.classpath.2=../lib/testfile.jar
>     >     > wrapper.app.parameter=testfile
>     >     >
>     >     > (because my main file is testfile.class)
>     >     >
>     >     > After that,i try to run it:
>     >     > ./testfile console
>     >     >
>     >     > it displays error:
>     >     > WrapperSimpleApp:Encountered an error running main:
>     >     > java.lang.IlegalAccessException: class
>     >     > org.tanukisoftware.wrapper.wrapperSimleApp cannot access a
>     member of
>     >     > class testfile with modifier 'public static'
>     >     >
>     >     > if i edit the 'wrapper.conf ' as below:
>     >     > wrapper.java.mainclass=org.tanukisoftware.wrapper.test.main
>     >     >
>     >     > it displays error:
>     >     > Exception in thread 'main' java
>     >     >
>     .lang.NoClassDefFoundError:org/tanukisoftware/wrapper/test/main
>     >     >
>     >     >
>     >     > What steps are wrong during the process?
>     >     >
>     >     > Can you send me a detail guide and example using java service
>     >     > wrapper?Urgently wanted.My email is cyr...@gm...
>     <mailto:cyr...@gm...>
>     >     <mailto:cyr...@gm... <mailto:cyr...@gm...>>
>     >     > <mailto: cyr...@gm...
>     <mailto:cyr...@gm...> <mailto:cyr...@gm...
>     <mailto:cyr...@gm...>>>
>     >     >
>     >     > Thank you in advanced.
>     >     >
>     >     >
>     >
>     >
>
>

Re: [Wrapper-user] Linux daemon question

[Anat H. <an...@en...>]

Hi again,

I didn't get any reply to my last question, so I'm gonna nag again:
Is there any way I can avoid disconnecting the GUI, and still have the 
service functioning on Linux?
Any idea is welcome.

Thanks,
Anat

Anat Halpern wrote:
> Hi Leif,
> It seems you were right - the window is causing this :-(
> I'm attaching 2 log files - one is with a hidden window, and one wo 
> GUI. The first shuts down on logout, while the second continues.
>
> Leif Mortenson wrote:
>> Anat,
>>> The process terminates when I logout, or at least that's how it 
>>> seems. I know the wrapper is not shutting it down, however I thought 
>>> the wrapper is supposed to intercept those signals so that the JVM 
>>> doesn't get them.
>> The Wrapper is capable of catching and handling many signals, but the 
>> JVM
>> is a separate child process of the Wrapper.  If it receives a kill 
>> -9, there is not
>> anything that can be done about it.  At that point, the os is killing 
>> the process
>> at a very low level.  This is true on Windows as well if the user 
>> kills the java
>> process from the task manager.  Processes in both platforms are 
>> protected
>> by user privileges.  But if the user has the privilege to kill the 
>> process, it goes
>> bye bye.
>>> I think the wrapper wouldn't be able to restart the application for 
>>> other reasons as well, but in any case restarting is not the 
>>> solution for this problem.
>> I agree, the reason for the restart not working makes sense in your 
>> case.
>> The question is, who is killing the initial java process?
>>> The original invocation also had a window, but hidden. I am checking 
>>> whether running in service mode, and if so I have the window hidden. 
>>> This is currently easier for me to do than to disentangle the GUI 
>>> code from the application. I plan to separate them, but I hope it 
>>> will not be necessary to do it now. Please let me know if it is...
>> I wonder if the JVM is creating some hooks into the window manager 
>> simply
>> by allocating the resources for a window, even if that window is not 
>> being
>> displayed?
>>
>> Could you create a simple headless application and try this out on your
>> machine?  I would like to find out if this is being caused by hidden 
>> GUI.
>>
> so I'd have to disconnect the GUI, or do you have some other solution 
> in mind?
>> I'll try this out on my home linux machine over the weekend.  I only 
>> have
>> access to remote systems today.
>>
>> Cheers,
>> Leif
>>
> Thanks,
> Anat
>
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.