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

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 JOnAS distribution in $JONAS_ROOT/lib.
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 Connector Architecture Resource access (i.e. one for each type of datasource used).
  4. config_env files:
    that may be used for updating the predefined CLASSPATH used by JOnAS.

JOnAS 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 JOnAS 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 JOnAS server.

A JOnAS 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 jonas check command to review the JOnAS configuration state.

The properties files related to Datasource 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 the environment variable named 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 classpath is automatically updated with the jar files needed for JEREMIE instead of the jar files needed for RMI.

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 the JOnAS bootstrap class. 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).
    (Note that the classpath is automatically updated with the jar files needed for DAVID instead of the jar files needed for RMI.

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 the JOnAS bootstrap class. Look at Configuring Jonathan/David how to disable security feature with DAVID.

CosNaming and Registry with DAVID special features

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:

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 can be done by two ways :

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.
An handler represents an output. An handler is identified by its name. It has a type and few others properties. In trace.properties file three handlers have been defined :

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

Loggers are identified by names which are structured as a tree. The root of the tree is named root.

Each logger is a topical logger, i.e. is associated with a topic. Topic names are usually based on the package name. Each logger can define the handler it will use, and the trace level among these 4 values :

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

Jonas code is written using directly monolog API, it can use the tty2 handler.

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

logger.org.objectweb.jonas_ejb.level DEBUG
    

Example for setting the output of JOnAS traces both on console and file /tmp/jonas/log:


handler.logf.output /tmp/jonas.log
logger.org.objectweb.jonas.handler.0 tty2
logger.org.objectweb.jonas.handler.1 logf
   

Configuring JOnAS services

Since version 2.4, JOnAS may be seen like a number of manageable built in service started at server launching time. JOnAS is also able to launch external services which can be defined as explained in the JOnAS service chapter.

Here is the list of the JOnAS built-in services: These services can be managed using the Jadmin administration console, which is a Servlet based application using the JMX technology. Note that Jadmin can only manage available services (currently it is not possible to launch a service via Jadmin).

The services available in a JOnAS server are those specified in the JOnAS configuration file. The jonas.services property in the jonas.properties file must contain a list of the required service names. Currently, these services will be started in the order they appear in the list. Therefore, the following constraints should be considered:


Consider de following example :

     jonas.services    registry,jmx,security,jtm,dbm,resource,jms,mail,web,ejb
    
The registry could be omitted from the list as this service is automatically launched if it is not already activated by another previously started server.
The services: security, jtm, .., are listed after jmx, in oredr to be manageable through the Jadmin application.
The dbm, resource, and jms services are listed after the jtm, for the reason mentioned above.
The application components deployed on this server can use Java Messaging and Java Mail as jms and mail are listed before ejb.
Web components will be deployed in a Tomcat container.

Note also, that it is possible to launch the Transaction manager service 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 are several Registry launching modes depending on the value of the JOnAS property, jonas.service.registry.mode. The possible values of the jonas.service.registry.mode property are:

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

Configuring EJB Container service

This is the main JOnAS service providing EJB containers for EJB components.

An EJB container can be created from an ejb-jar file using one of the following possibilities:

JOnAS also allows for loading unpacked EJB components. The name of the xml file containing the EJB's deployment descriptor must be listed in the jonas.service.ejb.descriptors property. Note that the JOnAS server must have access to the component's classes which may be achieved using the XTRA_CLASSPATH environment variable.

Configuring WEB Container service

This service provides WEB containers for the WEB components used in the J2EE applications.
JOnAS provides an implementation of this service for Tomcat 4.0.x.
It is recommended to run it when you want to use the Jadmin tool.

A WEB container is created from a war file. If the file name does not contain an absolute path name, than it may be located in the directory where the JOnAS Server is launched or in the $JONAS_ROOT/webapps/ directory.

In order for JOnAS to create WEB containers, the corresponding file names may be provided using the jonas.service.web.descriptors property in jonas.properties file. In this case, the WEB containers are created when the JOnAS server starts.
WEB containers may be also dynamically created from war files using the Jadmin tool.
Example:

     jonas.service.web.descriptors  Bank.war
    
Here the WEB Container service will create a container from the war file named Bank.war. If there is no Bank.war in the directory where JOnAS was launched, this file will be searched in $JONAS_ROOT/webapps/ directory.

Configuring EAR service

The EAR service allows deployment of complete J2EE applications (including both ejb-jar and war files packed in an ear file). This service is based upon the WEB container service and the EJB container service. The WEB container service is used to provide the WEB containers for the wars composing the J2EE application, and the EJB container service is used to provide the EJB containers for the ejb-jars composing the J2EE application.

This service may be configured by setting the jonas.service.ear.descriptors property in jonas.properties file. This property provides a list of ears that must be deployed when JOnAS is launched.
The Jadmin tool can be used to dynamically deploy the J2EE application components from an ear file.
When using relative paths for ear file names, the files may be located in the directory where the JOnAS Server is launched or in the $JONAS_ROOT/apps/ directory.
Example:

     jonas.service.ear.descriptors  Bank.ear
    
Here the EAR service will deploy the ear file named Bank.ear. If there is no Bank.ear in the directory where JOnAS was launched, this file will be searched in $JONAS_ROOT/apps/ directory.

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 time-out, 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:

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.3 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"/>

Using Jetty interceptors for authentication

For using Jetty interceptors in your web application you must:

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

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.3).
However, the roles defined in these two files may be the same but it is not mandatory:

For Jetty the corresponding configuration file is jettyRealm.properties file in which users passwords and roles are defined for each web application. This file is by default under JONAS_ROOT/config.

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.

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 Connector Architecture Resources service

The Connector Architecture Resources service is an optional service that must be started as soon as EJB components have 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 Connector Architecture Resources service is to deploy the Resource Adapters in the JOnAS server i.e configure it in the operational environment and register in JNDI name space a connection factory instance that can be looked up by the EJB components.

The way to configure the Connector Architecture Resources service is one of the following methods:

In each resource adapter a jonas specific resource adapter configuration xml file must be included. This file reflects the values of all configuration properties declared in the deployment descriptor for the resource adapter. See Using a Connector Architecture 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. Its configuration consists in choosing one of the two supported JMX implementations, SUN RI or MX4J. The choice is done based on the value of the jonas.service.jmx.class property in the JOnAS configuration file. The two possible values are:

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.3. Tomcat 4.0.3 is an implementation of the Java Servlet 2.3 and JSP 1.2 specifications, Tomcat 3.3 is an implementation of the Java Servlet 2.2 and JSP 1.1 specifications.

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.

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.3 as Tomcat service

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

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

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

Configuring Jetty service

The Jetty service is an optional service that may be used to launch the Jetty servlet container in the same JVM as JOnAS. Jetty is an alternative to Tomcat. The implementation of this service needs Jetty 4.0.4 is installed and the environment variable JETTY_HOME must be set.
Jetty 4.0.4 is an open source HTTP server and Servlet container that is an implementation of the Java Servlet 2.3 and JSP 1.2 specifications.
In order to use Jetty service jetty must be set in the jonas.services property in the jonas.properties file.
When the jetty service is launching it works by default with the configuration file jetty.xml found in JONAS_ROOT/config directory. This file may be customized and its location may be changed. In this case the jonas.service.jetty.config property of jonas.properties file must be set with the absolute path name.
The web applications (.war file) must be installed, by default, under JONAS_ROOT/webapps.

Configuring Mail service

The Mail service is an optional service that may be used to read and send email.
It is based upon JavaMailTM and on JavaBeansTM Activation Framework (JAF) API.

In order to be able to send or receive mails we need a mail factory. JOnAS provides two types of mail factories : javax.mail.Session and javax.mail.internet.MimePartDataSource.
MimePartDataSource factories allow you to send mails with a subject and recipients already set.

Mail factory objects must be configured accordingly to their type. The subsections below briefly explain how to configure Session and MimePartDataSource mail factory objects, in order to be able to run the SessionMailer SessionBean and the MimePartDSMailer SessionBean delivered with the platform.

Configuring Session mail factory

The template MailSession1.properties file supplied in the installation directory defines a mail factory of Session type. The JNDI name of the mail factory object is mailSession_1. You must update this template with values proper to your installation.
See the section "Configuring a mail factory" for the list of available properties.

Configuring MimePartDataSource mail factory

The template MailMimePartDS1.properties file supplied in the installation directory defines a mail factory of MimePartDSMailer type. The JNDI name of the mail factory object is mailMimePartDS_1. You must update this template with values proper to your installation.
You'll find in the section "Configuring a mail factory" the list of available properties. Let's see before, how to configure JOnAS in order to create the mail factory objects you need.

Configuring JOnAS

In order for JOnAS to create mail factory objects, you must name them. In the mailsb example, we defined 2 factories called MailSession1 and MailMimePartDS1.
For each factory we provided a configuration file named with the name of the factory and having the .properties extension (MailSession1.properties for the MailSession1 factory).
Also, the jonas.properties file must define the jonas.service.mail.factories property. In the case of our example, we have:

    jonas.service.mail.factories MailSession1,MailMimePartDS1
    

Configuring a mail factory

The fields are the following:
Required properties
mail.factory.name JNDI name of the mail factory.
mail.factory.type The type of the factory. This property can be javax.mail.Session or
javax.mail.internet.MimePartDataSource.
 
 
Optional properties
 
Authentication properties
mail.authentication.username Set the username for the authentication
mail.authentication.password Set the password for the authentication
 
javax.mail.Session.properties(see JavaMail documentation for more information)
mail.authentication.username Set the username for the authentication
mail.authentication.password Set the password for the authentication
mail.debug The initial debug mode. Default is false.
mail.from The return email address of the current user, used by the InternetAddress method getLocalAddress.
mail.mime.address.strict The MimeMessage class uses the InternetAddress method parseHeader to parse headers in messages. This property controls the strict flag passed to the parseHeader method. The default is true.
mail.host The default host name of the mail server for both Stores and Transports. Used if the mail.protocol.host property isn't set.
mail.store.protocol Specifies the default message access protocol. The Session method getStore() returns a Store object that implements this protocol. By default the first Store provider in the configuration files is returned.
mail.transport.protocol Specifies the default message access protocol. The Session method getTransport() returns a Transport object that implements this protocol. By default the first Transport provider in the configuration files is returned.
mail.user The default user name to use when connecting to the mail server. Used if the mail.protocol.user property isn't set.
mail.<protocol>.class Specifies the fully qualified class name of the provider for the specified protocol. Used in cases where more than one provider for a given protocol exists; this property can be used to specify which provider to use by default. The provider must still be listed in a configuration file.
mail.<protocol>.host The host name of the mail server for the specified protocol. Overrides the mail.host property.
mail.<protocol>.port The port number of the mail server for the specified protocol. If not specified the protocol's default port number is used.
mail.<protocol>.user The user name to use when connecting to mail servers using the specified protocol. Overrides the mail.user property.
 
MimePartDataSource properties (Only used if mail.factory.type is javax.mail.internet.MimePartDataSource)
mail.to Set the list of primary recipients ("to") of the message
mail.cc Set the list of Carbon Copy recipients ("cc") of the message
mail.bcc Set the list of Blind Carbon Copy recipients ("bcc") of the message
mail.subject Set the subject of the message