# Configuration Guide

1. JOnAS configuration rules
2. Configuring JOnAS environment
3. Configuring JNDI Environment
4. Configuring JOnAS and JNDI for Jeremie
5. Configuring JOnAS and JNDI for David (Rmi iiop)
6. Configuring The Logging System (monolog)
7. Configuring JOnAS services
   - Configuring Registry service
   - Configuring EJB Container service
   - Configuring Transaction service
   - Configuring DataBase service
   - Configuring Security service
   - Configuring JMS service
   - Configuring JCA Resources service
   - Configuring JMX service
   - Configuring Tomcat service

## JOnAS configuration rules

As previously seen in the Getting Started chapter, JOnAS is pre-configured and can be directly used if you want to work with RMI for distribution and if you don't need the visibility of other classes than those that are contained in the `RMI_jonas.jar`.
If you need to work with JEREMIE for distribution or if you need to work with additional java classes (JDBC driver classes for example) you have to perform specific configuration tasks. Setting a specific port number for the registry is another example.

Configuration of JOnAS is made via a little number of configuration files:

1. `jonas.properties` file is used to configure the JOnAS server and the different services that it may launch,
2. `jndi.properties` file is used to configure access to JNDI,
3. additional properties file used to configure Database access or JCA Resource access (i.e one for each type of datasource used).
4. `config_env` files:
   - `$JONAS_ROOT/bin/unix/config_env` on Unix
   - `%JONAS_ROOT%\bin\nt\config_env.bat` on Windows
   that may be used for updating the predefined `CLASSPATH` used by JOnAS.

JOnAS EJB servers are configured via files named `jonas.properties`. It contains a list of key/value pairs presented in the java properties file format. Such files can be found at three different places:

1. `$JONAS_ROOT/config/jonas.properties`
   This file holds all possible properties with their default values. This is the only mandatory file for JOnAS properties. The set of all possible properties is self documented in this file.
2. `$HOME/jonas.properties`
   This file is the place where a user may put its own properties.
3. `./jonas.properties`
   This file can be used to configure properties that depend on a particular EJB server. It is placed in the directory where the server is run. A possible usage of this file is to put the list of the beans to be loaded by the EJB server.

An EJB server will read the three possible files in this order (1, 2, 3), each one may overwrite properties defined in a previous file. Finally, it is possible to define properties on the command line: (`java -D...`).

Do not hesitate to use the `CheckEnv` command to review the JOnAS configuration state.

The properties files related to Datasource or JCA configuration follows the same rule than the previous one.

The `jndi.properties` file is automatically looked up by JNDI in the classpaths.

When you need to have the visibility of specific `.jar` files, the best practice consists in updating the `config_env` file.
For example, to see the JDBC driver classes you need you may update in this file one of the variables `IDB_CLASSES`,`ORACLE_CLASSES`, `POSTGRE_CLASSES`, `INTERBASE_CLASSES`.
Another way to put an additional `.jar` in the classpaths of your JOnAS server is to insert at the end of `config_env` file such a line:

          CLASSPATH=<The_Path_To_Your_Jar>$SPS$CLASSPATH

At least, a third way to do this is to set an environment variable named `XTRA_CLASSPATH` that is used by `config_env` to build the `CLASSPATH`.

## Configuring JOnAS Environment

Most of the properties are related to the JOnAS services that can be launched in the JOnAS server. The meaning of such properties is detailed in Configuring JOnAS services.
Two special properties that are not relatives to any service: `jonas.name` and `jonas.orb.port`, the former indicates the name of the JOnAS server, the latter the port number on which the remote objects receive calls.
The default value of `jonas.name` is jonas. When you need to have several JOnAS servers running simultaneously it is valuable to set a different name for each JOnAS server and so it will be possible to administrate these servers via the JOnAS administration tools.
The default value of `jonas.orb.port` is 0 this means that an anonymous port is chosen. Setting this property to a specific port number may be used when JOnAS server is behind a firewall.

## Configuring JNDI Environment

