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

[Wrapper-user] patch (3/4) -- don't catch signals in JNI

[Robey P. <ro...@da...>]

3rd patch of 4.  This one is a little rough.  Basically, under high  
load, catching signals inside JNI causes the JVM to crash, at least  
on Linux.  Crashing the JVM is really bad, and basically a non- 
recoverable error for any java code.

Since signals are caught by the wrapper process and passed to the JVM  
across a control channel, there is no reason for JNI code to try to  
handle signals anyway, so we just uncommented this code.  This may  
need more discussion: What is this code meant to be used for?

In general, my experience has been that the JVM tends to use signals  
for its own purposes, so trying to catch signals in the JVM is bad  
medicine.  This is especially true for things like HUP, USR1, and USR2.

robey

[Wrapper-user] patch (2/4) -- link with -m on linux

[Robey P. <ro...@da...>]

Here's the 2nd patch; it's a trivial patch that just adds "-m" to the  
link line on Linux.  Recent versions of Linux (Debian and Ubuntu, at  
minimum) don't automatically link with libm, so you have to add it  
explicitly if you want the math functions.

robey

[Wrapper-user] patch (1/4) -- use local ant

[Robey P. <ro...@da...>]

Hi there!

We've been using wrapper at Danger for about a year now, and recently  
upgraded to version 3.2.3.  We have a few patches that we apply, and  
with the last upgrade we had to modify those patches a lot, so I'm  
hoping to get most or all of them pushed upstream in some fashion.

This first patch is pretty straightforward.  The build scripts  
currently don't always pick up the local copy of 'ant' on systems  
that install an old 'ant' in the system path.  This makes sure they  
do, and that 'ant' doesn't pick up its configuration from the system  
copy either.

robey

Re: [Wrapper-user] Problems with Win 2003 Server

[Bernd L. <Ber...@we...>]

Bernd Laengerich wrote:

> - whenever a user logs out, the JVM exits unexpectedly
> - whenever the service is requested to stop, the JVM crashes

Sorry to bother the mailing list, it seems that one dll loaded with 
third party native code installs signal handlers under certain 
circumstances, thus disabling the wrapper to handle the logoff events.

Bernd

[Wrapper-user] Problems with Win 2003 Server

[Bernd L. <Ber...@we...>]

Hi,

I have some problems running an existing application with the service 
wrapper. I used integration method 1 to have a migration path for 
existing user installations.

Everything works fine for me using my W2K development machine. 
However, test installations with Win 2003 Server showed some problems:

- whenever a user logs out, the JVM exits unexpectedly
- whenever the service is requested to stop, the JVM crashes

I have attached a debug log and the hs_err file, any hints?

Currently I am preparing for integration method 3, but this be the 
next release of the software and is still untested with Win2003

Bernd

[Wrapper-user] Classload problems with inner classes. Was Re: Classes unloaded too early on process termination

[Chuck W. <ch...@ma...>]

The problem appears to be worse than described below.  It appears that
certain inner classes are not loaded properly.  I've only seen this
since upgrading to wrapper 3.2.3 from 3.1.2 Does wrapper do something to
affect class loading?  Has anybody else experienced problems accessing
inner classes?

Thanks for any help,

Chuck


Chuck Williams wrote on 10/29/2006 11:19 AM:
> Hi All,
>
> After recently upgrading from wrapper 3.1.2 to 3.2.3 an anomaly has
> developed in my application.  When a normal kill signal is received on
> linux (e.g., control-c when running from console) and
> WrapperListener.stop() is called, occasionally classes are unloaded too
> early, causing subsequent references to those classes in my shutdown
> code to get NoClassDefFoundError.  One time an inner class in my stop()
> method itself got this error!
>
> Can anyone explain or suggest a solution?  Has anyone else seen this?
>
> Thanks for any help,
>
> Chuck
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>   

[Wrapper-user] Classes unloaded too early on process termination

[Chuck W. <ch...@ma...>]

Hi All,

After recently upgrading from wrapper 3.1.2 to 3.2.3 an anomaly has
developed in my application.  When a normal kill signal is received on
linux (e.g., control-c when running from console) and
WrapperListener.stop() is called, occasionally classes are unloaded too
early, causing subsequent references to those classes in my shutdown
code to get NoClassDefFoundError.  One time an inner class in my stop()
method itself got this error!

Can anyone explain or suggest a solution?  Has anyone else seen this?

Thanks for any help,

Chuck

Re: [Wrapper-user] Hi,

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

Tito,
In the future, please post to the wrapper-user mailing list rather than
contacting me directly. Same result, but it makes these comments
available to other users.

All the Wrapepr does is to manage the specific JVM instance that it
itself launches.  If that JVM crashes or hangs, the Wrapper will restart
it.   Shutdowns are the same.

In your case, you are launching child JVMs, this is possible, but you
need to make your main Java application more intelligent about handling
the shutdown of the child JVMs on shutdown as well as recovering after
a restart if any old child JVMs are still left around.   I would do the 
later
by writing a file for each JVM in a known directory.  On startup, you can
iterate over those files to clean up the old JVMs.

Another, simpler, option is to write a unique anchor file into a known
directory then pass that anchor file name to the child JVM.  The child
will then monitor that file.  If it is ever deleted, it knows that it must
shutdown as soon as possible.
The parent JVM will then delete all anchor files on shutdown and startup.
The later is to clean up after a restart.  Simple.

If you want to have each of your child JVMs running under their own
wrapper instance this is also possible.   You can reuse the same
wrapper.exe, but you will want to create new wrapper.conf files for
each instance.  Make sure that they are each given a unique service
name as well.   Your main program can then use the wrapper binary
to install and start those services on startup, then stop and remove
them on shutdown.

Your exact problem was not clear, so I hope this helped.

Cheers,
Leif

Encrypti! wrote:
> Message body follows:
>
> I tried using JSW for one of my project. it is a client
> server  RMI application. in that for every clients server
> will create seperate process ie. seperate JVM. The creation
> is working fine(I am creating using a .bat file which is
> called form inside the jar file). and for killing i am using
> another bat file(using MS Kill.exe). That part is not
> working. its because  while using JSW there is no referance
> for that client. Is there another way to do this..
>
> Tito George
>   

