|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
Applications which need to be controlled directly as a service can implement the WrapperListener interface and then register themselves with the WrapperManager on instantiation. The WrapperManager will then control the the class as a service for its entire life-cycle.
Method Summary | |
void |
controlEvent(int event)
Called whenever the native wrapper code traps a system control signal against the Java process. |
java.lang.Integer |
start(java.lang.String[] args)
The start method is called when the WrapperManager is signaled by the native wrapper code that it can start its application. |
int |
stop(int exitCode)
Called when the application is shutting down. |
Method Detail |
public java.lang.Integer start(java.lang.String[] args)
If this method throws an exception the Wrapper will shutdown the current JVM in an error state and then relaunch a new JVM. It is the responsibility of the user code to catch any exceptions and return an appropriate exit code if the exception should result in the Wrapper stopping.
args
- List of arguments used to initialize the application.
public int stop(int exitCode)
WARNING - Directly calling System.exit in this method will result in a deadlock in cases where this method is called from within a shutdown hook. This method will be invoked by a shutdown hook if the JVM shutdown was originally initiated by a call to System.exit.
exitCode
- The suggested exit code that will be returned to the OS
when the JVM exits.
public void controlEvent(int event)
The WRAPPER_CTRL_C_EVENT will be called whether or not the JVM is controlled by the Wrapper. If controlled by the Wrapper, it is undetermined as to whether the Wrapper or the JVM will receive this signal first, but the Wrapper will always initiate a shutdown. In most cases, the implementation of this method should call WrapperManager.stop() to initiate a shutdown from within the JVM. The WrapperManager will always handle the shutdown correctly whether shutdown is initiated from the Wrapper, within the JVM or both. By calling stop here, it will ensure that the application will behave correctly when run standalone, without the Wrapper.
WRAPPER_CTRL_CLOSE_EVENT, WRAPPER_CTRL_LOGOFF_EVENT, and WRAPPER_CTRL_SHUTDOWN_EVENT events will only be encountered on Windows systems. Like the WRAPPER_CTRL_C_EVENT event, it is undetermined as to whether the Wrapper or JVM will receive the signal first. All signals will be triggered by the OS whether the JVM is being run as an NT service or as a console application. If the JVM is running as a console application, the Application must respond to the CLOSE and LOGOFF events by calling WrapperManager.stop() in a timely manner. In these cases, Windows will wait for the JVM process to exit before moving on to signal the next process. If the JVM process does not exit within a reasonable amount of time, Windows will pop up a message box for the user asking if they wish to wait for the process or exit or forcibly close it. The JVM must call stop() in response to the SHUTDOWN method whether running as a console or NT service. Usually, the LOGOFF event should be ignored when the Wrapper is running as an NT service.
Unless you know what you are doing, it is suggested that the body of this method contain the following code, or its functional equivalent.
public void controlEvent( int event ) { if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT ) && WrapperManager.isLaunchedAsService() ) { // Ignore } else { WrapperManager.stop( 0 ); } }
event
- The system control signal.
|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |