A server, or JOnAS instance, is a java process started via the jonas start command, or via the administration tool Java EE.

Several servers may run on the same physical host.

When a server starts, services are started.

A service typically provides system resources to containers. Most of the components of the JOnAS application server are pre-defined services. However, it is possible and easy for an advanced user to define a new service and to integrate it into JOnAS.

JOnAS services are manageable through JMX.

A container consists of a set of Java classes that implement the Java EE specification. The role of the container is to provide the facilities for executing Java EE components.

There are three types of containers:

A domain represents an administration perimeter which is under the control of an administration authority.

This perimeter contains management targets like servers and clusters.

If a domain contains several elements, it provides at least one common administration point represented by a master server.

A master is a JOnAS instance having particular management capabilities within the domain:

A cluster is a group of JOnAS servers having common properties within a domain. It usually allows to run a J2EE application, or a J2EE module, on the cluster members as if they were a single server. The objective is to achieve applications scalability and high availability.

JOnAS supports several cluster types:

From the administrator point of view, a cluster represents a single administration target.

Note that a particular JOnAS server may belong to zero, one or more clusters.

JOnAS administration mainly provides monitoring and configuration functions. Moreover, administrator can dynamically install/deploy/undeploy applications and/or resources on a running server.

All the functions are proposed by the JonasAdmin application, wereas the jonas admin command supports only a part of these functions.

Domain administration is mainly based on JonasAdmin.

It allows consulting the domain map (shows the servers and clusters in the domain) and modify this map.

Moreover, monitoring of the domain is provided: shows state evolution of servers and clusters, and statistics on resources used by the different servers in the domain.

Finally, dynamic install/deploy/undeploy operations are extended at the domain level: the applications source is the administaror server and operation's target may be one ore more servers and/or clusters in the domain.

Administrator may create clusters, add and/or remove servers to/from clusters. Allowed operations depend on the cluster type.

Once the JonasAdmin application deployed on a server, the administration console is accessible at the URL: http://<hostname>:<portnumber>/jonasAdmin/ using any web browser.

<hostname> is the name of the host where the Servlet container is running and <portnumber> is the http port number (default is 9000).

After logging in, the left-hand frame in the Welcome page displays the management tree associated with the JOnAS server running JonasAdmin. The management tree's root is Domain , which allows to the domain management facilities in case of a master server.

In the image below, JonasAdmin is running on the master server named jonas within a domain also named jonas. It is immediately apparent that this is a master server, as we have a Monitoring and a Deployment sub-tree under the Domain root node.

The management tree in this figure allows access to the following main management facilities:

Displays general information about the administered JOnAS server, including the JMX server and the WEB server, and provides the capability of listing the content of the Registry.

It is important to note that JOnAS and Tomcat have different approaches to reconfiguration persistency. In JOnAS, every Save operation is related to a service or a resource reconfiguration. For example, the administrator can reconfigure a service and a resource, but choose to save only the new resource configuration. In Tomcat, the Save operation is global to all configuration changes that have been performed. For example, if a new HTTP connector is reconfigured and a new context created for a web application, both configuration changes are saved when using the Save button.

First recall that domain management functions are accessible only when JonasAdmin is deployed on a master server. The Domain tree contains only one Server sub-tree, the currently administered server, which is initially the server hosting JonasAdmin.

Domain management principal function is to present the domain topology: list all the servers and clusters belonging to the domain. It also allows modification of the domain topology by adding new servers and clusters to the domain, removing servers and moving servers to/from clusters.

The domain management page also presents servers that are not yet started but are specified as belonging to the domain in the new configuration file named domain.xml . Also, a server can be added to the domain when it has been started without having the discovery service enabled.

An essential domain management function is that the administrator can switch from the master to any of the other servers in the domain. Currently, JonasAdmin allows only one category of global domain level management operation, the deployment operation. Using any other management operation requires switching to the server to be administered.

Domain level deployment allows for deploying one or more J2EE packages (JARs, WARs, RARs or EARs), which are installed in the corresponding master directory (ejbjars, webaps, rars or apps), into any running server in the domain. A deployment operation target may be a server but also a cluster. The deploy operation may have three semantics:

Note that at domain level deployment the Upload and Remove operations are only related to the master server itself.

Access to the MEJB provided by the JOnAS 5 distribution is now role secured. The client application that wants to access it must have one of the following roles:

Unauthorized access is forbidden

This snippet includes all of the elements needed to specify security roles in the web.xml file of a web application client of MEJB

   <security-constraint>
   <web-resource-collection>
     <web-resource-name>Protected Area</web-resource-name>
     <!-- Define the context-relative URL(s) to be protected -->
     <url-pattern>/*</url-pattern>
     <!-- If you list http methods, only those methods are protected -->
     <http-method>DELETE</http-method>
     <http-method>GET</http-method>
     <http-method>POST</http-method>
     <http-method>PUT</http-method>
   </web-resource-collection>
   <auth-constraint>
     <!-- Anyone with one of the listed roles may access this area -->
     <role-name>mejb-admin</role-name>
   </auth-constraint>
 </security-constraint>

 <!-- Default login configuration uses BASIC authentication -->
 <login-config>
   <auth-method>BASIC</auth-method>
   <realm-name>JOnAS Realm</realm-name>
 </login-config>

 <!-- Security roles referenced by this web application -->
 <security-role>
   <role-name>mejb-admin</role-name>
 </security-role> 

All the MBeans defined by the J2EE Management Specification are provided by JOnAS. These MBeans respect the naming conventions and are registered in the JMX server embeded in any JOnAS instance.

Proprietary MBeans are registered by JOnAS and by the integrated components in order to allow management of services or specific resources.

A set of operations is available on the remote server, it can be accessed by any JMX client connecting to the JOnAS J2EEServer Mbean. Here is a list of the available operations with an example using the JConsole:

For instance, the above operations can be easily tried using the JConsole diplaying the following interface:

Here is a result of the getThreadStackDumpList operation given by the JConsole. Navigation between elements is done using right and left arrows, each thread properties are displayed.

Please note all the above operations are also available through the MBeanCmd Dump Command

JonasAdmin web application provides a Flex module that lets you view all threads information. This module is available in the "Monitoring" node from the "Server JOnAS" section by clicking on the "StackDump" tab.

If JOnAs is started as a master ("jonas.master" property in the "jonas.properties" file is set to "true"), the thread stack dump visualization module is available for the current administrated server. Thus a master can access the thread stack dump of any server from the same domain through jonasAdmin stackDump visualization module by switching the current administrated server.

The visualization module shows all threads name and id from the JVM. Threads can be ordered by names or ids by clicking on the header of the related column. A selection of one or more threads can be done by clicking on names or ids. Selected threads information such as priority, state or stacktrace appear in a column to the right.

The Refresh button refreshes the threads list from the underlying JVM.

The Select all button allows to select all the threads from the JVM to get the complete "stacktrace" information from the server.

The Copy to clipboard button allows to copy all selected threads information in the clipboard so they could be pasted in a file to be kept. (Please also note that any part from the right column can be selected using the mouse and copied with a right click).

JOnAS provides support for remote connection to the MBean server in a standard way based on the JMX Remote API.

The JSR 160 specifies the JMX Remote API which extends the JMX specification by providing a standard way to connect to remote JMX-enabled applications.

Currently, JSR 160 has defined a mandatory connector based on RMI (that supports both RMI/JRMP and RMI/IIOP).

JSR 160 support implies providing standard connector server objects. The JMX service creates at start-up one or several such objects, depending on the protocols configuration (defined in carol.properties file). To create a client connector, the client side needs to know the URL of the connector server. Below we present the URLs that can be used by the clients depending on the protocol they choose.

Currently only 2 protocols can be used by JSR-160 connectors: RMI/JRMP and RMI/IIOP.

  Hashtable environment = null;
  JMXServiceURL address = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://host:1099/jrmpconnector_jonas");
  JMXConnector connector = JMXConnectorFactory.newJMXConnector(address, environment);
  connector.connect(environment);
      

  Hashtable environment = null;
  JMXServiceURL address = new JMXServiceURL("service:jmx:iiop:///jndi/iiop://host:2001/iiopconnector_jonas");
  JMXConnector connector = JMXConnectorFactory.newJMXConnector(address, environment);
  connector.connect(environment);