Application Deployment

This article explains how to deploy an existing Application manually, through the Console and through the admin.jar to the Orion Application Server.

1 Introduction

    This article explains how to deploy an existing Application to an Orion Application Server by presenting a step-by-step guide. It also gives a brief view of the structure of a J2EE application.

2 The Structure of a J2EE Application in brief

    This section briefly describes the structure of a J2EE Application.

    A J2EE application is made up of one or more modules and a descriptor (application.xml) describing these module(s). This is normally packaged into an .ear file but doesn't have to be.

    Regardless of if the application is packaged or not, the file structure should look something like in the following example: 


        /ejb.jar
        /web.war
        /helper.jar
        /application-client.jar
        /connector.rar
        /META-INF/application.xml
    Listing 1: Example of application file structure

    The example application in listing 1 above consists of an EJB-module, a Web-module, a Client-module, a Connector-module and a utility jar.

    Remember that when using helper classes located in a separate JAR, the utilizing JAR should have a reference to the helper JAR in its manifest file.

    Each module could then be packaged (as in listing 1 above) or unpackaged, which would look something like in the example below: 


        /ejb.jar
        /web/index.jsp
        /web/smiley.gif
        /web/WEB-INF/web.xml
        /helper.jar
        /application-client.jar
        /META-INF/application.xml
    Listing 2: Example of an unpackaged application's structure

    Using an unpackaged directory structure is very effective during development.

    As this article is about deploying applications and not about creating them, the structure of J2EE applications will not be further explored here.

3 Deploying a J2EE application manually

    This section describes the steps necessary to deploy an existing J2EE application manually.

    This section involves the following steps:

    3.1 Step 1: Editing server.xml

      Add an entry like the one given below to the server.xml file of the Server you are deploying to: 


          <application name="name"
                          path="path"
                          parent="parent"
                          auto-start="boolean" />
      Listing 3: Adding a application tag to server.xml

      The syntax of the application tag can be found here.

      Replace name with the name to use when referring to the application.

      Replace path with the relative (to the location of the server.xml file) or absolute path to the application. If the application is packaged into an EAR-file, the path and the name of the EAR-file should be given. If the application is not packaged the name of the directory where the application is should be given.

      Replace parent with the name of an application that should be utilized from this application, or leave out the attribute if this is not needed.

      Replace boolean with true or false depending upon if the application should be started automatically when the Server is started. The default is true, so the attribute only needs to be included if the intention is to set the value to false

      The file server.xml is normally located in /orion/config/server.xml.

      Below is an example where an unpackaged application (the ATM sample) is deployed with the reference name "atm":


      <application name="atm" path="../applications/atm" />
      Listing 4: Example of application tag usage for an unpackaged Application

      Below is an example where a packaged application (the ATM sample again) is deployed with the reference name="atm": 


      <application name="atm" path="../applications/atm.ear" />
      Listing 5: Example of application tag usage for a packaged Application

      When an application is deployed to a Server, the Server outputs a confirmation (or an error message) to Standard.out. It also creates a new directory in the applications deployment directory for the application. This directory is also where the applications log files are found by default.

    3.2 Step 2: Bind Web-module to site (optional)

      If the application contains Web-modules these should be bound to a URL and a Site in order to be accessible by clients.

      Step-by-step instructions for binding a Web-module to a site manually can be found here.

4 Deploying a J2EE application through the Console

    This section describes the steps necessary to deploy an existing J2EE application through usage of the Orion Console.

    One of the benefits of using the Console over manually deploying an application is that it allows remote deployments. The downside is that the application needs to be packaged as an EAR file.

    This section involves the following steps:

    4.1 Step 1: Starting the Console

      In order to start the console, you should invoke Orion in the following way:


      Java -jar orion.jar -console
      Listing 6: Orion invocation

      The console should now start up displaying any hosts tied to it.

    4.2 Step 2: Starting the EAR Deployer

      Select the host to deploy the application to and then bring up the context menu for the selected host. From the context menu, select the option "Install application". Use the file browser window to locate the existing application and confirm the selection. When asked for a deployment name, state the name to use for referencing this deployment of the application on this host.

      The EAR-deployer will now be launched in a separate window

    4.3 Step 3: Configuring the deployment

      The EAR-deployer allows configuration all Orion specific settings as well as vendor neutral settings of an application.

      Configuring a deployment is outside the scope of this article and is covered elsewhere.

    4.4 Step 4: Installing

      Select "Deploy" from the "Installation" menu. This will start the actual installation of the application.

      After a little while the Deployment result window will be displayed showing one or more confirmation message(s) or error message(s). Close this window by clicking the "OK" button.

    4.5 Step 5: Web-modules

      If the application contained any Web-modules, these will be prompted for site and root information. Select the site from the pull-down list presented and enter the root that the Web-module should be accessible at and click the "OK" button.

      The EAR-deployer window will now close.