Re: [Wrapper-user] HPUX

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

Miguel,
    Try downloading the 3.2.3 prerelease distribution and running the 
following:
./build32.sh release
Or
./build64.sh release

    If you are not using gcc then you may need to modify the makefiles 
in the
src/c directory:
Makefile-hpux-parisc-32
Makefile-hpux-parisc-64

    If you do get them working, I would love it if you contributed the 
resulting
files for the benefit of other users.

Cheers,
Leif

Geoffrey Mitchell wrote:
> Leif no longer has access to an HPUX system on which to build.
>
> If the existing build does not work for you, you will need to build 
> yourself from source. 
>
> Miguel Serrano wrote:
>> All,
>>
>> There are several post about problems with the HPUX ports (gcc 
>> dependencies from the librapper.so)
>>
>> I tried the  wrapper_hpux_3.1.2.tar.gz 
>> <http://prdownloads.sourceforge.net/wrapper/wrapper_hpux_3.1.2.tar.gz?download> 
>> build (the last built for HPUX) and we find the same problem.
>>
>> Is there an expected time for a hpux build that solves this problem>?
>>
>> Miguel

[Wrapper-user] HPUX

[Miguel S. <jav...@ya...>]

All,=0A=0AThere are several post about problems with the HPUX ports (gcc de=
pendencies from the librapper.so)=0A=0AI tried the =0A=09=09=09wrapper_hpux=
_3.1.2.tar.gz build (the last built for HPUX) and we find the same problem.=
=0A=0AIs there an expected time for a hpux build that solves this problem>?=
=0A=0AMiguel=0A=0A=0A=0A

Re: [Wrapper-user] Simple change to remove JAVA warning

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

Bill,
    Thanks for pointing out the javadoc problem.  It has been fixed.

    Also, I love that idea about reducing the ping output.  I 
implemented it a
little differently as a property called wrapper.ping.interval.logged.  
It is an
interval in seconds.  So if you have a ping interval of 5 seconds and you
set it to 60, you will only see a logged ping message once every minute,
or every 12 actual pings.
    I did it this way to avoid forcing the user to do any extra math.

    These changes will be in the next release.

    Cheers,
    Leif

Bill Edens wrote:
> Leif:
>  
> I have been making the following simple change in the source set since 
> 3.2.1 to get rid of a javadoc error message when using JAVA5 for 
> building the release.  FYI
>
>     *** ./src/java/org/tanukisoftware/wrapper/WrapperSimpleApp.java
>     Mon Oct 16 17:24:01 2006
>     ---
>     ../wrapper_3.2.3.1_src/./src/java/org/tanukisoftware/wrapper/WrapperSimpleApp.java 
>     Tue Oct 17 23:21:14 2006
>     ***************
>     *** 124,130 ****
>           /**
>            * Creates an instance of a WrapperSimpleApp.
>            *
>     !      * @param args The full list of arguments passed to the JVM.
>            */
>           protected WrapperSimpleApp( String args[] )
>           {
>     --- 124,130 ----
>           /**
>            * Creates an instance of a WrapperSimpleApp.
>            *
>     !      * @param The full list of arguments passed to the JVM.
>            */
>           protected WrapperSimpleApp( String args[] )
>           {
>
> I also add the "silent-pings" property to quiet down the ping cycle 
> messages to once every "n" occurances rather than every cycle.  The 
> pings still perform at their original rate.  They are just not as 
> noisy when in DEBUG mode.  See attachment.  The source change is 
> simple.  I can forward if your interested.
>  
> Bill

[Wrapper-user] Simple change to remove JAVA warning

[Bill E. <we...@te...>]

PGh0bWw+DQo8aGVhZD4NCjxNRVRBIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPHRpdGxlPkphdmEgU2VydmljZSBXcmFw
cGVyIC0gd3JhcHBlci5waW5nLnRpbWVvdXQgUHJvcGVydHk8L3RpdGxlPg0KPHN0eWxlIG1lZGlh
PSJhbGwiIHR5cGU9InRleHQvY3NzIj4NCiAgICAgICAgICAgIEBpbXBvcnQgdXJsKCIuL3N0eWxl
L3dyYXBwZXIuY3NzIik7DQogICAgICAgIDwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y
PSIjZWVlZWZmIiBtYXJnaW5oZWlnaHQ9IjAiIG1hcmdpbndpZHRoPSIwIiBsZWZ0bWFyZ2luPSIw
IiB0b3BtYXJnaW49IjAiIGFsaW5rPSIjMDIzMjY0IiB2bGluaz0iIzAyMzI2NCIgbGluaz0iIzUy
NUQ3NiIgdGV4dD0iIzAwMDAwMCI+DQo8bWFwIG5hbWU9IndyYXBwZXJMb2dvIj4NCjxhcmVhIGhy
ZWY9Imh0dHA6Ly93cmFwcGVyLnRhbnVraXNvZnR3YXJlLm9yZyIgY29vcmRzPSI5MCw5MCw4OCIg
c2hhcGU9ImNpcmNsZSI+DQo8L21hcD4NCjxtYXAgbmFtZT0id3JhcHBlclRpdGxlIj4NCjxhcmVh
IGhyZWY9Imh0dHA6Ly93d3cudGFudWtpc29mdHdhcmUuY29tIiBjb29yZHM9IjI4LDMyLDE3Niw0
OCIgc2hhcGU9InJlY3QiPg0KPC9tYXA+DQo8dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj
aW5nPSIwIiB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIj4NCjx0cj4NCjx0ZCB2YWxpZ249InRvcCIg
d2lkdGg9IjE4MCI+DQo8dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0
aD0iMTAwJSIgYm9yZGVyPSIwIj4NCjx0cj4NCjx0ZCB3aWR0aD0iMTgwIj48aW1nIHVzZW1hcD0i
I3dyYXBwZXJMb2dvIiBib3JkZXI9IjAiIGhlaWdodD0iMTgwIiB3aWR0aD0iMTgwIiBzcmM9Imlt
YWdlcy9XcmFwcGVyTG9nby5wbmciPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkPg0KPHRhYmxlIGNl
bGxwYWRkaW5nPSI0IiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9IjEwMCUiIGJvcmRlcj0iMCI+DQo8
dHI+DQo8dGQgbm93cmFwPSJ0cnVlIj4NCjxkaXYgaWQ9Im1lbnUiPg0KPHNjcmlwdCBsYW5ndWFn
ZT0iSmF2YVNjcmlwdCI+Ly9AQE1FTlVfVE9QQEA8L3NjcmlwdD4NCjxkaXY+DQo8Yj5Fc3NlbnRp
YWxzPC9iPg0KPGRpdj4NCjxhIGhyZWY9ImludHJvZHVjdGlvbi5odG1sIj5JbnRyb2R1Y3Rpb248
L2E+DQo8L2Rpdj4NCjxkaXY+DQo8YSBocmVmPSJpbnRlZ3JhdGUuaHRtbCI+SW50ZWdyYXRpb24g
TWV0aG9kczwvYT4NCjwvZGl2Pg0KPGRpdj4NCjxhIGhyZWY9InByb3BlcnRpZXMuaHRtbCI+Q29u
ZmlndXJhdGlvbiBQcm9wZXJ0aWVzPC9hPg0KPC9kaXY+DQo8ZGl2Pg0KPGEgaHJlZj0ibGF1bmNo
Lmh0bWwiPkxhdW5jaGluZyBZb3VyIEFwcGxpY2F0aW9uPC9hPg0KPC9kaXY+DQo8ZGl2Pg0KPGI+
DQogICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAg
ICAgPGEgaHJlZj0iZG9uYXRlLmh0bWwiPlNob3cgWW91ciBTdXBwb3J0PC9hPg0KICAgICAgICAg
ICAgICAgICAgICAgICAgJmx0OyZsdDsNCiAgICAgICAgICAgICAgICAgICAgPC9iPg0KPC9kaXY+
DQo8ZGl2Pg0KPGEgaHJlZj0ic3BvbnNvcnMuaHRtbCI+U3BvbnNvcnM8L2E+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxiPkRvY3VtZW50YXRpb248L2I+DQo8ZGl2Pg0KPGEgaHJlZj0iam14Lmh0
bWwiPkpNWCBDb250cm9sPC9hPg0KPC9kaXY+DQo8ZGl2Pg0KPGEgaHJlZj0iZXhhbXBsZS5odG1s
Ij5GZWF0dXJlIEV4YW1wbGVzPC9hPg0KPC9kaXY+DQo8ZGl2Pg0KPGEgaHJlZj0iZGVidWdnaW5n
Lmh0bWwiPkRlYnVnZ2luZyBZb3VyIEFwcGxpY2F0aW9uPC9hPg0KPC9kaXY+DQo8ZGl2Pg0KPGEg
aHJlZj0idHJvdWJsZXNob290aW5nLmh0bWwiPlRyb3VibGVzaG9vdGluZzwvYT4NCjwvZGl2Pg0K
PGRpdj4NCjxhIGhyZWY9ImZhcS5odG1sIj5GQVE8L2E+DQo8L2Rpdj4NCjxkaXY+DQo8YSBocmVm
PSJyZWxlYXNlLW5vdGVzLmh0bWwiPlJlbGVhc2UgTm90ZXM8L2E+DQo8L2Rpdj4NCjxkaXY+DQo8
YSBocmVmPSJoaXN0b3J5Lmh0bWwiPlByb2plY3QgSGlzdG9yeTwvYT4NCjwvZGl2Pg0KPGRpdj4N
CjxhIGhyZWY9ImphdmFkb2NzLmh0bWwiPkphdmFkb2NzIEFQSTwvYT4NCjwvZGl2Pg0KPGRpdj4N
CjxhIGhyZWY9ImJ1dHRvbnMuaHRtbCI+QnV0dG9uczwvYT4NCjwvZGl2Pg0KPGRpdj4NCjxhIGhy
ZWY9ImF1dGhvcnMuaHRtbCI+QXV0aG9yczwvYT4NCjwvZGl2Pg0KPGRpdj4NCjxhIGhyZWY9Imxp
Y2Vuc2UuaHRtbCI+TGljZW5zZTwvYT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGI+RG93bmxv
YWQ8L2I+DQo8ZGl2Pg0KPGEgaHJlZj0iaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0L3No
b3dmaWxlcy5waHA/Z3JvdXBfaWQ9Mzk0MjgiPkJpbmFyaWVzPC9hPg0KPC9kaXY+DQo8ZGl2Pg0K
PGEgaHJlZj0iaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0L3Nob3dmaWxlcy5waHA/Z3Jv
dXBfaWQ9Mzk0MjgiPlNvdXJjZSBDb2RlPC9hPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8Yj5H
ZXQgSW52b2x2ZWQ8L2I+DQo8ZGl2Pg0KPGEgaHJlZj0iaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9w
cm9qZWN0cy93cmFwcGVyLyI+U291cmNlIEZvcmdlPC9hPg0KPC9kaXY+DQo8ZGl2Pg0KPGEgaHJl
Zj0iaHR0cDovL2N2cy5zb3VyY2Vmb3JnZS5uZXQvY2dpLWJpbi92aWV3Y3ZzLmNnaS93cmFwcGVy
LyI+Q1ZTIFJlcG9zaXRvcnk8L2E+DQo8L2Rpdj4NCjxkaXY+DQo8YSBocmVmPSJodHRwOi8vc291
cmNlZm9yZ2UubmV0L3RyYWNrZXIvP2dyb3VwX2lkPTM5NDI4Ij5Jc3N1ZSBUcmFja2luZzwvYT4N
CjwvZGl2Pg0KPGRpdj4NCjxhIGhyZWY9Imh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbC8/Z3Jv
dXBfaWQ9Mzk0MjgiPk1haWxpbmcgTGlzdHMgYW5kIEFyY2hpdmVzPC9hPg0KPC9kaXY+DQo8ZGl2
Pg0KPGEgaHJlZj0iaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9mb3J1bS8/Z3JvdXBfaWQ9Mzk0Mjgi
PkZvcnVtcyAoT2xkKTwvYT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzY3JpcHQgbGFuZ3Vh
Z2U9IkphdmFTY3JpcHQiPi8vQEBNRU5VX0JPVFRPTUBAPC9zY3JpcHQ+DQo8cD4NCjxiPkhvc3Rl
ZCBieTo8L2I+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3Rz
L3dyYXBwZXIvIj48aW1nIGFsdD0iU291cmNlRm9yZ2UiIGJvcmRlcj0iMCIgaGVpZ2h0PSIzMSIg
d2lkdGg9Ijg4IiBzcmM9Imh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvc2Zsb2dvLnBocD9ncm91cF9p
ZD0zOTQyOCI+PC9hPg0KPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5zcHJlYWRmaXJlZm94LmNv
bS8/cT1hZmZpbGlhdGVzJmlkPTQ2MTEmdD03NSI+PGltZyBzcmM9Imh0dHA6Ly93d3cuc3ByZWFk
ZmlyZWZveC5jb20vY29tbXVuaXR5L2ltYWdlcy9hZmZpbGlhdGVzL0J1dHRvbnMvMTIweDYwL3Ry
dXN0LmdpZiIgdGl0bGU9IkdldCBGaXJlZm94ISIgYWx0PSJHZXQgRmlyZWZveCEiIGhlaWdodD0i
NjAiIHdpZHRoPSIxMjAiIGJvcmRlcj0iMCI+PC9hPg0KPC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rh
YmxlPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KPC90ZD48dGQgdmFsaWduPSJ0b3AiIHdpZHRo
PSIqIj4NCjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSIxMDAl
IiBib3JkZXI9IjAiPg0KPHRyPg0KPHRkIGNvbHNwYW49IjMiPjxpbWcgaGVpZ2h0PSI0IiBzcmM9
ImltYWdlcy9zcGFjZXIuZ2lmIj48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBhbGlnbj0iY2VudGVy
IiBoZWlnaHQ9IjkwIiBjb2xzcGFuPSIyIj48YSBocmVmPSJodHRwOi8vd3JhcHBlci50YW51a2lz
b2Z0d2FyZS5vcmciPjxpbWcgYm9yZGVyPSIwIiBoZWlnaHQ9IjkwIiB3aWR0aD0iNzI4IiBzcmM9
ImltYWdlcy9PZmZsaW5lQWQ3Mjh4OTAucG5nIj48L2E+PC90ZD48dGQgcm93c3Bhbj0iNSI+PGlt
ZyB3aWR0aD0iNCIgc3JjPSJpbWFnZXMvc3BhY2VyLmdpZiI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8
dGQgaGVpZ2h0PSI0OSIgd2lkdGg9IjQzNSI+PGltZyB1c2VtYXA9IiN3cmFwcGVyVGl0bGUiIGJv
cmRlcj0iMCIgaGVpZ2h0PSI0OSIgd2lkdGg9IjQzNSIgc3JjPSJpbWFnZXMvV3JhcHBlclRpdGxl
LnBuZyI+PC90ZD48dGQgdmFsaWduPSJib3R0b20iIGFsaWduPSJyaWdodCIgd2lkdGg9IioiPjxh
IGhyZWY9ImRvbmF0ZS5odG1sIj48aW1nIGJvcmRlcj0iMCIgaGVpZ2h0PSIxNiIgd2lkdGg9IjMw
MCIgc3JjPSJpbWFnZXMvRG9uYXRpb25SZXF1ZXN0LnBuZyI+PC9hPjwvdGQ+DQo8L3RyPg0KPHRy
Pg0KPHRkIGhlaWdodD0iNCIgY29sc3Bhbj0iMiI+PGltZyBoZWlnaHQ9IjQiIHdpZHRoPSI1MDAi
IHNyYz0iaW1hZ2VzL0JvcmRlclRvcC5wbmciPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIGNvbHNw
YW49IjIiPg0KPHRhYmxlIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjEw
MCUiIGJvcmRlcj0iMCI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHdpZHRoPSI0Ij48aW1nIGhl
aWdodD0iNDk2IiB3aWR0aD0iNCIgc3JjPSJpbWFnZXMvQm9yZGVyTGVmdC5wbmciPjwvdGQ+PHRk
IGJnY29sb3I9IiNmZmZmZmYiIHZhbGlnbj0idG9wIiB3aWR0aD0iKiIgY29sc3Bhbj0iMiI+DQo8
dGFibGUgY2VsbHBhZGRpbmc9IjQiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iMTAwJSIgYm9yZGVy
PSIwIj4NCjx0cj4NCjx0ZCBub3dyYXA9InRydWUiIGFsaWduPSJjZW50ZXIiPjxmb250IHpjb2xv
cj0iIzExNWI3NyIgY29sb3I9IiM4ODg4YWEiIHNpemU9IjUiPjxiPndyYXBwZXIuc2lsZW50X3Bp
bmdzIFByb3BlcnR5PC9iPjwvZm9udD48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZD4NCjx0aXRsZT53
cmFwcGVyLnBpbmcudGltZW91dCBQcm9wZXJ0eTwvdGl0bGU+DQogICAgDQogICAgDQo8YSBuYW1l
PSJOMTAwMDkiPjwvYT4NCjx0YWJsZSBjZWxscGFkZGluZz0iMiIgY2VsbHNwYWNpbmc9IjAiIHdp
ZHRoPSIxMDAlIiBib3JkZXI9IjAiPg0KPHRyPg0KPHRkIGJnY29sb3I9IiM4ODg4YWEiIGNsYXNz
PSJzZWN0aW9uaGVhZGVyMSIgd2lkdGg9IioiPjxmb250IGNvbG9yPSIjZWVlZWVlIiBzaXplPSI0
Ij48Yj5Db25maWd1cmF0aW9uIFByb3BlcnR5IE92ZXJ2aWV3PC9iPjwvZm9udD48L3RkPg0KPC90
cj4NCjx0cj4NCjx0ZD48aW1nIGhlaWdodD0iNCIgd2lkdGg9IjEiIHNyYz0iLi9pbWFnZXMvc3Bh
Y2VyLmdpZiI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQ+DQogICAgICAgIA0KICAgICAgICANCjx1
bD4NCiAgICAgICAgICAgIA0KPGxpPg0KICAgICAgICAgICAgICAgIA0KPGEgaHJlZj0icHJvcGVy
dGllcy5odG1sIj5Db25maWd1cmF0aW9uIFByb3BlcnR5IE92ZXJ2aWV3PC9hPg0KICAgICAgICAg
ICAgDQo8L2xpPg0KICAgICAgICAgICAgDQo8bGk+DQogICAgICAgICAgICAgICAgDQo8YSBocmVm
PSJwcm9wcy1hZHZhbmNlZC5odG1sIj5BZHZhbmNlZCBQcm9wZXJ0aWVzPC9hPg0KICAgICAgICAg
ICAgDQo8L2xpPg0KICAgICAgICAgICAgDQo8bGk+DQogICAgICAgICAgICAgICAgDQo8YSBocmVm
PSJwcm9wZXJ0aWVzLmh0bWwjbmFtZSI+UHJvcGVydHkgTGlzdCBieSBOYW1lPC9hPg0KICAgICAg
ICAgICAgDQo8L2xpPg0KICAgICAgICANCjwvdWw+DQogICAgDQo8L3RkPg0KPC90cj4NCjwvdGFi
bGU+DQogICAgDQo8YSBuYW1lPSJOMTAwMjciPjwvYT4NCjx0YWJsZSBjZWxscGFkZGluZz0iMiIg
Y2VsbHNwYWNpbmc9IjAiIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiPg0KPHRyPg0KPHRkIGJnY29s
b3I9IiM4ODg4YWEiIGNsYXNzPSJzZWN0aW9uaGVhZGVyMSIgd2lkdGg9IioiPjxmb250IGNvbG9y
PSIjZWVlZWVlIiBzaXplPSI0Ij48Yj53cmFwcGVyLnNpbGVudF9waW5nczwvYj48L2ZvbnQ+PC90
ZD4NCjwvdHI+DQo8dHI+DQo8dGQ+PGltZyBoZWlnaHQ9IjQiIHdpZHRoPSIxIiBzcmM9Ii4vaW1h
Z2VzL3NwYWNlci5naWYiPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkPg0KICAgICAgICANCiAgICAg
ICAgDQo8cD4NCiAgICAgICAgICAgIFdoZW4gdGhlIHdyYXBwZXIgaXMgcnVubmluZyBjb3JyZWN0
bHkgYW5kIGluIHRoZSBERUJVRyBtb2RlLCB0aGVyZSANCgkJCWlzIGEgcGluZyByZXBvcnQgaXNz
dWVkIGV2ZXJ5IHBpbmcuaW50ZXJ2YWwuJm5ic3A7IFRvIHF1aWV0IGRvd24gdGhlIA0KCQkJcmVw
b3J0aW5nIGFuZCByZWR1Y2UgdGhlIGxvZ2dpbmcgbG9hZCwgeW91IGNhbiBzZXQgdGhpcyB0byBz
aWxlbmNlIA0KCQkJYW55IG51bWJlciBvZiBzdWNjZXNzZnVsbCBwaW5ncy4mbmJzcDsgQWxsIG90
aGVyIHJlcG9ydHMgd2lsbCBzdGlsbCANCgkJCWJlIHJlcG9ydGVkLiZuYnNwOyBUaGlzIGlzIHRo
ZSBudW1iZXIgb2YgV3JhcHBlciBwaW5nIHJlcXVlc3RzIHRvIHRoZSBKVk0gDQoJCQl0byBOT1Qg
cmVwb3J0IHRvIHRoZSBvdXRwdXQgdGV4dCBmaWxlLiZuYnNwOyBNdXN0IGJlIGluIHRoZSByYW5n
ZQ0KICAgICAgICAgICAgMSB0byAzNjAwLiBEZWZhdWx0cyB0byAxLiZuYnNwOyBUaGlzIGNhdXNl
cyBldmVyeSBwaW5nIHJlcXVlc3QgdG8gDQoJCQl0aGUgcmVwb3J0ZWQuJm5ic3A7IElmIHRoZSB3
cmFwcGVyLnBpbmcuaW50ZXJ2YWwgaXMgNSBzZWNvbmRzIGFuZCANCgkJCXdyYXBwZXIuc2lsZW50
X3BpbmdzIGlzIHNldCB0byA3MTksIHRoZXJlIHdpbGwgYmUgYSBwaW5nIHJlcG9ydCBvbmNlIA0K
CQkJcGVyIGhvdXIuJm5ic3A7IFBpbmcgcmVwb3J0cyBhcmUgb25seSBsb2dnZWQgd2hlbiB0aGUg
d3JhcHBlciBpcyBpbiANCgkJCXRoZSBERUJVRyBtb2RlLg0KICAgICAgICA8L3A+DQogICAgICAg
IA0KPHA+DQogICAgICAgIA0KPC9wPg0KICAgICAgICANCjx0YWJsZSBjZWxsc3BhY2luZz0iMCIg
Y2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBib3JkZXI9IjAiIGNsYXNzPSJsaXN0aW5nIj4N
Cjx0cj4NCjx0ZCBjbGFzcz0ibGlzdGluZ2NhcHRpb24iPjxpPkV4YW1wbGU6PC9pPjwvdGQ+DQo8
L3RyPg0KPHRyPg0KPHRkIGJnY29sb3I9IiNlZWVlZWUiIGNsYXNzPSJsaXN0aW5nY2VsbCI+PGZv
bnQgY29sb3I9IiM0NDQ0NDQiPg0KPHByZSBjbGFzcz0ibGlzdGluZ3ByZSI+d3JhcHBlci5zaWxl
bnRfcGluZ3M9NzE5PC9wcmU+DQo8L2ZvbnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KICAgICAg
ICANCjwvdGQ+DQo8L3RyPg0KPC90YWJsZT4NCg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgYWxp
Z249InJpZ2h0IiBpZD0iYXV0aG9yIj4NCjxwPg0KPGk+YnkgV2lsbGlhbSBFZGVuczwvaT4NCjwv
cD4NCjwvdGQ+DQo8L3RyPg0KPC90YWJsZT4NCjxzY3JpcHQgbGFuZ3VhZ2U9IkphdmFTY3JpcHQi
Pi8vQEBCT0RZX1NFQ1RJT05AQDwvc2NyaXB0PjwvdGQ+PHRkIHZhbGlnbj0iYm90dG9tIiB3aWR0
aD0iNCI+PGltZyBoZWlnaHQ9IjQ5NiIgd2lkdGg9IjQiIHNyYz0iaW1hZ2VzL0JvcmRlclJpZ2h0
LnBuZyI+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgYWxp
Z249InJpZ2h0IiBoZWlnaHQ9IjQiIGNvbHNwYW49IjIiPjxpbWcgaGVpZ2h0PSI0IiB3aWR0aD0i
NTAwIiBzcmM9ImltYWdlcy9Cb3JkZXJCb3R0b20ucG5nIj48L3RkPg0KPC90cj4NCjwvdGFibGU+
DQo8L3RkPg0KPC90cj4NCjwvdGFibGU+DQo8dGFibGUgY2VsbHBhZGRpbmc9IjIiIGNlbGxzcGFj
aW5nPSIwIiBib3JkZXI9IjAiIHdpZHRoPSIxMDAlIj4NCjx0cj4NCjx0ZCBpZD0iY29weXJpZ2h0
IiBhbGlnbj0ibGVmdCI+PGZvbnQgY29sb3I9IiM1MjVENzYiIHNpemU9Ii0xIiBmYWNlPSJhcmlh
bCxoZWx2ZXRpY2Esc2Fuc2VyaWYiPjxpPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIENv
cHlyaWdodCAmY29weTsxOTk5LTIwMDQgYnkgPGEgaHJlZj0iaHR0cDovL3d3dy50YW51a2lzb2Z0
d2FyZS5jb20iPlRhbnVraSBTb2Z0d2FyZTwvYT4uDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvaT48L2Zv
bnQ+PC90ZD48dGQgYWxpZ249InJpZ2h0Ij48Zm9udCBjb2xvcj0iIzUyNUQ3NiIgc2l6ZT0iLTEi
IGZhY2U9ImFyaWFsLGhlbHZldGljYSxzYW5zZXJpZiI+PGk+DQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgbGFzdCBtb2RpZmllZDoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c2Ny
aXB0IGxhbmd1YWdlPSJKYXZhU2NyaXB0Ij4gZG9jdW1lbnQud3JpdGUoZG9jdW1lbnQubGFzdE1v
ZGlmaWVkKTsgPC9zY3JpcHQ+PC9pPjwvZm9udD48L3RkPg0KPC90cj4NCjwvdGFibGU+DQo8L2Jv
ZHk+DQo8L2h0bWw+DQo=

Re: [Wrapper-user] wrapper.filter.trigger property question ...

[Richard E. <rem...@ed...>]

We've used this feature for years. It very, very important
that the folks writing messages that will appear in the
log file output do not inadvertently have a string that
will match one of the trigger strings. As an example,
our trigger string at one time was "Error". Well some
well meaning programmer produced a log message that included
that string (when an obscure branch of code executed).
Bang, the application was shutdown and restarted.
So, now all of our trigger strings are the full
class names of the java.lang.Error exceptions types, such as
"UnsupportedClassVersionError".

RME


Leif Mortenson wrote:
> Indra Dutta wrote:
>> I have a filter set as follows in the wrapper.conf file:
>>
>>  
>>
>> wrapper.filter.trigger.1=java.lang.OutOfMemoryError
>>
>> wrapper.filter.action.1=RESTART
>>
>>  
>>
>> Will this fire the trigger if the wrapper output contains the following?
>>
>>  
>>
>> java.lang.OutOfMemoryError: PermGen Space
>>
> Yes.  It will match.
>>  
>>
>> In other words, does wrapper look for an exact match of the string 
>> specified by wrapper.filter.trigger.n property?  If so, it will be 
>> nice to have a feature where user can simply specify a pattern to look 
>> for instead of a literal string.
>>
> The specified filter will match any subset of the console output.  You 
> don't have to
> register the entire line of output.  Take a look at the docs.
> http://wrapper.tanukisoftware.org/doc/english/prop-filter-x-n.html
> 
> Cheers,
> Leif
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
> 


-- 
This email message is for the sole use of the intended recipient(s) and
may contain confidential information.  Any unauthorized review, use,
disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy all
copies of the original message.

Re: [Wrapper-user] wrapper.filter.trigger property question ...

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

Indra Dutta wrote:
>
> I have a filter set as follows in the wrapper.conf file:
>
>  
>
> wrapper.filter.trigger.1=java.lang.OutOfMemoryError
>
> wrapper.filter.action.1=RESTART
>
>  
>
> Will this fire the trigger if the wrapper output contains the following?
>
>  
>
> java.lang.OutOfMemoryError: PermGen Space
>
Yes.  It will match.
>
>  
>
> In other words, does wrapper look for an exact match of the string 
> specified by wrapper.filter.trigger.n property?  If so, it will be 
> nice to have a feature where user can simply specify a pattern to look 
> for instead of a literal string.
>
The specified filter will match any subset of the console output.  You 
don't have to
register the entire line of output.  Take a look at the docs.
http://wrapper.tanukisoftware.org/doc/english/prop-filter-x-n.html

Cheers,
Leif

[Wrapper-user] wrapper.filter.trigger property question ...

[Indra D. <ID...@lg...>]

I have a filter set as follows in the wrapper.conf file:
=20
wrapper.filter.trigger.1=3Djava.lang.OutOfMemoryError
wrapper.filter.action.1=3DRESTART
=20
Will this fire the trigger if the wrapper output contains the following?
=20
java.lang.OutOfMemoryError: PermGen Space
=20
In other words, does wrapper look for an exact match of the string
specified by wrapper.filter.trigger.n property?  If so, it will be nice
to have a feature where user can simply specify a pattern to look for
instead of a literal string.
=20
- Indra
=20
----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and pri=
vileged information for the sole use of the intended recipient.  Any review=
, use, distribution, or disclosure by others is strictly prohibited.  If yo=
u are not the intended recipient (or authorized to receive information for =
the intended recipient), please contact the sender by reply e-mail and dele=
te all copies of this message.

Re: [Wrapper-user] MSVCR80.dll could not be loaded

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

Christian,
    I think you were looking into this as I was redoing the release.  
Sorry about that.
Have you given 3.2.3 a try?  It has been built correctly to use static 
libraries.

Cheers,
Leif

Christian Kuecherer wrote:
> Dear all,
>
> after downloading and extracting Version 3.2.2 of wrapper for Windows, 
> I've got following problem.
> When executing the wrapper.exe file in a command box (cmd) on Windows 
> 2000, there is a message saying "Could not load msvcr80.dll".
> After some research, this is a library from MS-C++, runtime 
> environment, which is of course not installed on my system.
>
> In order to fix that, I tried downloading the dll from 
> www.dll-files.com/dllindex/dll-files.shtml?msvcr80 
> <http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80> which does 
> not help.
> After adding the dll to the path, there is a message saying
> "the procedure entry point '_decode_pointer' could not be found in 
> msvcr80.dll".
> Beforde debugging c++ stuff, I'd like to ask you for any hints.
>
> Within the mailing list, there is no hint for any similar problen.
> Could not belief it, am I the only one ? ;-)
>
> Best regards
> Christian, germany

Re: [Wrapper-user] wrapper.filter.trigger property question ...

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

Indra,
    Yes.  As described on the following page, the string will be matched 
against
the configured text wherever it exists in the output.
http://wrapper.tanukisoftware.org/doc/english/prop-filter-x-n.html

    Note that the filter works my monitoring console output, it is not 
able to
trigger off of exceptions that are caught internally without any console 
output.

    When you ask about matching a pattern, are you referring to 
wildcards like
this "My*Error"?  While that would be possible, it would probably be a 
bit slow
when used.  Not unusable however.   Feel free to submit a feature request
describing exactly what you would like to see.

Cheers,
Leif


Indra Dutta wrote:
>
> I have a filter set as follows:
>
>  
>
> wrapper.filter.trigger.1=java.lang.OutOfMemoryError
>
> wrapper.filter.action.1=RESTART
>
>  
>
> Will this cause the trigger if the wrapper output contains the following?
>
>  
>
> java.lang.OutOfMemoryError: PermGen Space
>
>  
>
> In other words, does wrapper look for an exact match of the string 
> specified by wrapper.filter.trigger.n property?  If so, it will be 
> nice to have a feature where user can simply specify a pattern to look 
> for instead of a literal string.
>
>  
>
> - Indra
>
>  
>

[Wrapper-user] wrapper.filter.trigger property question ...

[Indra D. <ID...@lg...>]

I have a filter set as follows:
=20
wrapper.filter.trigger.1=3Djava.lang.OutOfMemoryError
wrapper.filter.action.1=3DRESTART
=20
Will this cause the trigger if the wrapper output contains the
following?
=20
java.lang.OutOfMemoryError: PermGen Space
=20
In other words, does wrapper look for an exact match of the string
specified by wrapper.filter.trigger.n property?  If so, it will be nice
to have a feature where user can simply specify a pattern to look for
instead of a literal string.
=20
- Indra
=20
----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and pri=
vileged information for the sole use of the intended recipient.  Any review=
, use, distribution, or disclosure by others is strictly prohibited.  If yo=
u are not the intended recipient (or authorized to receive information for =
the intended recipient), please contact the sender by reply e-mail and dele=
te all copies of this message.

Re: [Wrapper-user] Resolve Partial Assembly failed for Microsoft.VC80.CRT

[Jason P. <jas...@gm...>]

Will do.  Cheers

On 10/18/06, Leif Mortenson <le...@ta...> wrote:
>
> Jason,
>     Sorry about that.  I just redid the release as 3.2.3.  Could you
> give it another try?
>
> Cheers,
> Leif
>
> Leif Mortenson wrote:
> > Jason,
> >     For the 3.2.2 release, I upgraded from Visual Studio 98 (v6) to
> Visual
> > Studio 2005 (v8).  I am looking into it right now, but I may have
> > inadvertently
> > changed the requirements for the wrapper to work.
> >     It still builds fine under v6, so if necessary I can put out a 3.2.3
> > release
> > with that down grade.  Let me try to figure out what the root cause is
> > though.
> > Gotta love Microsoft.... :-/
> >
> > Cheers,
> > Leif
> >
> > Jason Polites wrote:
> >
> >> I am getting a strange error when trying to run the wrapper on a
> >> freshly installed Windows 2003 server box:
> >>
> >> "The system cannot execute the specified program."
> >>
> >> Looking at the Windows Event Log, I see:
> >>
> >> Generate Activation Context failed for
> >> D:\java\wrapper-windows-x86-32-3.2.2\bin\wrapper.exe. Reference error
> >> message: The operation completed successfully.
> >>
> >> Then:
> >>
> >> Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference
> >> error message: The referenced assembly is not installed on your system.
> >>
> >> Any idea what I need to do here?  Everything works ok on my Windows XP
> >> (SP2) box, but not on my 2003 server box, or another XP machine which
> >> doesn't have SP2.
> >>
> >> Thanks.
> >>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] MSVCR80.dll could not be loaded

