|
From: Leif M. <le...@ta...> - 2004-07-08 03:06:22
|
Venkatesh,
I agree that littering your code with Wrapper references is not a
very good idea.
The Wrapper does provide you with a few ways of avoiding this however.
1) Create a shutdown method which centralizes the WrapperManager.restart
code
to a single location. (Not much better but it does allow you to make
your code
cleaner)
2) Register Output triggers with the Wrapper. (v3.0.0 and above)
If your application reliably outputs a message to the console then the
Wrapper
is able to trigger on that output and shutdown or restart the JVM. See the
following for details:
http://wrapper.tanukisoftware.org/doc/english/prop-filter-x-n.html
3) Register on-exit events with the Wrapper. (v3.1.0 and above)
The Wrapper is capable of performing different actions depending on the exit
code returned when the JVM exits. You could for example trigger a restart
if the JVM exits with a non-zero exit code. See the following for details:
http://wrapper.tanukisoftware.org/doc/english/prop-on-exit-n.html
wrapper.on_exit.default=RESTART
wrapper.on_exit.0=SHUTDOWN
Whenever a fatal error is encountered, simply call System.exit(1) and your
JVM will be restarted by the Wrapper. About as non-intrusive as you
can get.
Cheers,
Leif
Venkatesh Sellappa wrote:
>Hi All,
>
>My problem,
>
>I have an application that is dependent on multiple resources and there is no single entry point/catch-all
>class where i can monitor the resources.
>I understand that the standard way of handling runtime crashes is to
>
>try
>{
> // do something
>}
>catch ( Exception x )
>{
> // clear stacks
> WrapperManager.restart();
>}
>This would allow us to restart the JVM.
>My quibble, this is a fairly intrusive way of doing things, as the classes now become
>WrapperManager dependent.
>
>Has anyone found any other way of doing this ?
>
>I am using Integration method 3.
>Any and all suggestions welcome.
>
>Rgds,
>
>
|