5 Deploying a J2EE application through admin.jar

    This section describes the steps necessary to deploy an existing J2EE application through usage of the Orion admin.jar.

    One of the benefits of using the admin.jar over manually deploying an application is that it allows remote deployment. As opposed to using the Console, the admin.jar approach does not involve a GUI, which could be good for environments where that is not available. The downside is that the application needs to be packaged as an EAR archive.

    This section involves the following steps:

    5.1 Step 1: Deploying the application

      Issue the following command to deploy (or redeploy) an application: 


      java -jar admin.jar ormi://host:port username password -deploy -file filename -deploymentName depname -targetpath tarpath -parent parent -deploymentDirectory dir -cluster
      Listing 7: using admin.jar

      Replace host with the location of the host to deploy to.

      Replace port with the port the host is listening to. If not specified 23791 will be used by default.

      Replace username with a valid administrator username

      Replace password with a valid administrator password that belongs to the given username (see above).

      Replace filename with the path and name of the EAR archive to deploy.

      Replace depname with the deployment name to use for this deployment.

      Replace tarpath with the path to the target directory for the EAR archive. If this parameter is not given the default applications directory will be used.

      Replace parent with the name of an application that should be utilized from this application, or leave out the attribute if this is not needed.

      Replace dir with the root deployment directory. If "[NONE]" is given, the deployment configuration files will be placed inside the EAR archive. If this parameter is not given the default application-deployments directory will be used.

      To signal that the deployment should be propagated to other nodes in the cluster if this host is part of a cluster, keep the -cluster switch in the command line.

      To signal that any previous deployment with the same deployment name should be removed before this application is deployed, keep the -ignorePreviousDeployment switch in the command line.

    5.2 Step 2: Bind Web-module to site (optional)

      If the application contains Web-modules these should be bound to a URL and a Site in order to be accessible by clients.

      Step-by-step instructions for binding a Web-module to a site using orion.jar can be found here.

6 Deploying a J2EE application through Ant

    This section describes the steps necessary to deploy an existing J2EE application through the usage of Ant.

    This can be particularly useful during development where new builds has to be deployed in an orderly and controlled way in short intervals.

    One of the benefits of using the Ant approach over manually deploying an Application is that it allows this to be performed remote. The Ant approach does not involve a GUI, which could be good for environments where none is available. The downside is that the Application needs to be archived as an EAR-archive, but this is very simple to do when utilizing Ant.

    In order to utilize this section, Ant knowledge is required. Read more about Ant here.

    This section involves the following steps:

    6.1 Step 1: Creating the build file

      In a suitable directory, create the following build file and call it build.xml:


          <?xml version="1.0" ?>
          <project name="hello-world" default="deploy" basedir=".">
      

              <target name="init">
                  <property name="name" value="hello-world" />
                  <property name="build.dir" value="build" />
                  <property name="orion.dir" value="/usr/local/orion" />
                  <property name="build.compiler" value="classic" />
                  <property name="deploy.ormi" value="" />
                  <property name="deploy.username" value="" />
                  <property name="deploy.password" value="" />
              </target>
      

              <target name="deploy" depends="init">
                  <java classname="com.evermind.client.orion.OrionConsoleAdmin" fork="yes">
                      <arg value="${deploy.ormi}" />
                      <arg value="${deploy.username}" />
                      <arg value="${deploy.password}" />
                      <arg value="-deploy" />
                      <arg value="-file" />
                      <arg value="${build.dir}/${name}.ear" />
                      <arg value="-deploymentName" />
                      <arg value="${name}" />
                      <classpath>
                          <pathelement location="${orion.dir}/orion.jar" />
                          <pathelement location="${orion.dir}/ejb.jar" />
                          <pathelement location="${orion.dir}/jndi.jar" />
                      </classpath>
                  </java>
              </target>
          </project>
      Listing 8: A sample build file for Ant

      Replace the value of the property name with the name deployment name of your application.

      The property name is also used as the name of the EAR-archive to deploy (with an added ".ear"). You might want to change that

      Replace the value of the property build.dir with the path to the directory holding your EAR-archive.

      Replace the value of the property orion.dir with the path to the directory holding your Orion JAR files.

      Replace the value of the property build.compiler with the compiler to use (if you don't want to use classic).

      Replace the value of the property deploy.ormi with the path to the Orion Application Server to deploy to.

      Replace the value of the property deploy.username with the name of an administrator user on the Orion Application Server to deploy to.

      Replace the value of the property deploy.password with the password of an administrator user on the Orion Application Server to deploy to.

      Notice that if no build file name is specified, Ant will look for a file called build.xml at the codebase.

    6.2 Step 2: Executing the build file

      In a suitable directory (depending on your setup) execute the build file with the following command:


          ant
      Step 2: Executing the build file from the command line

      This will invoke Ant looking for a local build.xml file. As the build.xml file created above has a default target, there is no reason to specify a target.

      The specified Application should now have been deployed to the Orion Application Server specified.

      If the build file is not located in the same directory as Ant is executed in, the -buildFile [file] needs to be utilized to point out the build file to use.

    6.3 Step 3: Bind Web-module to site (optional)

      If the application contains Web-modules these should be bound to a URL and a Site in order to be accessible by clients.

      Step-by-step instructions for binding a Web-module to a site using Ant is available here.

7 Deploying a J2EE application automatically

    This section describes the steps necessary to deploy an existing J2EE application through the usage of Orion's automatic deployment feature.

    One of the benefits of using Orion's automatic deployment feature is that is a very quick and easy way of deploying applications. The drawback is the lack of control mainly regarding reference names.

    This section involves the following steps:

    7.1 Step 1: Making sure auto-deployment is enabled

      In order to utilize the auto-deployment feature of Orion this feature must be turned on, as this feature is disabled by default.

      Open up the server.xml on the Server and make sure that the following attribute exists in the application-server tag: 


          <application-server
              ...
              application-auto-deploy-directory="path"
              ...
          >
      Listing 9: Making sure that the auto-deploy-directory is there

      The syntax of the application-server tag can be found here.

      Where path is the path to the directory you want to put your EAR-archives to auto-deploy, as for example "../applications/auto"

      This will instruct the Server to automatically deploy any new or changes applications in the specified directory.

      The file server.xml is normally located in /orion/config/server.xml.

    7.2 Step 2: Auto-deploying an Application

      To utilize the enabled auto-deployment feature, just drop your EAR-archives in the directory specified (see step 1 above).

      Orion will deploy the Application using the name of the EAR-archive (without the .ear suffix) together with any modules it contains.

      Any Web-modules that are part of the Application will be bound to the active default web-site (if available) using the context-root stated in the Applications application.xml as root. If no context-root is given, the name of the WAR-archive (without the .war suffix) will be used as root.

8 Deploying standalone J2EE modules

    Information about deploying a standalone Connector-module can be found here.

    Information about deploying a standalone EJB-module can be found here.

    Information about deploying a standalone Web-module can be found here.

    Information about deploying a standalone Client-module can be found here.

9 Deployment configurations

    After that an Application has been deployed, it is possible to modify its deployment configurations by editing the generated orion-application.xml file. This file is normally located in the deployment directory of the Application.


        /orion/application-deployments/appname/orion-application.xml
    Listing 10: Location of the deployment configuration file for an Application. Replace 'appname' with the name of the Application in question.

    It is also possible to specify deployment configuration settings during deployment by using the EAR-deployer tool.

    An edited Application deployment configuration file can be included in the .ear file of the application. Orion would then copy the orion-application.xml file when the Application is first deployed, and use it as base for the new deployment configuration. The orion-application.xml file that is to be included in the .ear file should be kept to a minimum and be located in the META-INF directory of the Application, right next to the application.xml J2EE Application file.

    The settings available for deployment configuration of an Application are:

    See also: Client-module deployment configuration, Connector-module deployment configuration, EJB-module deployment configuration and Web-module deployment configuration.

    9.1 Automatic creation of EJB CMP tables

      By default, Orion creates the database tables and columns needed for any EJB CMP Beans in the Application, according to the EJB-module configurations and the database schema used for the Datasource in use.

      To turn this feature off, add an entry to orion-application.xml as described in listing 11 below.


      <orion-application
          auto-create-tables="false"
      />
      Listing 11: Turning automatic creation of EJB CMP tables off in the Application deployment configuration

    9.2 Automatic alteration of EJB CMP tables

      By default, Orion will not try to alter database tables and columns to reflect CMP Entity changes at redeployment of Application, as this increase the deployment time for most databases.

      To turn this feature on, add an entry to orion-application.xml as described in listing 12 below.


      <orion-application
          auto-alter-tables="true"
      />
      Listing 12: Turning automatic alteration of tables and columns on in the Application deployment configuration

    9.3 Automatic deletion of EJB CMP tables

      By default, Orion does not delete the database tables used by EJB CMP Beans at redeployment of Application.

      This feature can be turned on by adding an entry to orion-application.xml as described in listing 13 below.


      <orion-application
          auto-delete-tables="true"
      />
      Listing 13: Turning automatic deletion of EJB CMP tables on in the Application deployment configuration

      This feature is especially useful combined with automatic table creation during development when each redeployment should start off with a fresh database.

    9.4 Defining a default DataSource

      By defining a default DataSource to be used for the Application, this DataSource will be used as default for any DataSource reference added after this definition has been added.

      So for instance, if the default DataSource to use is defined to be "jdbc/MyOwnDS", an EJB-module containing a CMP Entity bean would be given a DataSource location of "jdbc/MyOwnDS".

      The default is to use the Server default DataSource. To configure the default DataSource to use any other valid CMT datasource (ejb-location), add an entry to orion-application.xml as described in listing 14 below.


      <orion-application
          default-data-source="jdbc/myOwnDS"
      />
      Listing 14: Turning automatic deletion of EJB CMP tables on in the Application deployment configuration

      Where jdbc/myOwnDS is the location of a valid CMT-datasource.

    9.5 Defining handling of zero for Primary Keys

      If the value of zero (0) is to be interpreted as null for EJB Entity Primary Keys, this can be configured by adding an entry like in listing 14 below to the Applications orion-application.xml file.


      <orion-application
          treat-zero-as-null="true"
      />
      Listing 15: Specifying that zero (0) should be interpreted as zero for Primary Keys

      By default, Orion differentiates between 0 and zero, just as any other Java application. This feature was added as some DBMS does not.

    9.6 EJB-module inclusion configuration

      EJB-modules that are part of the Application should be listed with a tag like in listing 16 below:


      <orion-application>
          <ejb-module remote="false" path="sampleBeans.jar" />
      </orion-application>
      Listing 16: An EJB-module entry in orion-application.xml

      Where the value of the path attribute is the absolute or relative (to the application's root) path to the EJB-module. The boolean value of the remote attribute specifies if the EJB-module is to be activated from this node (false) or from a remote node (true). For more information about remote modules, see the Remote Access documentation.

      The EJB-module entry can be used to add stand-alone EJB-modules to the global application as described in this section.

    9.7 Web-module inclusion configuration

      Web-modules that are part of the Application should be listed with a tag like in listing 17 below:


      <orion-application>
          <web-module id="myWebApp" path="sampleWeb.war" />
      </orion-application>
      Listing 17: A Web-module entry in orion-application.xml

      Where the value of the id attribute is the name to be used to reference this Web-module (such as when binding the Web-module to a site). The default value of the id attribute is the filename of the Web-module without any suffix. The path attribute is the absolute or relative (to the application's root) path to the Web-module.

      The Web-module entry can be used to add stand-alone Web-modules to the global application as described in this article.

    9.8 Client-module inclusion configuration

      Client-modules that are part of the Application should be listed with a tag like in listing 18 below:


      <orion-application>
          <client-module
              path="myappclient.jar"
          />
      </orion-application>
      Listing 18: A Client-module entry in orion-application.xml

      Where the value of the path attribute is the absolute or relative (to the application's root) path to the Client-module.

      A Client-module can also be configured to be launched in-process when the Server is started. Such a configuration would look like in listing 19 below:


      <orion-application>
          <client-module
              auto-start="true"
              path="myappclient.jar"
              user="theUser">
              <arguments>
                  <argument value="theValue" />
              </arguments<
          </client-module>
      </orion-application>
      Listing 19: An auto-starting Client-module entry in orion-application.xml

      Where the value of the auto-start attribute is set to true (the default is false) in order to have the Client-module to start when the Sever is started. The value of the user attribute should be set to the identity of the user that the Client-module should be run as. Any arguments that should be passed to the main method of the Client-modules main-class should be stated in the value of the value attribute in argument tags.

      The Client-module entry can be used to add stand-alone Client-modules to the global application as described in this section.

    9.9 Connector-module inclusion configuration

      Connector-modules that are part of the Application should be listed with a tag like in listing 20 below:


      <orion-application>
          <connector-module
              name="name"
              path="../applications/name.rar"
              default-location="env/eis/name"
          />
      </orion-application>
      Listing 20: A Connector-module entry in orion-application.xml

      Where the value of the name attribute is the name to be used to reference this Connector-module. The default value of the name attribute is the filename of the Connector-module without any suffix. The path attribute is the absolute or relative (to the application's root) path to the Connector-module. If needed, a default-location can be given that will be used as a base for JNDI-names for resource-adapters in the Connector module.

      The Connector-module entry can be used to add stand-alone Connector-modules to the global application as described in this article.

    9.10 Mapping security roles to Users/Groups

      The Orion default behaviour to handle mapping of Roles defined in a application.xml file (or the descriptor file of a stand-alone module such as web.xml) of an Application to Groups is to assume that the Role should be mapped to a Group with the same name as the Role .

      To change how roles are mapped to Users/Groups, use the security-role-mapping tag in the orion-application.xml file of the Application, as described in this article.


      <orion-application>
          <security-role-mapping name="shopkeeper">
              <group name="administrators">
          </security-role-mapping>
      </orion-application>
      Listing 21: A Role mapping entry in orion.application.xml. The entry maps the Role "shopkeepers" to the Group "administrators".

    9.11 Configuring persistence file path

      The Orion default behaviour is to store state over restarts in a directory called "persistence" within the deployment directory of the Application. To change this behaviour, set teh persistence file path as exemplified in listing 22 below:


      <orion-application>
          <persistence path="./persistence" />
      </orion-application>
      Listing 22: Specifying a persistence path

      Where the value of the path attribute is the absolute or relative (to the application's root) path to the locaion where Orion should persist state over restarts.

    9.12 Adding additional library paths

      Additional library paths can be added to the Application by adding library tags to the deployment settings of the Application, as exemplified in listing 23 below.


      <orion-application>
          <library path="../lib" />
      </orion-application>
      Listing 23: Specifying additional library paths for the Application

      Where the value of the path attribute is the absolute or relative (to the application's root) path to a directory, .jar or .zip file that should be added as library-paths to the Application.

      Notice that when specifying directories, these are scanned for .jar/.zip files during Application startup.

    9.13 Configuring path to principals file

      The default location for the principals.xml file that contains the Users and Groups for this application is at the root of the Applications deployment directory. To change this, follow the example given in listing 24 below:


      <orion-application>
          <principals path="./principals.xml" />
      </orion-application>
      Listing 24: Specifying the path to the principals.xml file

      Where the value of the path attribute is the absolute or relative (to the application's root) path to the principals.xml file of the Application.

    9.14 Configuring mail-sessions

      Any mail-session resource that the Application needs can be configured as exemplified in listing 25 below:


      <orion-application>
          <mail-session location="mail/mailSession" smtp-host="smtp.server.com">
              <description>description</description>
              <property name="mail.from" value="mail.sender@server.com" />
              <property name="mail.transport.protocol" value="smtp" />
              <property name="mail.smtp.from" value="mail.sender@server.com" />
          </mail-session>
      </orion-application>
      Listing 25: A sample mail-session resource

      Where the value of the location attribute is the JNDI location to bind the mail-session to and the value of the smtp-host attribute is the name or IP of the SMTP host to use. The mail-session can also be given an optional description by usage of the description subtag.

      Additional parameters can be stated by using the property subtag. This tag has two attributes, name and value which can hold the name and value of a property that should be given to the mail-session. Common parameters are "mail.from", "mail.transport.protocol" and "mail.stmp.from".


      Session session=(Session) new InitialContext().lookup("java:comp/env/mail/mailSession");
      MimeMessage message = new MimeMessage(session);
      message.setRecipient(Message.RecipientType.TO, new InternetAddress(address));
      message.setSubject(subject, "utf-8");
      message.setText(content,"utf-8");
      Transport.send(message);
      Listing 26: Sample usage of mail-session resource

    9.15 Configuring UserManager

      By default, Orion configures the Application to use the XMLUserManager. To use any other UserManager, add an entry like the one given in listing 26 below to orion-application.xml:


      <orion-application>
          <user-manager class="com.evermind.sql.DataSourceUserManager">
               <property name="groupMembershipGroupFieldName" value="group" />
               <property name="groupMembershipUsernameFieldName" value="Userid" />
               <property name="table" value="users" />
               <property name="passwordField" value="password" />
               <property name="groupMembershipTableName" value="user_groups" />
               <property name="usernameField" value="userid" />
               <property name="dataSource" value="<your data source>" />
          </user-manager>
      </orion-application>
      Listing 27: Configuring the use of a UserManager other than the default XMLUserManager

      Where the value of the class is a class that implements the com.evermind.security.UserManager interface. The UserManager can also be given an optional description by usage of the description subtag.

      Additional parameters can be stated by using the property subtag. This tag has two attributes, name and value which can hold the name and value of a property that should be given to the UserManager, as exemplified in listing 26 above.

      Further information about configuring UserManagers can be found at www.orionsuport.com.

    9.16 Configuring Application logging file

      By default, Orion writes Application log entries to a file named "application.log" in the deployment directory of the Application. The name and location of the file that the log entries should be written to can be changed, as exemplified in listing 28 below:


      <orion-application>
          <log>
          <file path="./application.log" />
          </log>
      </orion-application>
      Listing 28: Configuring a custom log file

      Where the value of the path attribute is the absolute or relative (to the application's root) path to the logfile to use for the Application.

    9.17 Configuring Application logging email notifications

      Orion can be configured to send email notifications when log entries are written. This feature requires that a mail-session is available. One or more email addresses can be listed as shown in listing 29 below.


      <orion-application>
          <log>
          <mail address="mail.receiver1@server.com" />
          <mail address="mail.receiver2@server.com" />
          </log>
      </orion-application>
      Listing 29: Configuring email addresses that should receive notifications of log entries

      Where the value of the address attribute should be a valid email address.

    9.18 Configuring a custom Application Logger

      Orion can be configured to send all log events to custom log classes as well as to the default logger. The custom log classes must implement the Logger interface. One or more custom log classes can be stated as shown in listing 30 below:


      <orion-application>
          <log>
          <logger class="com.acme.util.MyFileLogger" />
          <logger class="com.acme.util.MyJMSLogger" />
          </log>
      </orion-application>
      Listing 30: Configuring custom log classes

      Where the value of the class attribute should be a class implementing the Logger interface.

    9.19 Configuring path to DataSource configurations

      To specify an Application specific DataSource configuration file (data-sources.xml), add an entry as exemplified in listing 31 below:


      <orion-application>
         <data-sources path="./data-sources.xml" />
      </orion-application>
      Listing 31: Specifying the path to the data-sources.xml file.

      Where the value of the path attribute is the absolute or relative (to the application's root) path to the data-sources.xml file of the Application.

      More information about configuring DataSources can be found here.

    9.20 Configuring namespace read-access for RMI clients

      By default, Orion allows RMI-clients to read the namespace (naming context) only if the calling principal belongs to a Role mapped to the Group "administrators".

      Read access is configured as exemplified in listing 32 below:


      <orion-application>
          <namespace-access>
                  <read-access>
                      <namespace-resource root="">
                          <security-role-mapping name="<jndi-user-role>">
                              <group name="administrators" />
                          </security-role-mapping>
                      </namespace-resource>
                  </read-access>
          </namespace-access>
      </orion-application>
      Listing 32: Specifying the namespace read access policy.

      In the example above, the <jndi-user-role> is mapped to the Group "administrators", thereby granting any User that belongs to the Role that the Group "administrators" is mapped to read access to the namespace specified in the value of the root attribute in the namespace-resource tag, by including one or more group tags inside the role-mapping tag.

      Notice that any number of Groups can be specified inside the security-role-mapping tag for each namespace-resource root specified.

    9.21 Configuring namespace write-access for RMI clients

      By default, Orion allows RMI-clients to write to the namespace (naming context) only if the calling principal belongs to a Role mapped to the Group "administrators".

      Write access is configured as exemplified in listing 33 below:


      <orion-application>
          <namespace-access>
                  <write-access>
                      <namespace-resource root="">
                          <security-role-mapping name="<jndi-user-role>">
                              <group name="administrators" />
                          </security-role-mapping>
                      </namespace-resource>
                  </write-access>
          </namespace-access>
      </orion-application>
      Listing 33: Specifying the namespace write access policy.

      In the example above, the <jndi-user-role> is mapped to the Group "administrators", thereby granting any User that belongs to the Role that the Group "administrators" is mapped to write access to the namespace specified in the value of the root attribute in the namespace-resource tag, by including one or more group tags inside the role-mapping tag.

      Notice that any number of Groups can be specified inside the security-role-mapping tag for each namespace-resource root specified.

Copyright © 2005 IronFlare AB