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

Re: [Wrapper-user] Possible Enhancements

[GMX <lg...@gm...>]

Leif,

Thanks for the reply, I will certainly looking into this. One issue why I
was asking for a more external watchdog was that in case the system runs out
of memory it often has some sort of fit, killing tasks and other nasty
stuff. I fear that the hook to catch uncought excpetions might be failing as
well. If you had this in the outside world as part of the watchdog process,
you would not be affected by this. Does this make sense?

Of course, we have to fix the problem itself, but that is another story :-)

Thanks,
Lars

----- Original Message -----
From: "Leif Mortenson" <le...@ta...>
To: <wra...@li...>
Sent: Thursday, October 10, 2002 1:49 PM
Subject: Re: [Wrapper-user] Possible Enhancements


> Lars,
>     The features that you requested below are all things that you can
> build into your
> application. There is nothing there that should require any special code
> on the Wrapper
> level.
>
>     You can catch uncaught exceptions by extending the ThreadGroup class
> and overriding
> the uncaughtException(thread, throwable) method.  You then launch the
> threads of your
> application within this thread group.
>     It would be possible to do this in the Wrapper by launching the
> applications within a
> custom WrapperThreadGroup.  But I am wary of doing that as it would
> likely cause problems
> with some applications.  A lot of server apps which are using the
> Wrapper make heavy use
> of thread groups.  Most likely it would not cause any problems (??)  But
> I would not be able
> to catch any exceptions from threads created by other thread groups, so
> the feature would
> not work consistently.
>
>     The second request about memory monitoring can be handled very
> easily by your application.
> (The best option would be to fix the leak :-) )  But to implement this.
>  Simply monitor the memory
> using using the following:
>
>     Runtime r = Runtime.getRuntime();
>     if ( r.totalMemory() - r.freeMemory() > 128 * 1024 * 1024 )
>     {
>         WrapperManager.restart();
>         // Will not get here.
>     }
>
>     Just put that code in a daemon thread and let it run.
>
> Cheers,
> Leif
>
>
> GMX wrote:
>
> >Hi,
> >
> >I would like to ask if it is possible to add some more functionality to
the
> >wrapper code.
> >
> >First, the ability to detect certain exceptions and as a result restart
the
> >machine. Mainly I am thinking about a OutOfMemoryException, which can
occur
> >if a system runs for a long time and somehow the code does not clear out
its
> >resources. Or a slight memory leak, which of course should be fixed in
the
> >first place but with that extra functionality in the wrapper it would
mean
> >to have another countermeasure against dreadful bugs.
> >
> >Second, and this is along the same line, monitoring the memory usage. Say
> >you have set the maximum memory to 128Mb, it would then be good to set
some
> >sort of threshold to monitor the garbage collection and its
effectiveness.
> >In other words, when the memory increases above a certain limit and then
> >stays there for a given amount of time, then restart the app. This is for
> >the same reasons as above. Usually the garbage collector thread should
free
> >enough resources ones they are filled up, but when buggy code keeps
eating
> >resources, the garbage collector can only free a small percentage each
time,
> >even when running full garbage collections. As an example the minimum
used
> >memory limit that triggers this watchdog could be set to 112Mb and the
time
> >limit to 15 mins. If the memory usage does not drop below 112Mb within 15
> >mins from the time it got over that memory usage level, then restart the
> >app.
> >
> >What I do not know without diving head on into the code is of this sort
of
> >thing is possible with the way wrapper is working and if that information
> >can be reliably gathered using C or Java code.
> >
> >I hope I explained this thoroughly enough. Any help/hint/idea is highly
> >appreciated. Keep up the good work!
> >
> >Kind regards,
> >Lars
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >Wrapper-user mailing list
> >Wra...@li...
> >https://lists.sourceforge.net/lists/listinfo/wrapper-user
> >
> >
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>

Re: [Wrapper-user] Possible Enhancements

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

Lars,
    The features that you requested below are all things that you can 
