In addition to defining the binding information between your Java asset and the server where it will be deployed, deployment plans can be used to configure server resources that are limited to the application's scope. This feature is useful when

• You need to limit access to a sensitive resource like a message queue or a database connection pool
• You need to reduce the effort your customers must invest to prepare a server for your asset
• You need to automate special configurations for development or testing.

Below, you will find tips for

• #Configuring a database connection pool
• #Configuring a JMS resource group
• #Configuring a virtual host
• #Configuring a Tomcat Web container
• #Overriding session management attributes

Configuring a database connection pool

Database connection pools are deployed as Java EE connectors and can be limited to an enterprise application (EAR) or a Java EE client application. To accomplish this, you must add the resource adapter to your asset and then add the connector's deployment information to the asset's deployment plan.

Enterprise application scoped database connection pool

To add the resource adapter to your enterprise application, simply copy it from the server's repository into the directory tree used to build your asset. See the database connection pool reference for more information on resource adapter names.
For example, for the Apache Derby local transaction adapter broker, you would search <GERONIMO_HOME>/repository (where <GERONIMO_HOME> is the server's installation directory) for tranql-connector-derby-client-local-<version>.rar (where <version> is replaced with the correct version specification) and copy the file into your EAR.

Use the administrative console to build the deployment plan for the database connection pool, but instead of deploying the result, click the Show plan button, copy the plan to the clipboard, and paste it into a file. See the database connection pool reference for more information on creating database connection pools.

To add the resource group to the deployment plan for your enterprise application, you can reference the group's deployment plan from within the EAR's deployment plan. The result will be similar to this example.

this section, we will discuss about the configurations that are already deployed and running in the server when the server is installed and started.

Connection pools

Apache Geronimo ships with embedded Derby database and ActiveMQ message broker. There are also connection pools that connect to Derby and activeMQ configured to run in the installed server. The following sections discuss about various such configurations already running in the installed server.

Embedded Derby Database connection pool

Apache Geronimo ships with embedded Derby database. The Derby libraries are present in the server repository at <geronimo_home>/repository/org/apache/derby. By default, a Derby database by name SystemDatabase is created and the files related to the database are stored at <geronimo_home>/var/derby/SystemDatabase. Along with that, by default, server deploys a database connection pool over the SystemDatabase with the configuration name org.apache.geronimo.configs/system-database/2.1/car. The name of the database connection pool is SystemDatasource. The configuration artifacts are stored at <geronimo_home>/repository/org/apache/geronimo/configs/system-database. The deployment plan used for database connection pool is as follows.

<?xml version="1.0" encoding="UTF-8"?>
<application<connector xmlns="http://geronimo.apache.org/xml/ns/j2ee/applicationconnector-1.2.0">
    <dep:environment xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2">
    <module><dep:moduleId>
        <connector>adapter</connector><dep:groupId>org.apache.geronimo.configs</dep:groupId>
        <alt-dd>plan.xml</alt-dd><dep:artifactId>system-database</dep:artifactId>
    </module>
   
</application>

where

• adapter is the relative path and file name to the database resource adapter within your EAR.
• plan.xml is the file that contains the database connection pool definition created by the administrative console.

Alternatively, if you prefer to use a single file for the EAR and the database connection pool deployment plan, you can copy the entire contents of the database connection pool deployment plan into the application deployment plan.

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-2.0">
   
    <module>  <dep:version>2.1</dep:version>
      <dep:type>car</dep:type>
    </dep:moduleId>
    <dep:dependencies>
      <dep:dependency>
        <dep:groupId>org.apache.geronimo.configs</dep:groupId>
        <dep:artifactId>transaction</dep:artifactId>
        <connector>adapter</connector>
  <dep:version>2.1</dep:version>
        <dep:type>car</dep:type>
      <!-- Begin -->/dep:dependency>
      <dep:dependency>
        <connector xmlns="http://geronimo<dep:groupId>org.apache.geronimo.org/xml/ns/j2ee/connector-1.2">modules</dep:groupId>
        <dep:artifactId>geronimo-derby</dep:artifactId>
    .
    <dep:version>2.1</dep:version>
        .<dep:type>jar</dep:type>
      </dep:dependency>
      .<dep:dependency>
        </connector><dep:groupId>org.apache.geronimo.modules</dep:groupId>
        <!-- End -->
<dep:artifactId>geronimo-timer</dep:artifactId>
       </module> <dep:version>2.1</dep:version>
        <dep:type>jar</dep:type>
</application>

where

• adapter is the relative path and file name to the database resource adapter within your EAR.
• The entire contents of the file that contains the database connection pool definition created by the administrative console is placed between the Begin and End comment tags, replacing the text in this illustration.

Java client scoped database connection pool

Use the administrative console to build the deployment plan for the database connection pool, but instead of deploying the result, click the Show plan button, copy the plan to the clipboard, and paste it into a file. See the database connection pool reference for more information on creating database connection pool definitions.

To add the database connection pool to the deployment plan for your application client, you can reference the resource adapter and include the connection pool's deployment plan within the application client's deployment plan. The result will be similar to this example.

<?xml version="1.0" encoding="UTF-8"?>
<application-client xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-client-2.0">      </dep:dependency>
      <dep:dependency>
        <dep:groupId>org.apache.derby</dep:groupId>
        <dep:artifactId>derby</dep:artifactId>
        <dep:version>10.2.2.0</dep:version>
        <dep:type>jar</dep:type>
      </dep:dependency>
  
    <resource><dep:dependency>
        <external-rar>adapter</external-rar><dep:groupId>org.apache.derby</dep:groupId>
        <!-- Begin --><dep:artifactId>derbynet</dep:artifactId>
        <connector xmlns="http://geronimo.apache.org/xml/ns/j2ee/connector-1.2"><dep:version>10.2.2.0</dep:version>
           ..
  <dep:type>jar</dep:type>
      </connector>dep:dependency>
      <dep:dependency>
  <!-- End -->      <dep:groupId>org.apache.derby</dep:groupId>
    </resource>
    <dep:artifactId>derbyclient</dep:artifactId>
       
</application-client>

where

...

...

 <dep:version>10.2.2.0</dep:version>
        <dep:type>jar</dep:type>
      </dep:dependency>
      <dep:dependency>
        <dep:groupId>org.tranql</dep:groupId>
        <dep:artifactId>tranql-connector-derby-

...

Configuring a JMS resource group

A JMS resource group includes a connection factory and its destinations. Since JMS resource groups are deployed as Java EE connectors, the group can be limited to an enterprise application (EAR) or a Java EE client application. To accomplish this, you must add the resource adapter to your asset and then add the connector's deployment information to the asset's deployment plan.

Enterprise application scoped resource group

To add the resource adapter to your enterprise application, simply copy it from the server's repository into the directory tree used to build your asset. For example, for the ActiveMQ broker, you would search <GERONIMO_HOME>/repository (where <GERONIMO_HOME> is the server's installation directory) for geronimo-activemq-ra-<version>.rar (where <version> is replaced with the correct version specification) and copy the file into your EAR.

Use the administrative console to build the deployment plan for the JMS resource group, but instead of deploying the result, click the Show plan button, copy the plan to the clipboard, and paste it into a file. See the JMS resource configuration reference for more information on creating JMS resource definitions.

To add the resource group to the deployment plan for your enterprise application, you can reference the group's deployment plan from within the EAR's deployment plan. The result will be similar to this example.

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-2.0">
    
    <module>
        <connector>adapter</connector>
embed-xa
        </dep:artifactId>
        <dep:version>1.3</dep:version>
        <dep:type>rar</dep:type>
      </dep:dependency>
    </dep:dependencies>
    <dep:hidden-classes/>
    <dep:non-overridable-classes/>
  </dep:environment>
  <resourceadapter>
    <outbound-resourceadapter>
      <connection-definition>
        <connectionfactory-interface>javax.sql.DataSource
        </connectionfactory-interface>
        <connectiondefinition-instance>
          <name>SystemDatasource</name>
          <config-property-setting name="UserName"/>
          <config-property-setting name="Password"/>
          <config-property-setting name="DatabaseName">
             SystemDatabase
          </config-property-setting>
          <config-property-setting name="CreateDatabase">
             true
          <alt-dd>plan.xml</alt-dd>
    </module>
    
</application>

where

• adapter is the relative path and file name to the connector's resource adapter within your EAR.
• plan.xml is the file that contains the JMS resource group definition created by the administrative console.

Alternatively, if you prefer to use a single file for the EAR and the JMS resource group deployment plan, you can copy the entire contents of the JMS resource group deployment plan into the application deployment plan.

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-2.0">
   
    <module>
</config-property-setting>
          <connectionmanager>
            <xa-transaction>
              <transaction-caching/>
            </xa-transaction>
            <single-pool>
              <max-size>100</max-size>
              <blocking-timeout-milliseconds>
                 <connector>adapter</connector>
5000
              <!/blocking-timeout-milliseconds>
  Begin -->
           <connector xmlns="http://geronimo.apache.org/xml/ns/j2ee/connector-1.2" <select-one-assume-match/>
            ..</single-pool>
          </connector>connectionmanager>
        <!-- End -->
/connectiondefinition-instance>
        <connectiondefinition-instance>
         < <name>NoTxDatasource</module>name>
        
</application>

where

• adapter is the relative path and file name to the connector's resource adapter within your EAR.
• The entire contents of the file that contains the JMS resource group definition created by the administrative console is placed between the Begin and End comment tags, replacing the text in this illustration.

Java client scoped resource group

Use the administrative console to build the deployment plan for the JMS resource group, but instead of deploying the result, click the Show plan button, copy the plan to the clipboard, and paste it into a file. See the JMS resource configuration reference for more information on creating JMS resource definitions.

To add the resource group to the deployment plan for your application client, you can reference the resource adapter and include the group's deployment plan within the application client's deployment plan. The result will be similar to this example.

<?xml version="1.0" encoding="UTF-8"?>
<application-client xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-client-2.0">
   
    <resource>
        <external-rar>adapter</external-rar>
  <config-property-setting name="UserName"/>
          <config-property-setting name="Password"/>
          <config-property-setting name="DatabaseName">
             SystemDatabase
          </config-property-setting>
          <config-property-setting name="CreateDatabase">
             true
          </config-property-setting>
          <connectionmanager>
            <no-transaction/>
            <single-pool>
            <!-- Begin <max-size>100</max->size>
        <connector xmlns="http://geronimo.apache.org/xml/ns/j2ee/connector-1.2">
      <blocking-timeout-milliseconds>5000
            ..
  </blocking-timeout-milliseconds>
      </connector>
        <!<select-one- End --assume-match/>
     </resource>
       
</applicationsingle-client>

where

• adapter specifies the resource adapter in the server's repository. For example, for the Active MQ resource adapter the specification will have the form

  Panel
  borderStyle solid
  org/apache/geronimo/modules/geronimo-activemq-ra/<version>/geronimo-activemq-ra-<version>.rar

  where <version> is replaced with the correct version numbers.
• The entire contents of the file that contains the JMS resource group definition created by the administrative console is placed between the Begin and End comment tags, replacing the text in this illustration.

Configuring a virtual host

This technique is useful when you wish to deploy a single Web application or enterprise application to a particular domain and you don't want to reconfigure the entire server to support the new domain. This situation may occur when you are combining Web sites. It may also occur when you are deploying a new application to a shared server but it will ultimately be moved to its own server.

...

<gbean
    gbeanInfo="org.apache.geronimo.tomcat.HostGBean"
    name="org.apache.geronimo.configs/tomcat6/2.1.1/car?
      ServiceModule=org.apache.geronimo.configs/tomcat6/2.1.1/car,
      j2eeType=Host,name=bean"
>
  <attribute name="className">org.apache.catalina.core.StandardHost</attribute>
  <attribute name="initParams">
    name=hostname
    appBase=
    workDir=work
  </attribute>
  <attribute name="aliases">list</attribute>
</gbean>

...

• 2.1.1 may need to be replaced with the version number used in your configuration. See your config.xml file to find the correct value.
• bean is the name to be assigned to this gbean (for example, VirtualHost01). This name must be unique in your configuration.
• hostname is the host name to be associated with the default virtual host (for example, www.company.com).
• list is a comma separated list, with no white space, of alias names to be associated with the default virtual host (for example, branch.company.com,service.company.com ). If there are no alias names to specify, omit this entire attribute element.

...

<container-config>
  <tomcat>
    <host>hostname</host>
  </tomcat>
</container-config>

...

• hostname is a hostname that matches the hostname specified in a virtual host defined in the server configuration. The web application can be accessed by requests sent to the specified virtual host or any alias associated with that virtual host.

Configuring a Tomcat Web container

This technique is useful when you wish to limit your Web application to a particular port where no other application is allowed to use that port.

...

pool>
          </connectionmanager>
        </connectiondefinition-instance>
      </connection-definition>
    </outbound-resourceadapter>
  </resourceadapter>
  <gbean name="DerbySystem" 
         class="org.apache.geronimo.derby.DerbySystemGBean">
    <reference name="ServerInfo">
      <name>ServerInfo</name>
    </reference>
    <attribute name="derbySystemHome">var/derby</attribute>
  </gbean>
  <gbean name="DerbyNetwork" 
         class="org.apache.geronimo.derby.DerbyNetworkGBean">
    <reference name="derbySystem">
      <name>DerbySystem</name>
    </reference>
    <attribute name="host">localhost</attribute>
    <attribute name="port">1527</attribute>
  </gbean>
  <gbean name="DerbyLog" 
         class="org.apache.geronimo.derby.DerbyLogGBean">
    <reference name="DerbySystem">
      <name>DerbySystem</name>
    </reference>
  </gbean>
  <gbean name="DerbyDriver" 
  class="org.apache.geronimo.system.util.JDBCDriverRegistrationGBean">
    <attribute name="driverClassName">
       org.apache.derby.jdbc.EmbeddedDriver
    </attribute>
  </gbean>
  <gbean name="DerbyClientDriver" 
   class="org.apache.geronimo.system.util.JDBCDriverRegistrationGBean">
    <attribute name="driverClassName">
      org.apache.derby.jdbc.ClientDriver
    </attribute>
  </gbean>
  <gbean name="TransactionalThreadPooledTimer" class="org.apache.geronimo.timer.jdbc.JDBCStoreThreadPooledTransactionalTimer">
    <attribute name="repeatCount">5</attribute>
    <reference name="TransactionManager">
      <name>TransactionManager</name>
    </reference>
    <reference name="ManagedConnectionFactoryWrapper">
      <name>SystemDatasource</name>
    </reference>
    <reference name="ThreadPool">
      <name>DefaultThreadPool</name>
    </reference>
    <dependency>
      <name>DerbySystem</name>
    </dependency>
  </gbean>
  <gbean name="NonTransactionalThreadPooledTimer" class="org.apache.geronimo.

...

timer.jdbc.

...

JDBCStoreThreadPooledNonTransactionalTimer">
    

...

<reference name="

...

TransactionManager">
      <name>TransactionManager</name>
    </reference>
    <reference name="

...

ManagedConnectionFactoryWrapper">
      

...

<name>SystemDatasource</name>
    </reference>
    <reference name="

...

ThreadPool">
      

...

<name>DefaultThreadPool</name>
    </reference>
    

...

<dependency>
      

...

<name>DerbySystem</name>
    </

...

dependency>
  </gbean>

...

</connector>

After starting the server, the running database connection pool SystemDatasource can be observed on the admin console from console Navigation => Services => Database pools. The resource adapter used to deploy the above database connection pool is tranql-connector-derby-embed-xa-1.3.rar. The above plan is actually deployment plan of a outbound resource adapter. If the above plan is packaged along with the rar file, the xml content will be placed in META-INF/geronimo-ra.xml of the archive.

Closely observe various configurations in the deployment plan. Many derby libraries in the server repository are mentioned as dependencies. After configuring the outbound resource adapter, there are series of gbeans configured for the database connection pool.

Embedded ActiveMQ resource adapter

By default, a JMS resource adapter that connects to embedded activemq message broker is deployed and running in the apache geronimo server. This is an outbound jms resource adapter that configures a connection factory and two message queues. The configuration name of the resource adapter is org.apache.geronimo.configs/activemq-ra/2.1/car. The artifacts of the resource adapter are stored at <geronimo_home>/repository/org/apache/geronimo/configs/activemq-ra. The deployment plan is as follows.

<?xml version="1.0" encoding="UTF-8"?>
<connector xmlns="http://geronimo.apache.org/xml/ns/j2ee/connector-1.2">
  <dep:environment xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2">
    <dep:moduleId>
      <dep:groupId>org.apache.geronimo.configs</dep:groupId>
      <dep:artifactId>activemq-ra</dep:artifactId>
      <dep:version>2.1</dep:version>
      <dep:type>car</dep:type>
    </dep:moduleId>
    <dep:dependencies>
      <dep:dependency>
        <dep:groupId>org.apache.geronimo.configs</dep:groupId>
        <dep:artifactId>activemq-broker</dep:artifactId>
        

...

<dep:version>2.1</dep:version>
        

...

<dep:type>car</dep:type>
      

...

</dep:dependency>
    </dep:dependencies>
    <dep:hidden-classes/>
    

...

<dep:non-overridable-classes/>
  </dep:environment>
  <resourceadapter>
    

...

<resourceadapter-instance>
    

...

  <resourceadapter-name>ActiveMQ RA</resourceadapter-name>
      

...

<config-property-setting name="

...

ServerUrl">tcp://0.0.0.0:61616</config-property-setting>
    

...

  <config-property-setting name="

...

UserName"

...

>geronimo</config-property-setting>
    

...

  <config-property-setting name="

...

Password"

...

>geronimo</config-property-setting>
     

...

 <workmanager>
  

...

...

...

 <gbean-link>DefaultWorkManager</gbean-link>
     

...

 </workmanager>
    

...

</resourceadapter-instance>
    <outbound-resourceadapter>
      <connection-definition>
    

...

    <connectionfactory-interface>javax.jms.ConnectionFactory</connectionfactory-interface>
       

...

 <connectiondefinition-instance>
        

...

  <name>DefaultActiveMQConnectionFactory</name>
      

...

• TomcatWebContainer1 is the name of the new Web container.
• TomcatEngine1 is the name of the new engine for the new Web container.
• TomcatHost1 is the name of the new virtual host in the new Web container.
• TomcatWebManager is the name of the web manager of the new Web container. TomcatWebManager is the name of the Web manager defined in the initial server.
• TomcatJAASRealm is the name of the Tomcat realm for authenticating and authorizing users. TomcatJAASRealm is the name of the realm defined in the initial server configuration.
• FirstValve is the first valve in the optional valve chain for the new Tomcat engine.
  See the Managing Tomcat valves for more information on Tomcat valves.
• FirstListener is the first listener in the optional lifecycle listener chain for the new Tomcat engine. See the Managing lifecycle listeners for more information on lifecycle listener chains.
• localhost is replaced with the host name or IP address of the web containers host. The value localhost will restrict access to requesters in the server's host.
• 8081 is replaced with the port number where the HTTP connector will listen for requests.

...

<web-container>
     <gbean-link>TomcatWebContainer1</gbean-link>
</web-container>

...

• TomcatWebContainer1 is replaced with the name of the new Web container GBean created in the previous step.

Overriding session management attributes

You can override the behavior of the Tomcat session manager within a Web application context by customizing the Tomcat manager within your Web application (WAR) deployment plan. In this example, the maximum number of sessions is customized for a single Web application.

...

<gbean name="TomcatManager" class="org.apache.geronimo.tomcat.ManagerGBean">
    <attribute name="className">org.apache.catalina.session.StandardManager</attribute>
    <attribute name="initParams">
        maxActiveSessions=10
    </attribute>
</gbean>

...

• TomcatManager is the name of the manager GBean defined in the initial server configuration.
• 10 overrides the maximum number of active sessions for a your web application context.

...

<container-config>
    <tomcat xmlns="http://geronimo.apache.org/xml/ns/web/tomcat/config-1.0">
        <!-- Begin Tomcat configuration elements -->
                  
        <manager>TomcatManager</manager>
        ..
        <!-- End Tomcat configuration elements -->

    </tomcat>
</container-config>

    <implemented-interface>javax.jms.QueueConnectionFactory</implemented-interface>
          <implemented-interface>javax.jms.TopicConnectionFactory</implemented-interface>
          <connectionmanager>
            <xa-transaction>
              <transaction-caching/>
            </xa-transaction>
            <single-pool>
              <max-size>10</max-size>
              <blocking-timeout-milliseconds>5000</blocking-timeout-milliseconds>
              <match-one/>
            </single-pool>
          </connectionmanager>
        </connectiondefinition-instance>
      </connection-definition>
    </outbound-resourceadapter>
  </resourceadapter>
  <adminobject>
    <adminobject-interface>javax.jms.Queue</adminobject-interface>
    <adminobject-class>org.apache.activemq.command.ActiveMQQueue</adminobject-class>
    <adminobject-instance>
      <message-destination-name>MDBTransferBeanOutQueue</message-destination-name>
      <config-property-setting name="PhysicalName">MDBTransferBeanOutQueue</config-property-setting>
    </adminobject-instance>
  </adminobject>
  <adminobject>
    <adminobject-interface>javax.jms.Queue</adminobject-interface>
    <adminobject-class>org.apache.activemq.command.ActiveMQQueue</adminobject-class>
    <adminobject-instance>
      <message-destination-name>SendReceiveQueue</message-destination-name>
      <config-property-setting name="PhysicalName">SendReceiveQueue</config-property-setting>
    </adminobject-instance>
  </adminobject>
</connector>

The resource adapter used to deploy the above plan is <geronimo_home>/repository/org/apache/geronimo/modules/geronimo-activemq-ra/2.1. After the server is started, the running resource adapter can be looked up on the admin console from Console Navigation => Services => JMS Resource. We can also observe the connection factories and queues deployed by the resource adapter on the admin console.

Security

A Java EE application may consist of several components that can be deployed into different containers such as WEB container, EJB container, WebServices container in a JEE5 server. This kind of deployment allows multi-tier applications that interact with one another to perform a given user task. Multi-tier JEE5 applications can be secured by properly selecting authenticating mechanisms and designing authorization levels or roles. If the application components use declarative security management, the authentication and authorization aspects are declared in corresponding JEE5 deployment descriptors. The declared security roles or levels are mapped to real security roles or levels in the geronimo deployment plans through security realms. In Apache Geronimo , the security realms abstract away authentication and authorization aspects of the application components. The authentication and authorization together enable access control for the various components of the application.

Depending on the selected authenticating system, a JAAS login module is selected and configured in a security realm. JAAS login modules connect to corresponding user/group repositories and perform authentication and retrieve authorization information. The Geronimo server provides login modules that connect to different types of user/group repositories. These are PropertiesFileLoginModule, LDAPLoginModule, SQLLoginModule and CertificatePropertiesFileLoginModule.

For example, Geronimo uses geronimo-admin security realm to authenticate users when they login to the geronimo administration Console. The deployment plan of the security realm is follows.

geronimo-admin security realm

<module xmlns="http://geronimo.apache.org/xml/ns/deployment-1.2">
    <environment>
        <moduleId>
            <groupId>console.realm</groupId>
            <artifactId>geronimo-admin</artifactId>
            <version>1.0</version>
            <type>car</type>
        </moduleId>

        <dependencies>
            <dependency>
                <groupId>org.apache.geronimo.framework</groupId>
                <artifactId>j2ee-security</artifactId>
                <type>car</type>
            </dependency>
        </dependencies>
    </environment>
    
    <gbean name="geronimo-admin"
           class="org.apache.geronimo.security.realm.GenericSecurityRealm"
           xsi:type="dep:gbeanType"
           xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

        <attribute name="realmName">geronimo-admin</attribute>
        <reference name="ServerInfo">
            <name>ServerInfo</name>
        </reference>
        
        <xml-reference name="LoginModuleConfiguration">
            <log:login-config xmlns:log="http://geronimo.apache.org/xml/ns/loginconfig-2.0">
                <log:login-module control-flag="REQUIRED" wrap-principals="false">
                    <log:login-domain-name>geronimo-admin</log:login-domain-name>
                    <log:login-module-class>
                        org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule
                    </log:login-module-class>
                    <log:option name="groupsURI">var/security/groups.properties</log:option>
                    <log:option name="usersURI">var/security/users.properties</log:option>
                </log:login-module>
            </log:login-config>
        </xml-reference>
    </gbean>

</module>

The above security realm is deployed over two property files <geronimo_home>/var/security/users.properties and var/security/groups.properties that contain user/group information using org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule. The Geronimo Administration Console is a web application that uses the above security realm for user authentication.

The security realm deployment plan is an XML file that uses http://geronimo.apache.org/xml/ns/deployment-1.2 schema for moduleId, dependency and security realm GBean configurations. The XML file uses http://geronimo.apache.org/xml/ns/loginconfig-2.0 schema for login module configuration. All the XML schema files (.xsd) are located at <geronimo_home>/schema directory.

The following table provides the summary of user/group repositories and corresponding login modules in Apache Geronimo

Depending on the type of the login module, the options for configuration may change.

Once a security realm is deployed, it is available for any JEE5 application deployed in Geronimo to map declared roles to actual users/groups through a Geronimo specific deployment plan

...

.