[Christian K. <chr...@gm...>]

Dear all,

after downloading and extracting Version 3.2.2 of wrapper for Windows, I've
got following problem.
When executing the wrapper.exe file in a command box (cmd) on Windows 2000,
there is a message saying "Could not load msvcr80.dll".
After some research, this is a library from MS-C++, runtime environment,
which is of course not installed on my system.

In order to fix that, I tried downloading the dll from
www.dll-files.com/dllindex/dll-files.shtml?msvcr80 which does not help.
After adding the dll to the path, there is a message saying
"the procedure entry point '_decode_pointer' could not be found in
msvcr80.dll".
Beforde debugging c++ stuff, I'd like to ask you for any hints.

Within the mailing list, there is no hint for any similar problen.
Could not belief it, am I the only one ? ;-)

Best regards
Christian, germany

Re: [Wrapper-user] Resolve Partial Assembly failed for Microsoft.VC80.CRT

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

Jason,
    Sorry about that.  I just redid the release as 3.2.3.  Could you 
give it another try?

Cheers,
Leif

Leif Mortenson wrote:
> Jason,
>     For the 3.2.2 release, I upgraded from Visual Studio 98 (v6) to Visual
> Studio 2005 (v8).  I am looking into it right now, but I may have 
> inadvertently
> changed the requirements for the wrapper to work.
>     It still builds fine under v6, so if necessary I can put out a 3.2.3 
> release
> with that down grade.  Let me try to figure out what the root cause is 
> though.
> Gotta love Microsoft.... :-/
>
> Cheers,
> Leif
>
> Jason Polites wrote:
>   
>> I am getting a strange error when trying to run the wrapper on a 
>> freshly installed Windows 2003 server box:
>>
>> "The system cannot execute the specified program."
>>
>> Looking at the Windows Event Log, I see:
>>
>> Generate Activation Context failed for 
>> D:\java\wrapper-windows-x86-32-3.2.2\bin\wrapper.exe. Reference error 
>> message: The operation completed successfully.
>>
>> Then:
>>
>> Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference 
>> error message: The referenced assembly is not installed on your system.
>>
>> Any idea what I need to do here?  Everything works ok on my Windows XP 
>> (SP2) box, but not on my 2003 server box, or another XP machine which 
>> doesn't have SP2.
>>
>> Thanks.
>>     