Access to JNDI is bound to a `jndi.properties` file that must be accessible from the classpath.
Such a file is supplied with the JOnAS distribution in the `$JONAS_ROOT/config` directory and by default the `CLASSPATH` is up to date to access to this file by the way of the config_env file.

The `jndi.properties` file contents for RMI and DAVID is:

          java.naming.factory.initial   com.sun.jndi.rmi.registry.RegistryContextFactory
          java.naming.provider.url      rmi://localhost:1099
          java.naming.factory.url.pkgs  org.objectweb.jonas.naming

The `jndi.properties` file contents for JEREMIE is:

          java.naming.factory.initial   org.objectweb.jeremie.libs.services.registry.jndi.JRMIInitialContextFactory
          java.naming.provider.url      jrmi://localhost:12340
          java.naming.factory.url.pkgs  org.objectweb.jonas.naming

Customization of JNDI consists to edit the `$JONAS_ROOT/config/jndi.properties` file and mainly to choose between RMI and JEREMIE.

You may change `localhost` to the hostname where registry will be run.
You may want to change the standard port number too. In this case, don't forget to run registry with this port number as argument: `registry <Your_Portnumber>`, when the registry is not launched inside the EJB server.

## Configuring JOnAS and JNDI for JEREMIE

Remember of the default configuration of the JOnAS distribution is for RMI.

The following steps are required to change from RMI to JEREMIE:

1. Adapt the `jndi.properties` file as indicated previously.
2. set `OBJECTWEB_ORB=JEREMIE` in the `$JONAS_ROOT/bin/unix/config_env` file on Unix (or in the `%JONAS_ROOT%\bin\nt\config_env.bat` file on Windows).
   (Note that the config_env script automatically update the CLASSPATH with `JEREMIE_jonas.jar` instead of `RMI_jonas.jar`).

If you have already deployed EJB with RMI you must redeploy (i.e run the GenIC tool) them for JEREMIE use.

JEREMIE has a special configuration file `jonathan.xml` under `$JONAS_ROOT/config`, that, in general you can easily ignore. This file must be seen via the classpath and it is the case by default thanks to config_env. Look at Configuring Jonathan/Jeremie how to disable security feature with JEREMIE.

## Configuring JOnAS and JNDI for DAVID (rmi iiop)

From now on, you can build/use JOnAS on the top of DAVID which is the CORBA personality of the JONATHAN ORB.This version uses two naming services for object binding:

1. The Rmi registry for Referenceable objects like UserTransaction
2. The David CosNaming for rmi-iiop Remote objects like ejb home or remote interfaces

The general operation principle of JOnAS over rmi-iiop is the same operation principle than JOnAS over rmi-jrmp, there are only some restrictions listed at the end of this section. Remember of the default configuration of the JOnAS distribution is for RMI.

The following steps are required to change from RMI to DAVID:

1. Keep the same `jndi.properties` file as for RMI.
2. set `OBJECTWEB_ORB=DAVID` in the `$JONAS_ROOT/bin/unix/config_env` file on Unix (or in the `%JONAS_ROOT%\bin\nt\config_env.bat` file on Windows).
3. set `COSNAMING_PORT=14727` (this is an example, set your Cosnaming port) `COSNAMING_HOST=jonas.objectweb.org` (this is an example, set your Cosnaming host) in the `$JONAS_ROOT/bin/unix/config_env` file on Unix (or in the `%JONAS_ROOT%\bin\nt\config_env.bat` file on Windows).
4. Ensure that `DAVID_jonas.jar` is in your classpath rather than `RMI_jonas.jar` (The config_env file does this automatically)

If you have already deployed EJB with RMI or JEREMIE you must re-deploy (i.e run the GenIC tool) them for DAVID use.

DAVID has a special configuration file `jonathan.xml` under `$JONAS_ROOT/config`, that, in general, you can easily ignore. This file must be seen via the `CLASSPATH` and it is the case by default thanks to config_env. Look at Configuring Jonathan/David how to disable security feature with DAVID.

CosNaming and Registry with DAVID special features