build into your
application. There is nothing there that should require any special code 
on the Wrapper
level.

    You can catch uncaught exceptions by extending the ThreadGroup class 
and overriding
the uncaughtException(thread, throwable) method.  You then launch the 
threads of your
application within this thread group.
    It would be possible to do this in the Wrapper by launching the 
applications within a
custom WrapperThreadGroup.  But I am wary of doing that as it would 
likely cause problems
with some applications.  A lot of server apps which are using the 
Wrapper make heavy use
of thread groups.  Most likely it would not cause any problems (??)  But 
I would not be able
to catch any exceptions from threads created by other thread groups, so 
the feature would
not work consistently.

    The second request about memory monitoring can be handled very 
easily by your application.
(The best option would be to fix the leak :-) )  But to implement this. 
 Simply monitor the memory
using using the following:

    Runtime r = Runtime.getRuntime();
    if ( r.totalMemory() - r.freeMemory() > 128 * 1024 * 1024 )
    {
        WrapperManager.restart();
        // Will not get here.
    }

    Just put that code in a daemon thread and let it run.

Cheers,
Leif


GMX wrote:

>Hi,
>
>I would like to ask if it is possible to add some more functionality to the
>wrapper code.
>
>First, the ability to detect certain exceptions and as a result restart the
>machine. Mainly I am thinking about a OutOfMemoryException, which can occur
>if a system runs for a long time and somehow the code does not clear out its
>resources. Or a slight memory leak, which of course should be fixed in the
>first place but with that extra functionality in the wrapper it would mean
>to have another countermeasure against dreadful bugs.
>
>Second, and this is along the same line, monitoring the memory usage. Say
>you have set the maximum memory to 128Mb, it would then be good to set some
>sort of threshold to monitor the garbage collection and its effectiveness.
>In other words, when the memory increases above a certain limit and then
>stays there for a given amount of time, then restart the app. This is for
>the same reasons as above. Usually the garbage collector thread should free
>enough resources ones they are filled up, but when buggy code keeps eating
>resources, the garbage collector can only free a small percentage each time,
>even when running full garbage collections. As an example the minimum used
>memory limit that triggers this watchdog could be set to 112Mb and the time
>limit to 15 mins. If the memory usage does not drop below 112Mb within 15
>mins from the time it got over that memory usage level, then restart the
>app.
>
>What I do not know without diving head on into the code is of this sort of
>thing is possible with the way wrapper is working and if that information
>can be reliably gathered using C or Java code.
>
>I hope I explained this thoroughly enough. Any help/hint/idea is highly
>appreciated. Keep up the good work!
>
>Kind regards,
>Lars
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

Re: [Wrapper-user] Service stop while in delay

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

Nic,
Don't bother with the bug. I forgot that the wrapper.restart.delay was added
for 2.2.9 and has not yet been released. I went ahead and got this fixed
today.
It required adding an additional state to the main state engine. This
lets the wrapper
continue to process all control events while it is waiting for the delay
to expire.

I also added a new advanced property which makes it possible to enable
output
of the current wrapper state engine. It is useful for understanding how
the internals
of the Wrapper work. Just add a wrapper.state_output=true line to your
wrapper.conf
file. This will output about 4 lines per second of information like the
following:

wrapper | WrapperState=STARTED, JVMState=STARTED JVMStateTimeout=28
wrapper | WrapperState=STARTED, JVMState=STARTED JVMStateTimeout=28
wrapper | WrapperState=STARTED, JVMState=STARTED JVMStateTimeout=28
wrapper | WrapperState=STARTED, JVMState=STARTED JVMStateTimeout=28
wrapper | WrapperState=STARTED, JVMState=STARTED JVMStateTimeout=27
wrapper | JVM exited unexpectedly.
wrapper | WrapperState=STARTED, JVMState=DOWN JVMStateTimeout=0
wrapper | WrapperState=STARTED, JVMState=LAUNCH(DELAY) JVMStateTimeout=5
wrapper | WrapperState=STARTED, JVMState=LAUNCH(DELAY) JVMStateTimeout=4
wrapper | WrapperState=STARTED, JVMState=LAUNCH(DELAY) JVMStateTimeout=4
wrapper | WrapperState=STARTED, JVMState=LAUNCH(DELAY) JVMStateTimeout=4