[Wrapper-user] Wrapper 3.2.3 Release

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

Hello all,
Version 3.2.3 of the Java Service Wrapper has been released today.
This version was released to fix a mistake I made when building the
Windows 3.2.2 release.  It required a set of DLLs that were only
available on systems that had Visual Studio 8 installed.  Sigh...

3.2.3 fixes a critical problem in the Windows versions of 3.2.0
and 3.2.1 which could result in the Wrapper crashing while running
as a service.  It is recommended that users making use of either
of these versions upgrade.

Please see the release notes for a full list of changes:
http://wrapper.tanukisoftware.org/doc/english/release-notes.html

The web site has also been updated to reflect the features of the 3.2.3
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] Resolve Partial Assembly failed for Microsoft.VC80.CRT

[Jason P. <jas...@gm...>]

No worries.  I solved it in the interim by deploying the
Microsoft.VC80.CRTinto the library path of the java app.  This is
found in

%Program Files%\Microsoft Visual Studio 8\VC\redist\x86

It's basically a manifest file and three dlls.  Having this in the same path
as wrapper.dll fixes the problem.  I can confirm that the machine I have on
which it worked the first time also has Visual Studio 2005.

P.S.  I found a few postings about this elsewhere, so you're not the only
one to bump into this.

On 10/17/06, Leif Mortenson <le...@ta...> wrote:
>
> Jason,
>     For the 3.2.2 release, I upgraded from Visual Studio 98 (v6) to Visual
> Studio 2005 (v8).  I am looking into it right now, but I may have
> inadvertently
> changed the requirements for the wrapper to work.
>     It still builds fine under v6, so if necessary I can put out a 3.2.3
> release
> with that down grade.  Let me try to figure out what the root cause is
> though.
> Gotta love Microsoft.... :-/
>
> Cheers,
> Leif
>
> Jason Polites wrote:
> > I am getting a strange error when trying to run the wrapper on a
> > freshly installed Windows 2003 server box:
> >
> > "The system cannot execute the specified program."
> >
> > Looking at the Windows Event Log, I see:
> >
> > Generate Activation Context failed for
> > D:\java\wrapper-windows-x86-32-3.2.2\bin\wrapper.exe. Reference error
> > message: The operation completed successfully.
> >
> > Then:
> >
> > Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference
> > error message: The referenced assembly is not installed on your system.
> >
> > Any idea what I need to do here?  Everything works ok on my Windows XP
> > (SP2) box, but not on my 2003 server box, or another XP machine which
> > doesn't have SP2.
> >
> > Thanks.
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Resolve Partial Assembly failed for Microsoft.VC80.CRT

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

Jason,
    For the 3.2.2 release, I upgraded from Visual Studio 98 (v6) to Visual
Studio 2005 (v8).  I am looking into it right now, but I may have 
inadvertently
changed the requirements for the wrapper to work.
    It still builds fine under v6, so if necessary I can put out a 3.2.3 
release
with that down grade.  Let me try to figure out what the root cause is 
though.
Gotta love Microsoft.... :-/

Cheers,
Leif

Jason Polites wrote:
> I am getting a strange error when trying to run the wrapper on a 
> freshly installed Windows 2003 server box:
>
> "The system cannot execute the specified program."
>
> Looking at the Windows Event Log, I see:
>
> Generate Activation Context failed for 
> D:\java\wrapper-windows-x86-32-3.2.2\bin\wrapper.exe. Reference error 
> message: The operation completed successfully.
>
> Then:
>
> Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference 
> error message: The referenced assembly is not installed on your system.
>
> Any idea what I need to do here?  Everything works ok on my Windows XP 
> (SP2) box, but not on my 2003 server box, or another XP machine which 
> doesn't have SP2.
>
> Thanks.

[Wrapper-user] Resolve Partial Assembly failed for Microsoft.VC80.CRT

[Jason P. <jas...@gm...>]

I am getting a strange error when trying to run the wrapper on a freshly
installed Windows 2003 server box:

"The system cannot execute the specified program."

Looking at the Windows Event Log, I see:

Generate Activation Context failed for D:\java\wrapper-
windows-x86-32-3.2.2\bin\wrapper.exe. Reference error message: The operation
completed successfully.

Then:

Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference error
message: The referenced assembly is not installed on your system.

Any idea what I need to do here?  Everything works ok on my Windows XP (SP2)
box, but not on my 2003 server box, or another XP machine which doesn't have
SP2.

Thanks.