- In JOnAS over DAVID, you must use the remote mode for naming service. So just set the `jonas.services.registry.mode` to value `remote` in the `JONAS_ROOT/config/jonas.properties`file. The default value for `jonas.services.registry.mode` is `automatic` so, if you start the remote registry before the JOnAS server with the default configuration, it will work fine
- Run the registry with the command: `registry 14727 1099`. The last two numbers (CosNaming port and Registry port) are optional, if they are not specified, the registry starts with default configuration: with the CosNaming port set to 14727 and the registry port set to 1099. Be sure that, if you run the registry command with the 2 port numbers, this two numbers correpond to your server configuration (`COSNAMING_PORT` and provider.url port in the `jndi.properties file`)

Rmi Iiop Client with DAVID

The following steps are required to launch a rmi iiop client with David:

1. Configure JOnAS, compile src like with jeremie (with `OBJECTWEB_ORB` set to DAVID)
2. Start the 2 Naming Services with the following:

       registry <cosnaming port> <registry port>

3. Start Server with the following:

       EJBServer <cosnaming host> <cosnaming port>

4. Start the client jvm with the -D system properties:

       java \
       -Dorg.omg.CORBA.ORBClass=org.objectweb.david.libs.binding.orbs.iiop.IIOPORB \
       -Dorg.omg.CORBA.ORBSingletonClass=org.objectweb.david.libs.binding.orbs.ORBSingletonClass \
       -Djavax.rmi.CORBA.StubClass=org.objectweb.david.libs.stub_factories.rmi.StubDelegate \
       -Djavax.rmi.CORBA.PortableRemoteObjectClass=org.objectweb.david.libs.binding.rmi.ORBPortableRemoteObjectDelegate \
       -Djavax.rmi.CORBA.UtilClass=org.objectweb.david.libs.helpers.RMIUtilDelegate \
       -Ddavid.CosNaming.default_method=0 \
       -Ddavid.rmi.ValueHandlerClass=com.sun.corba.se.internal.io.ValueHandlerImpl \
       -Ddavid.CosNaming.default_host=$COSNAMING_HOST \
       -Ddavid.CosNaming.default_port=$COSNAMING_PORT \
       your.client.ClassName

JOnAS with DAVID Restrictions:

- The CosNaming and Registry must be remote in JOnAS over rmi-iiop
- There are many problems with the Security Context propagation in JOnAS over rmi-iiop
- The Session Stateful method isIdentical() does not work fine in JOnAS over rmi-iiop
- The Jadmin Tool does not work fine in JOnAS over rmi-iiop

## Configuring Logging System (monolog)

Since Jonas 2.5, the logging system is based on Monolog, the new standard API for Objectweb projects. Configuring trace messages inside Jonas or the modules it uses can be done by two ways :

- Changing the trace.properties file to configure statically the traces, before the EJBServer is run
- Using the JonasAdmin tool or the Jadmin servlet to configure dynamically the traces, while the EJBServer is running.

### trace.properties syntax

A standard file is given in `$JONAS_ROOT/config/trace.properties` The policy to retrieve this file is to use the CLASSPATH. You can either change the file in its standard location, or to copy your own version somewhere else.

You can refer to the monolog documentation to know in more details how you can configure logging. Basically, we must know that monolog is build above a standard log API (currently, log4j). You can define loggers, each one being backed on a handler. 3 handlers have been defined :

- tty is a basic standard output on console, with no headers.
- tty2 is the same, but with extended headers (class + method)
- logf is a handler to print messages on a file

Each handler can define the header it will use, the type of logging (console, file), and the file name.

Loggers are structured as a tree. root represents the root of the tree. Each logger is a topical logger, i.e. is associated with a topic. topic name are usually based on the package name. Each logger can define the handler it will use, and the trace level among these 4 values :

- ERROR errors. Should be always printed
- WARN warning. Should be printed
- INFO informative messages, not very used in Jonas (for example: test results)
- DEBUG debug messages. Should be printed only for debugging

If a logger has nothing defined, it will use the properties defined for its parent.

Jonas modules (org.objectweb.jonas_xxx) use generally the tty handler because all messages had been written (in older jonas version) with the method name inside, so no need to add it again.

Jonas code is written using directly monolog API, so they use the tty2 handler.

Example of setting DEBUG level for the logger used in jonas_ejb module:

    logger.org.objectweb.jonas_ejb.level DEBUG

## Configuring JOnAS services

Since version 2.4 JOnAS may be seen like a number of built in services that are started at server launching time. JOnAS is able to launch external services (see the JOnAS service chapter). JOnAS may be configured to launch only a subset of available services.
The JOnAS existing services are the following:

- registry: this service is used for binding remote objects and resources that will be later accessed via JNDI. It must be started before all other services.
- tomcat: this service is used to launch the Tomcat's servlet container in the same JVM as JOnAS. You must start it before Jmx service.
- jmx: this service must be started in order to administrate JOnAS server via `Jadmin`. This is not a mandatory service.
- security: this service is needed for enforcing security functionalities at runtime. It is not a mandatory service.
- jtm: the Transaction manager service is used for the support of distributed transactions. This service is mandatory.
- dbm: the Database service is needed as soon as we need access to one or several relational databases. This optional service musr be started after jtm.
- resource: this service is needed in order to access to Resource Adapter conform to the J2EE Connector Achitecture Specification. This optional service must be started after jtm.
- jms: the Java Message Service is a standard API for messaging that can be used by application components in JOnAS especially message driven beans. When it is the case the jms service must be started after jtm.
- ejb: the EJB Container service is the service that provides support for application components.

Via the EJBServer command it is possible to launch all or some of these services depending on the `jonas.services` property in `jonas.properties` file. The services will be started in the order of the list. The order required when all the services must be started is the following:

         jonas.services    registry,jmx,security,jtm,dbm,resource,jms,ejb

It is possible to launch the Transaction manager service alone. There is no sense to try to launch other services alone.

Most of configuration information for services are located in the `jonas.properties` file following a precise naming convention : a service XX will be configured via a set of properties:

        jonas.service.XX.foo   something
        jonas.service.XX.bar   else

## Configuring Registry service

This service is used for accessing the RMI registry or Jeremie registry depending on the configuration of JNDI made in `jndi.properties` see Configuring JNDI Environment.

There is different Registry launching mode depending on the value of the JOnAS property, `jonas.service.registry.mode`. The possible values of the `jonas.service.registry.mode` property are:

- `collocated`: the Registry is launched in the same JVM as JOnAS Server,
- `remote`: the Registry has to be launched before in a separate JVM,
- `automatic`: the Registry is launched in the same JVM as JOnAS Server, if it's not already started, (this is the default value).

The port number on which the Registry is launched, is defined in the `jndi.properties` file.

## Configuring Container service

This is the main JOnAS service. This service is used for providing EJB containers that will interpose themselves between the EJB components and other services in order to inject services defined by the EJB deployment descriptor.
This service is configured by setting the `jonas.service.ejb.descriptors` property in `jonas.properties` file. In this property must be set a list of containers that must be created. A container is created from an `ejb-jar` file or from an EJB deployment descriptor identified by their files names. These files names absolute path name or relative path name. In the later case the path is relative to where the JOnAS Server is launched. In case of `ejb-jar` file, the name may also correspond to a file located in the `$JONAS_ROOT/ejbjars/` directory.
example:

         jonas.service.ejb.descriptors  Bank.jar, ../sample.xml

Here the Container service will a create a container from the `ejb-jar` file named `Bank.jar`. If there is no `Bank.jar` in the directory where JOnAS was launched, this file will be searched in `$JONAS_ROOT/ejbjars/` directory.
A second container will be created from the EJB deployment descriptors `sample.xml` and `jonas-sample.xml` that must both be located in a parallel directory to the one where JOnAS was launched.

## Configuring Transaction service

The Transaction service is used by the Container service in order to provide transaction management for EJB components as defined in the deployment descriptor. It is a mandatory service. The Transaction service uses a Transaction manager that may be local or launched in another JVM ( a remote Transaction manager). Typically when there are several JOnAS servers working together, one of the Transaction service must be considered as the master and the other as slaves. The later must be configured as working with a remote Transaction manager.
Here is an example of configuration of two servers, one named TM in which a stand alone Transaction service will be run, the second named EJB will be used to deploy some EJB container:

         jonas.name               TM
         jonas.services           jtm
         jonas.service.jtm.remote false

