Jump to content

Commons Daemon: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
No edit summary
 
No edit summary
Line 1: Line 1:
JSCV designates the Jakarta Tomcat 4.0 project´s Daemon component with the proposed package name org.apache.commons.daemon. For that, it is also called the '''commons daemon''', while Commons ist the Jakarta subproject which focuses on reusable Java components.
JSVC designates the Jakarta Tomcat 4.0 project´s Daemon component with the proposed package name org.apache.commons.daemon. For that, it is also called the '''commons daemon''', while Commons ist the Jakarta subproject which focuses on reusable Java components.


In a nutshell, JSCV provides '''means of interacting with non-interactive Unix daemons''' (as far as Win32 services are concerned, ''procrun'' would be the adequate counterpart). It is made of 2 parts. One is written in C that makes the interface to the operating system, the other in Java, that provides the Daemon API.
In a nutshell, JSCV provides '''means of interacting with non-interactive Unix daemons''' (as far as Win32 services are concerned, ''procrun'' would be the adequate counterpart). It is made of 2 parts. One is written in C that makes the interface to the operating system, the other in Java, that provides the Daemon API.

Revision as of 18:14, 24 November 2005

JSVC designates the Jakarta Tomcat 4.0 project´s Daemon component with the proposed package name org.apache.commons.daemon. For that, it is also called the commons daemon, while Commons ist the Jakarta subproject which focuses on reusable Java components.

In a nutshell, JSCV provides means of interacting with non-interactive Unix daemons (as far as Win32 services are concerned, procrun would be the adequate counterpart). It is made of 2 parts. One is written in C that makes the interface to the operating system, the other in Java, that provides the Daemon API.

For a wider understanding of when such a component is usefull, one has to grasp the distinction between server and client applications in terms of starting and stopping them.

Whilst Client Java platform applications are started through a single point of entry (the public static void main(String[]) method), those applications can afterwards be stopped interactively by the user. The quitting application then can terminate the JavaVM process by calling the System.exit(int) method.

For non-interactice applications (like server application) there is no portable way to notify the Virtual Machine of its imminent shutdown, which might be required in such cases as the server application might have to perform several tasks before being able to shutdown the Virtual Machine process. For example in the case of a Servlet container, before the VM process is shut down, sessions might need to be serialized to disk, and web applications need to be destroyed.

This problem can be surpassed by using JSVC and through that "interface" initiating the startup or shutdown of daemons like for excample Tomcat.

There generally are two ways to use jsvc: via a implementing the Daemon interface or via calling a Class that provides the required methods for JSVC. For example Tomcat-4.1.x uses the Daemon interface and Tomcat-5.0.x provide a Class whose methods are called by jsvc directly.