I did it this way rather than enabling the output through the log
levels, because it is pretty
low level and is difficult to observe when mixed with lots of other
debug level output.

Could you give this new version a try and confirm that it solves the
problems you were
seeing? (You can checkout from CVS?)

Cheers,
Leif

Leif Mortenson wrote:

>Nic,
>You are right. Hadn't thought of that. In the original design, the delay
>was fixed at
>5 seconds, so it was never a problem. The Wrapper is a single threaded
>app. When it
>is pausing at the restart, that thread simply waits for the specified
>time before
>continuing, so it makes sense that it would do that. I'll have to modify
>it so that it is
>another state in the main loop. That way it will still be able to
>respond to system
>events while it is paused.
>Can you submit a bug on this?
>Cheers,
>Leif
>
>asdfas sdfdsf wrote:
>
>  
>
>>Hi there, Leif
>>That wrapper.restart.delay parameter works great periodically running
>>my app. Back from holiday, but my guys here uncovered another small
>>prob in the meanwhile.
>>When the service is in delay it doesn't stop using the command-line
>>"net stop" (but works with the service manager). It will stop after
>>the delay, but the 'net stop' command returns with an error.
>>Cheers
>>Nic
>>
>>
>>
>>_________________________________________________________________
>>Join the world痴 largest e-mail service with MSN Hotmail.
>>http://www.hotmail.com
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>Wrapper-user mailing list
>>Wra...@li...
>>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>    
>>
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Wrapper-user mailing list
>Wra...@li...
>https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>  
>

Re: [Wrapper-user] Service stop while in delay

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

Nic,
You are right. Hadn't thought of that. In the original design, the delay
was fixed at
5 seconds, so it was never a problem. The Wrapper is a single threaded
app. When it
is pausing at the restart, that thread simply waits for the specified
time before
continuing, so it makes sense that it would do that. I'll have to modify
it so that it is
another state in the main loop. That way it will still be able to
respond to system
events while it is paused.
Can you submit a bug on this?
Cheers,
Leif

asdfas sdfdsf wrote:

> Hi there, Leif
> That wrapper.restart.delay parameter works great periodically running
> my app. Back from holiday, but my guys here uncovered another small
> prob in the meanwhile.
> When the service is in delay it doesn't stop using the command-line
> "net stop" (but works with the service manager). It will stop after
> the delay, but the 'net stop' command returns with an error.
> Cheers
> Nic
>
>
>
> _________________________________________________________________
> Join the world痴 largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

[Wrapper-user] Service stop while in delay

[asdfas s. <nic...@ho...>]

Hi there, Leif
That wrapper.restart.delay parameter works great periodically running my 
app. Back from holiday, but my guys here uncovered another small prob in the 
meanwhile.
When the service is in delay it doesn't stop using the command-line "net 
stop" (but works with the service manager). It will stop after the delay, 
but the 'net stop' command returns with an error.
Cheers
Nic



_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

[Wrapper-user] Possible Enhancements

[GMX <lg...@gm...>]

Hi,

I would like to ask if it is possible to add some more functionality to the
wrapper code.

First, the ability to detect certain exceptions and as a result restart the
machine. Mainly I am thinking about a OutOfMemoryException, which can occur
if a system runs for a long time and somehow the code does not clear out its
resources. Or a slight memory leak, which of course should be fixed in the
first place but with that extra functionality in the wrapper it would mean
to have another countermeasure against dreadful bugs.

Second, and this is along the same line, monitoring the memory usage. Say
you have set the maximum memory to 128Mb, it would then be good to set some
sort of threshold to monitor the garbage collection and its effectiveness.
In other words, when the memory increases above a certain limit and then
stays there for a given amount of time, then restart the app. This is for
the same reasons as above. Usually the garbage collector thread should free
enough resources ones they are filled up, but when buggy code keeps eating
resources, the garbage collector can only free a small percentage each time,
even when running full garbage collections. As an example the minimum used
memory limit that triggers this watchdog could be set to 112Mb and the time
limit to 15 mins. If the memory usage does not drop below 112Mb within 15
mins from the time it got over that memory usage level, then restart the
app.

What I do not know without diving head on into the code is of this sort of
thing is possible with the way wrapper is working and if that information
can be reliably gathered using C or Java code.

I hope I explained this thoroughly enough. Any help/hint/idea is highly
appreciated. Keep up the good work!

Kind regards,
Lars

[Wrapper-user] Re: ver 2.2.9a

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

Ralf,
Looking at Marc's patch more carefully, I see that I missed a change.  :-(
It should be working now.
Could you give it another try?

I placed a new build up on the server:
http://wrapper.sourceforge.net/wrapper_win32_2.2.9b.zip

Thanks,
Leif


WrapperManager.java
1218c1231,1239
<         Thread[] threads = new Thread[Thread.activeCount() * 2];
---
 >         // Locate the top thread group.
 >         ThreadGroup topGroup = Thread.currentThread().getThreadGroup();
 >         while (topGroup.getParent() != null ) {
 >             topGroup = topGroup.getParent();
 >         }
 >        
 >         // Get a list of all threads.  Use an array that is twice the 
total number of
 >         //  threads as the number of running threads may be 
increasing as this runs.
 >         Thread[] threads = new Thread[topGroup.activeCount() * 2];

Could you please send me your modified file?  I have not heard back from 
Marc.


Ralf Weber wrote:

>i had the same problems how with the old version, here is the screenshot:
>
>wrapper  | --> Wrapper Started as Console
>wrapper  | Launching a JVM...
>jvm 1    | Wrapper (Version 2.2.9a)
>.....
>.....
>.....
>jvm 1    | WrapperSimpleApp: main method completed
>wrapperp | sent 6 bytes
>jvm 1    | Received a packet 103 : ping
>jvm 1    | Send a packet 103 : ok
>jvm 1    | All non-daemon threads have stopped.  Exiting.
>jvm 1    | Send a packet 101 : 0
>wrapperp | read a packet 103 : ok
>wrapper  | Got ping response from JVM
>wrapperp | read a packet 101 : 0
>wrapper  | JVM requested a shutdown. (0)
>wrapper  | wrapperStopProcess(0) called.
>wrapper  | Sending stop signal to JVM
>wrapperp | sent 2 bytes
>jvm 1    | Thread, Wrapper-Connection, handling the shutdown process.
>jvm 1    | calling listener.stop()
>jvm 1    | WrapperSimpleApp: stop(0)
>jvm 1    | returned from listener.stop()
>jvm 1    | Send a packet 107 : 0
>jvm 1    | Closing socket.
>wrapperp | read a packet 107 : 0
>wrapper  | JVM signalled that it was stopped.
>wrapperp | socket read no code (closed?).
>jvm 1    | calling System.exit(0)
>wrapper  | JVM exited normally.
>wrapper  | <-- Wrapper Stopped
>
>so i will use the wrapper.jar which one i changed and compiled after i got
>the mail from marc!
>here is the screenshot, it works.
>
>jvm 1    | WrapperSimpleApp: main method completed
>wrapperp | sent 6 bytes
>jvm 1    | Received a packet 103 : ping
>jvm 1    | Send a packet 103 : ok
>wrapperp | read a packet 103 : ok
>wrapper  | Got ping response from JVM
>wrapperp | sent 6 bytes
>jvm 1    | Received a packet 103 : ping
>jvm 1    | Send a packet 103 : ok
>wrapperp | read a packet 103 : ok
>wrapper  | Got ping response from JVM
>wrapperp | sent 6 bytes
>jvm 1    | Received a packet 103 : ping
>jvm 1    | Send a packet 103 : ok
>
>
>  
>

Re: [Wrapper-user] [Fixed] Re: my wrapper stoped and i don't know why

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

Marc,
Thanks for the patch.  That looks like it is most likely the cause.

I went ahead and committed that to CVS.  In case you can't build,  I 
have placed
files up on the server temporarily at the following addresses.  Please 
give them
a try and let me know whether or not they solve the problems that you 
are both
having.

http://wrapper.sourceforge.net/wrapper_win32_2.2.9a.zip
http://wrapper.sourceforge.net/wrapper_linux_2.2.9a.tar.gz

Cheers,
Leif

RE: [Wrapper-user] Re: my wrapper stoped and i don't know why

[Marc W. <ma...@da...>]

I have had a similar problem using 2.2.7.

My application starts up and registers a remote object with an RMI
registry running in the same JVM.  When it is run from the console it
remains after starting up and recieves requests, but when started by the
wrapper, it closes down imediately notifying me that "All non-daemon
threads have stopped".

I used Eclipse to debug the state of the threads after it starts up and
there is one non-daemon thread running. This is running in the System
Thread group, one group above the Thread Group the wrapper is running
in, so when the wrapper checks there are no non-daemon threads, it
returns true and exits, as it is only looking in it's own thread group.

I haven't had much of a look at a fix yet, but changes to the
getNonDaemonThreadCount() method in the WrapperManager class below may
be sufficient. 

Cheers
-Marc

private static int getNonDaemonThreadCount() 
{
	// BEGIN CHANGE
	ThreadGroup topGroup = Thread.currentThread().getThreadGroup();
	while(topGroup.getParent() != null)
	{
		topGroup = topGroup.getParent();
	}

	Thread[] threads = new Thread[topGroup.activeCount() * 2];
	topGroup.enumerate(threads, true);
	
	// END CHANGE

	// Only count any non daemon threads which are 
	//  still alive other than this thread.
	int liveCount = 0;
	for (int i = 0; i < threads.length; i++) {
	    /*
	    if (threads[i] != null) {
	    System.out.println("Check " + threads[i].getName() + "
daemon=" + 
	    threads[i].isDaemon() + " alive=" + threads[i].isAlive());
	    }
	     */
	    if ((threads[i] != null) && (threads[i].isAlive() &&
(!threads[i].isDaemon()))) {
	        // Do not count this thread or the wrapper connection
thread
	        if ((Thread.currentThread() != threads[i]) &&
(threads[i] != _commRunner)) {
	            // Non-Daemon living thread
	            liveCount++;
	            //System.out.println("  -> Non-Daemon");
	        }
	    }
	}
	//System.out.println("  => liveCount = " + liveCount);
	
	return liveCount;
}

-----Original Message-----
From: wra...@li...
[mailto:wra...@li...] On Behalf Of Leif
Mortenson
Sent: Friday, 27 September 2002 23:16
To: Wrapper User List
Subject: [Wrapper-user] Re: my wrapper stoped and i don't know why


Ralf,
The wrapper is designed to exit cleanly when all non-daemon threads have
quit. Most likely, your application is launching one or more threads
with their daemon flag set and then all other threads are exiting.

Daemon threads are designed to be running in the background until the
JVM is ready to shut down. They are designed so that your application
does not need to worry about shutting them all down before the JVM will
exit. The Swing event handler thread is an example of a daemon thread.

Running java without the wrapper should behave in the same way. That is
what the following line is telling you.

jvm 1    | All non-daemon threads have stopped.  Exiting.


Is this an application you wrote yourself? How does it behave when not
using the Wrapper?

Leif

Ralf weber wrote:

>i use the WrapperSimpleApp for my application but after the
>main method completed the wrapper stopped, can you maybe tell 
>me what bullshit i done. i have no idea, here is a screenshot.
>
>ciao, ralf
>
>jvm 1    | WrapperSimpleApp: main method completed
>wrapperp | sent 6 bytes
>jvm 1    | Received a packet 103 : ping
>jvm 1    | Send a packet 103 : ok
>jvm 1    | All non-daemon threads have stopped.  Exiting.
>jvm 1    | Send a packet 101 : 0
>wrapperp | read a packet 103 : ok
>wrapper  | Got ping response from JVM
>wrapperp | read a packet 101 : 0
>wrapper  | JVM requested a shutdown. (0)
>wrapper  | wrapperStopProcess(0) called.
>wrapper  | Sending stop signal to JVM
>wrapperp | sent 2 bytes
>jvm 1    | Thread, Wrapper-Connection, handling the shutdown 
>process.
>jvm 1    | calling listener.stop()
>jvm 1    | WrapperSimpleApp: stop(0)
>jvm 1    | returned from listener.stop()
>jvm 1    | Send a packet 107 : 0
>jvm 1    | Closing socket.
>wrapperp | read a packet 107 : 0
>wrapper  | JVM signalled that it was stopped.
>wrapperp | socket read no code (closed?).
>jvm 1    | calling System.exit(0)
>wrapper  | JVM exited normally.
>wrapper  | <-- Wrapper Stopped
>
>  
>




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

[Wrapper-user] Re: my wrapper stoped and i don't know why

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

Ralf,
The wrapper is designed to exit cleanly when all non-daemon threads have
quit.
Most likely, your application is launching one or more threads with
their daemon
flag set and then all other threads are exiting.

Daemon threads are designed to be running in the background until the JVM is
ready to shut down. They are designed so that your application does not need
to worry about shutting them all down before the JVM will exit. The
Swing event
handler thread is an example of a daemon thread.

Running java without the wrapper should behave in the same way. That is what
the following line is telling you.

jvm 1    | All non-daemon threads have stopped.  Exiting.


Is this an application you wrote yourself? How does it behave when not using
the Wrapper?

Leif

Ralf weber wrote:

>i use the WrapperSimpleApp for my application but after the 
>main method completed the wrapper stopped, can you maybe tell 
>me what bullshit i done. i have no idea, here is a screenshot.
>
>ciao, ralf
>
>jvm 1    | WrapperSimpleApp: main method completed
>wrapperp | sent 6 bytes
>jvm 1    | Received a packet 103 : ping
>jvm 1    | Send a packet 103 : ok
>jvm 1    | All non-daemon threads have stopped.  Exiting.
>jvm 1    | Send a packet 101 : 0
>wrapperp | read a packet 103 : ok
>wrapper  | Got ping response from JVM
>wrapperp | read a packet 101 : 0
>wrapper  | JVM requested a shutdown. (0)
>wrapper  | wrapperStopProcess(0) called.
>wrapper  | Sending stop signal to JVM
>wrapperp | sent 2 bytes
>jvm 1    | Thread, Wrapper-Connection, handling the shutdown 
>process.
>jvm 1    | calling listener.stop()
>jvm 1    | WrapperSimpleApp: stop(0)
>jvm 1    | returned from listener.stop()
>jvm 1    | Send a packet 107 : 0
>jvm 1    | Closing socket.
>wrapperp | read a packet 107 : 0
>wrapper  | JVM signalled that it was stopped.
>wrapperp | socket read no code (closed?).
>jvm 1    | calling System.exit(0)
>wrapper  | JVM exited normally.
>wrapper  | <-- Wrapper Stopped
>
>  
>

[Wrapper-user] Announcing the release of version 2.2.8

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

Wanted to let you guys know that version 2.2.8 of the Java Service
Wrapper was released
today. I am attaching the change log at the end of this mail.

I have also finally gotten the wrapper-user and wrapper-cvs mailing
lists configured
correctly.

Cheers,
Leif

[Wrapper-user] Test

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

Test