and

         jonas.name                    EJB
         jonas.services                jmx,security,jtm,dbm,ejb
         jonas.service.jtm.remote      true
         jonas.service.ejb.descriptors foo.jar

Another possible configuration is the value of the transaction timeout, in seconds, via the `jonas.service.jtm.timeout` property.
Here is the default configuration:

          jonas.service.jtm.timeout   60

## Configuring Database service

In order to be able to access one or several relational databases (e.g. Oracle, InstantDB, PostgreSQL, ...), JOnAS will create and use DataSource objects. You have to configure such a DataSource object according to the database you intend to use for the persistence of a bean. More details about DataSource objects and their configuration is provided in the "Configuring JDBC DataSources" chapter of the Bean Programmer's Guide.

The subsections below briefly explains how to configure a DataSource object for your database, in order to be able to run the Entity Bean example delivered with the platform.

### Configuring Oracle for the supplied example

A template Oracle1.properties file is supplied in the installation directory. This file is used to define a DataSource object, named `Oracle1`. You must update this template with values proper to your installation. The fields are the following:

datasource.name | JNDI name of the DataSource: The name used in the example is `jdbc_1`.
datasource.url | The JDBC database URL: for the Oracle JDBC "Thin" driver it is `jdbc:oracle:thin:@hostname:sql*net_port_number:ORACLE_SID` If you are using an Oracle OCI JDBC driver, the URL is `jdbc:oracle:oci7:` or `jdbc:oracle:oci8:`
datasource.classname | Name of the class implementing the Oracle JDBC driver: `oracle.jdbc.driver.OracleDriver`
datasource.username | Database user name
datasource.password | Database user password

In order that the EJB platform creates the corresponding DataSource object, you must have its name (Oracle1, not the JNDI name) in your `jonas.properties` file, on the jonas.service.dbm.datasources line:

        jonas.service.dbm.datasources      Oracle1

You may have several DataSource objects defined for an EJB server, in this case, you will have several dataSourceName.properties files, and the list of DataSource names on the jonas.service.dbm.datasources line of the jonas.properties file:

        jonas.service.dbm.datasources      Oracle1, Oracle2, InstantDB1

Your Oracle server must be running, and a JDBC driver installed (Oracle JDBC drivers may be downloaded at their Web site). You can then create the table used by the example with the SQL script provided in `examples/src/eb/Account.sql`.
For example:

        sqlplus user/passwd
        SQL> @Account.sql
        SQL> quit

The JDBC driver classes must be accessible from the classpath. For that, you must update the config_env file; (`$JONAS_ROOT/bin/unix/config_env` on Unix, or `%JONAS_ROOT%\bin\nt\config_env.bat` on Windows).

### Configuring InstantDB for the supplied example

A template InstantDB1.properties file is supplied in the installation directory. This file is used to define a Datasource object, named InstantDB1. You must update this template with values proper to your installation. The fields are the following:

datasource.name | JNDI name of the DataSource: The name used in the example is `jdbc_1`.
datasource.url | The JDBC database URL: for InstantDB it is `jdbc:idb=db1.prp`
datasource.classname | Name of the class implementing the JDBC driver: `org.enhydra.instantdb.jdbc.idbDriver`

In order that the EJB platform creates the corresponding DataSource object, you must have its name (InstantDB1, not the JNDI name) in your `jonas.properties` file, on the jonas.service.dbm.datasources line

        jonas.service.dbm.datasources            InstantDB1

InstantDB should have been properly installed and configured. You should use a version higher than 3.14. (examples have been tested with 3.25).

The JDBC driver classes must be accessible from the classpath. For that, you must update the config_env file; (`$JONAS_ROOT/bin/unix/config_env` on Unix, or `%JONAS_ROOT%\bin\nt\config_env.bat` on Windows).

You have to create the Account database using the utility provided with InstantDB:

        cd examples/src/eb
        . $JONAS_ROOT/bin/unix/config_env
        java org.enhydra.instantdb.ScriptTool Account.idb

### Configuring other databases

The same kind of process can be used for other databases. We supply with JOnAS a template of datasource for PostgreSQL and for InterBase. Of course many other databases are currently used by the JOnAS users, e.g. Informix, Sybase, SQL Server, ... however not all JDBC drivers have been tested against JOnAS.

## Configuring Security service

The Security service is used by the Container service to provide security for EJB components. The Container service provides security in two forms: declarative security and programmatic security. The Security service exploits security roles and method permissions found in the EJB deployment descriptor.

Note that:

- JOnAS relies on Tomcat for the identification and authentication of the user. Thus, security is available only if the client of the EJB is a servlet in Tomcat which has been configured to be secured
- There is no mapping concerning the security between JOnAS and the target operational environment. That is to say that the roles defined for JOnAS cannot be mapped to roles of the target operational environment (e.g., groups on Unix).

There is no specific properties in `jonas.properties` file for configuring security service.

### Configuring Jonathan/Jeremie

It is up to Jonathan/Jeremie to propagate the security context (built after authentication process). However if this security feature is not needed, you can disable this feature by modifying the `jonathan.xml` file and put this line in comments:

             <ELEM name="200"><ALIAS name="/jeremie/SSHandler/instance"/></ELEM>

Disabling the security feature increases performance.

### Configuring Jonathan/David

It is up to Jonathan/David to propagate the security context (built after authentication process). However if this security feature is not needed, you can disable this feature by modifying the `jonathan.xml` file and put this line in comments:

             <ELEM name="200"><ALIAS name="/david/SSHandler/instance"/></ELEM>

Disabling the security feature increases performance.

### Using security with RMI

With RMI in order to use security in JOnAS, special Stubs and Skeletons must be generated. This is done by using GenIC tool with the `-secpropag` option.

### Using Tomcat interceptors for authentication

Now Tomcat version 3.3.x or Tomcat 4.0.x may be used to identify and authenticate and can be embedded via the `tomcat service` ( seeConfiguring Tomcat service) There is one step to enable Tomcat to be used as an authenticated client for JOnAS.
With Tomcat3.3.x (both on RMI or on Jeremie), in the `$TOMCAT_HOME/conf/modules.xml` file, replace the following line:

`<module name="AccessInterceptor" javaClass="org.apache.tomcat.modules.aaa.AccessInterceptor"/>`

by :

`<module name="AccessInterceptor" javaClass="org.objectweb.security.tomcat.interceptor.SecurityCtxInterceptor33"/>`

With Tomcat4.0.x (both on RMI or on Jeremie), in the `$TOMCAT_HOME/conf/server.xml` file, replace the following line:

`<Realm className="org.apache.catalina.realm.MemoryRealm"/>`

by :

`<Realm className="org.objectweb.security.tomcat.interceptor.SecurityCtxInterceptor40"/>`

### Configuring mapping principal/roles

JOnAS relies on the `jonas-users.properties` file for the access control to the methods of EJB components. This is a simple properties file where each property has the following syntax: `<principal> = <list of roles>` where

- `<principal>` is a string identifying the user. It can be an email address (`joe.bar@foo.com`) or a login (`barj`) or whatever identifying the user.
- `<list of roles>` is a list of roles separated by commas (e.g.: `administrator, user`). These roles will be used in the deployment descriptor of the EJB component.

It has to be noted that to use Tomcat to identify and authenticate the users, the principals defined in the `jonas-users.properties` must be the same that those in the `$TOMCAT_HOME/conf/users/tomcat-users.xml` file (`$TOMCAT_HOME/conf/tomcat-users.xml` file for Tomcat 4.0.x).
However, the roles defined in these two files may be the same but it is not mandatory:

- The roles defined in the `tomcat-users.xml` file are used in Tomcat.
- The roles defined in the `jonas-users.properties` file are used in JOnAS.

## Configuring JMS service

JOnAS uses a third party JMS implementation (currently the Joram opensource is integrated and delivered with JOnAS, the SwiftMQ product may also be used, other JMS provider implementations may easily be integrated). JMS service is used to contact (or launch) the corresponding MOM (Message Oriented Middleware) or JMS server. The JMS administered objects used by the EJB components, such as the connection factories and the destinations, should be created previously to the EJB execution, by the way of the proprietary JMS implementation administration facilities. JOnAS provides "wrappers" upon such JMS administration APIs, allowing simple administration operations to be achieved automatically by the EJB server itself.
jms service is an optional service that must be started before the ejb container service.
Here are the properties that may be set in `jonas.properties` file for jms service:
`jonas.service.jms.collocated` for setting the JMS server launching mode. If set to true it is launched in the same JVM as JOnAS Server (this is the default value) if set to false it is launched in a separate JVM in this case the `jonas.service.jms.url` must be set with the connexion url to the JMS server.

`jonas.service.ejb.mdbthreadpoolsize` is used for setting the default thread pool used Message Driven Beans (10 is the default value).

`jonas.service.jms.queues` and `jonas.service.jms.topics` are used for setting lists of administered objects queues or topics at launching time. If (and only if) these properties are not set, a default administered object queue named sampleQueue and a default administered object topic named sampleTopic are created by the jms service.

`jonas.service.jms.mom` is used to indicate what class must be used to perform administrative operations. This class is the wrapper to the actual JMS provider implementation. The default one is org.objectweb.jonas_jms.JmsAdminForJoram that must be used for Joram. You may get a com.swiftmq.appserver.jonas.JmsAdminForSwiftMQ class from the SwiftMQ site if you intend to use the SwiftMQ product.

## Configuring JCA Resources service

The JCA Resources service is an optional service that must be started as soon as EJB components has to access to an external Enterprise Information Systems. The standard way to do this is to use a third party software component called Resource Adapter.

The role of the JCA Resources service is to deploy the Resource Adapter in JOnAS server i.e configure it in the operational environment and register in JNDI namespace a connection factory instance that can be looked up by the EJB components.

The way to configure the JCA Resources service is very similar to the Database service:

`jonas.service.resource.resources` property set the list of Resource Adapter to be used. This is a coma-separated list of resource adapter configuration properties file names (without the '.properties' suffix).

For each resource adapter a resource adapter configuration properties file must be provided to the JCA Resources service. This file reflects the values of all properties declared in the deployment descriptor for the resource adapter. See Using a JCA Resource Adapter with JOnAS for additional information.

## Configuring JMX service

The JMX service must be started in order to administrate or instrument JOnAS server via `Jadmin`.This is not a mandatory service but if it is needed it must be launched first. There is no specific configuration for this service.

## Configuring Tomcat service

The Tomcat service is an optional service that may be used to launch the Tomcat servlet container in the same JVM as JOnAS. It is recommended to run it when you want to use the `Jadmin` tool. JOnAS since 2.5 version provides two implementations for this service: one for using Tomcat 3.3.x and one for using Tomcat 4.0.x.

### Using Tomcat 3.3.x as Tomcat service

The implementation of this service needs that Tomcat 3.3.x is installed and the environment variables `TOMCAT_HOME` and `JAVA_HOME` must be set.

The `jonas.service.tomcat.class` property in `jonas.properties` file must be set to `org.objectweb.jonas.tomcat.EmbeddedTomcatImpl33`. This is the default value for this property.

the `jonas.service.tomcat.args` property in `jonas.properties` file may be used to pass arguments to Tomcat when it starts, the syntax is the one of the script `tomcat.sh`.

### Using Tomcat 4.0.x as Tomcat service

The implementation of this service needs that Tomcat 4.0.x is installed and the environment variables `CATALINA_HOME` and `CATALINA_BASE` must be set (see Tomcat 4.0.X documentation).

The `jonas.service.tomcat.class` property in `jonas.properties` file must be set to `org.objectweb.jonas.tomcat.EmbeddedTomcatImpl40`

The only argument possible in `jonas.service.tomcat.args` property is `-debug`.