Web-module deployment

This article explains how to deploy a Web-module to the Orion Application Server.

1 Introduction

    This article provides a step-by-step guide to deploying an existing Web-module to an Orion Application Server. It also gives a brief overview of the structure of a Web-module. Information about deploying a full J2EE application can be found in the Application Deployment article.

2 The structure of a Web-module in brief

    This section briefly describes the structure of a J2EE Web-module.

    A J2EE Web-module is one of the J2EE Module types that are parts of a J2EE Application (others are EJB-modules, Client-modules and Connector-modules).

    A Web-module might be part of a J2EE application as described in the Application Deployment document.

    A Web-module consists of content, classes, JAR archives and a Web-module descriptor describing the Web-module. This is normally packaged into a .war file but doesn't have to be.

    Content could be things like JSP pages, HTML pages, images and so on. These are normally located at the root of a Web-module, or located in a subdirectory of the root.

    Classes such as Servlets, Filters, Beans and others are placed in a dedicated directory named /WEB-INF/classes/ under the root of a Web-module.

    JAR archives such as packaged Tag libraries, 3rd party utilities etc are located in a dedicated directory named /WEB-INF/lib/ under the root of a Web-module.

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


        /index.html
        /images/smiley.gif
        /WEB-INF/web.xml
        /WEB-INF/classes/bean.class
        /WEB-INF/lib/ejbtags.jar
        /WEB-INF/lib/helper.jar
    Listing 1: Web-module file structure example

    Using an unpackaged directory structure is very effective during development.

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

3 Deploying a standalone Web-module manually

    If the Web-module to deploy is not part of a J2EE application, the following steps can be followed to add it to the default application shipped with Orion:

    3.1 Step 1: Add the Web-module to the default Application

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


          <web-module
              id="name"
              path="../applications/name.war"
          />
      Listing 2: Adding a web entry to /orion/config/application.xml

      The syntax of the web-module tag can be found here.

      Replace id with the deployment name of the Web-module that will be used to reference it.

      Replace path with the path to the Web-module, either to the .war file or the root directory of an unpackaged Web-module (the directory holding the Web-modules WEB-INF directory).

    3.2 Step 2: Binding the Web-module to a Site (optional)

      If the Web-module should be accessible it needs to be bound to a Site. Step-by-step instructions for binding a deployed Web-module to a site can be found in the Web-module binding article.

4 Deployment configuration

    After a Web-module has been deployed (standalone or as part of a J2EE application), it is possible to modify its configuration by editing the generated orion-web.xml file. This file is normally located in the Web-modules directory within the deployment directory of the Application that the Web-module is part of (The default Application when adding standalone Web-modules). 


                    /orion/application-deployments/default/web-module name/orion-web.xml
    Listing 2: Location of the deployment configuration file if the Web-module was added to the default Application. Notice that "Web-module name" should be replaced with the actual name of the Web-module (including the .war suffix if was a packaged archive).

    Deployment configurations can be distributed with the Web-module by placing the orion-web-xml file within the WEB-INF directory (next to the web.xml file) of the Web-module. The container will then use the distributed deployment configuration file as base when deploying the Web-module for the first time. When re-deploying the Web-module the deployment configuration file of the Web-module's deployment directory will be used as base.

    The settings available for deployment configuration of a Web-module are:

    Please notice that the orion-web.xml file also allows for overriding the web.xml file of the Web-module. This is useful for overriding normal configuration settings in the web.xml file.

    4.1 Configuring auto-reloading of beans

      By default, Orion reloads any modified beans when they are accessed by other beans, Taglibraries or Scriptlets in JSP pages. To disable this feature, add an entry to orion-web.xml as described in listing 3 below. 


      <orion-web-app
          autoreload-jsp-beans="false"
      />
      Listing 3: Disabling auto-reloading of beans

      The value of the autoreload-jsp-bean attribute can be either "true" or "false".

    4.2 Configuring auto-reloading of included JSP pages

      By default, Orion reloads any modified JSP page including any JSP page they include. To disable the reloading of included pages (included by other JSP pages or Servlets), add an entry to orion-web.xml as described in listing 4 below. 


      <orion-web-app
          autoreload-jsp-pages="false"
      />
      Listing 4: Disabling auto-reloading of included JSP pages

      The value of the autoreload-jsp-pages attribute can be either "true" or "false".

    4.3 Configuring the default size of the output buffer

      The default output buffer size for Serlvet responses is 2048 bytes. To modify this value add an entry like in listing 5 below to the Web-module's orion-web.xml file. A larger buffer allows more content to be written before anything is actually sent to the client, thus providing the resource with more time to set appropriate status codes and headers. A smaller buffer decreases server memory load and allows the client to start receiving data more quickly. 


      <orion-web-app
          default-buffer-size="2048"
      />
      Listing 5: Specifying the output buffer size for Servlet responses

      Where the value of the default-buffer-size is a numeric value specifying the size of the Servlet response output buffer size.

    4.4 Configuring the default charset

      Orion sets the default character set for a Web-module to be "iso-8859-1" (latin 1). To change this value, add an entry like in listing 6 below to the Web-module's orion-web.xml file.


      <orion-web-app
          default-charset="iso-8859-1"
      />
      Listing 6: Specifying the default charset to use

      Where the value of the default-charset is a string representation of the charset to use as default. See RFC 2047 for more information about character encoding and MIME.

    4.5 Configuring development-mode

      Orion does not run in the slower development-mode by default, but can be told to do so by adding an entry like the one in listing 7 below to the Web-module's orion-web.xml file:


      <orion-web-app
          development="true"
      />
      Listing 7: Enabling development-mode

      The value of the development attribute can be either "true" or "false".

      When development-mode is turned on, the source code generated for JSP files will be in a slower and more readable form. Any classes for which source-code is available will be automatically compiled.

      More information about development-mode can be found in this article.

    4.6 Configuring directory browsing

      By default, Orion does not allow clients to browse directories without welcome-pages. To enable directory browsing for a Web-module, add an entry to its orion-web.xml as described in listing 8 below. 


      <orion-web-app
          directory-browsing="allow"
      />
      Listing 8: Enabling directory browsing

      Where the value of the directory-browsing attribute is either "allow" (for allowing directory browsing) or "deny". The default value is "deny".

    4.7 Configuring document root

      By default, Orion uses the root of the Web-module as the content root. To change the location of the document root, enter an entry like in listing 9 below:


      <orion-web-app
          document-root="./"
      />
      Listing 9: Configuring the document root

      Where the value of the document-root attribute is the absolute or relative (to the Web-module's root) path to the location to use as document root for the Web-module.

    4.8 Configuring the interval for file modification checks

      By default, Orion will check for file-modifications every 1000ms. To change this interval, add an entry like in listing 10 below:


      <orion-web-app
          file-modification-check-interval ="1000"
      />
      Listing 10: Configuring the interval for file-modification checks

      Where the value of the file-modification-check-interval attribute is the interval in milis. With value of 0 or less the files will always be checked.

    4.9 Configuring Locale handling for logged in Users

      By default, Orion tries to get the clients Locale by looking at the request headers. If so wanted, Orion can be configured to first try and get the Locale from the User if the client is a logged in User (This will only work if the Application stores Locale information with the Users and will potentially slow down execution).

      In order to activate this feature, add an entry like in listing 11 below to the orion-web.xml file of the Web-module:


      <orion-web-app
          get-locale-from-user ="true"
      />
      Listing 11: Enabling Locale lookup in User data

      Where the value of the get-locale-from-user attribute is either true or false, with false being the default due to the slowdown it might cause.

    4.10 Configuring JSP cache directory

      By default, Orion cache compiled JSP pages to file across server restarts in a directory named "persistence" in the Web-module's deployment directory. To change this behaviour, specify a cache directory like the example in listing 12 below.


      <orion-web-app
          jsp-cache-directory="./cache"
      />
      Listing 12: Specifying a directory for caching of JSP binaries across server restarts.

      Where the value of the jsp-cache-directory attribute is the absolute or relative (to the Web-module's root) path to the directory to use for caching JSP binaries across server restarts.

    4.11 Configuring JSP timeout

      By default, Orion never unloads JSP pages. To configure the timeout value after which JSP pages should be unloaded, add an entry like in listing 13 below:


      <orion-web-app
          jsp-timeout="100"
      />
      Listing 13: Specifying a timeout value after which JSP pages should be unloaded.

      Where the value of the jsp-timeout attribute is the number of seconds after which JSP pages should be unloaded from cache. Specifying a value of "never" (which is the default) will lead to that JSP pages are not unloaded.

    4.12 Configuring compilation error logging

      By default, Orion does not log compilation errors to the Application log. To enable this feature, add an entry like in listing 14 below:


      <orion-web-app
          log-compilation-errors="true"
      />
      Listing 14: Enabling Application logging of compilation errors.

      Where the value of the log-compilation-errors attribute is either true or false, with false being the default.

      Regardless of the value of this setting, Orion always writes compilation errors to the console window. This setting might prove useful if orion is running as a service, or the console window is unavailable for some other reason.

    4.13 Configuring persistence file path

      By default, Orion does not cache JSP binaries to file across server restarts. To change this behaviour, specify a cache directory like the example in listing 12 below.


      <orion-web-app
         persistence-path="./persistence/state.ser"
      />
      Listing 15: Specifying a directory for persisting HTTP sessions across server restarts.

      Where the value of the persistence-path attribute is the absolute or relative (to the Web-module's root) path to the file to use for persisting HTTP sessions across server restarts. Please notice that only Serializable or Remote objects can be persisted.

    4.14 Configuring Servlet invocation directory mapping

      By default, Orion will map the web-directory "/servlet/" to a Servlet invocation. To use another mapping, add an entry like in listing 16 below to the Web-module's orion-web.xml file:


      <orion-web-app
         servlet-webdir ="/myServlets/"
      />
      Listing 16: Specifying the web-directory to map to Servlet invocations

      Where the value of the servlet-webdir attribute is the web-directory to map Servlet invocations to.

    4.15 Configuring auto-compilation source directory

      When running Orion in development-mode, Orion will look for source files to auto-compile in the "WEB-INF/src/" directory if it exists, and then "WEB-INF/classes/". To initially look for source-files in another directory than "WEB-INF/src", add an entry like in listing 17 below:


      <orion-web-app
          source-directory="./mySourceDirectory"
      />
      Listing 17: Specifying a source-code directory to use when running Orion in development-mode.

      Where the value of the source-directory attribute is the absolute or relative (to the Web-module's root) path to the directory to search for source-code for auto-compilation when running Orion in development-mode.

    4.16 Configuring classnames of JSP intermediate sources

      By default, Orion running in development-mode stores the JSP intermediate source-files using the JSP filename. To store the source-files using the made-up class names, add an entry like the one shown in listing 17 below to the Web-module's orion-web.xml file.


      <orion-web-app
          store-source-by-classname="true"
      />
      Listing 18: Storing intermediate JSP source-files using the made-up classnames.

      Where the value of the store-source-by-classname attribute is either true or false, with false being the default.

      Using the default (store-source-by-classname="false"), the intermediate JSP source-file for index.jsp would be named "index.jsp.java", while setting store-source-by-classname to true would name the intermediate JSP source-file would be named "persistence__jspPage0_index_jsp.java".

    4.17 Configuring temporary directory for scrap-files

      By default, Orion configures the deployed Web-modules to use the directory "./temp" for scrap files. To configure the Web-module to use another directory, add an entry like the one in listing 19 below:


      <orion-web-app
          temporary-directory="./temp"
      />
      Listing 19: Defining what directory to use for temporary scrap files.

      Where the value of the temporary-directory attribute is the absolute or relative (to the Web-module's root) path to the directory to use for scrap files. The Web-module can look the directory up by issuing a code sniplet like the one shown in listing 20 below:


          ...
          File file = (File)application.getAttribute("javax.servlet.context.tempdir").
          ...
      Listing 20: Looking up the directory to use for temporary files.

      Notice that availability of a temporary directory is required by the JSP specification, but how to configure the temporary directory is up to the implementors.

    4.18 Configuring form-login mechanism

      By default, Orion forwards POST requests and redirects GET requests to the protected resource once the request has been authenticated. To configure the Web-module to use another behaviour, add an entry like the one shown in listing 2 below to the Web-module's orion-web.xml file.


      <orion-web-app
          form-login-mechanism="forward-post"
      />
      Listing 21: Specifying the login mechanism to use for form-based athentication.

      Where the value of the form-login-mechanism attribute is either "forward-post", "forward" or "redirect". The value of the form-login-mechanism is used to determine how the protected resource should be called once the client has been authenticated through form-based login. A value of "forward-post" will redirect any GET requests but forward POST requests. A value of "forward" will forward GET and POST while a value of "redirect" will redirect both GET and POST.

      Forwarding to the protected resource will leave "j_security_check" in the URL, which is ally considered bad as clients might bookmark the call to the form-login mechanism instead of the protected resource.

    4.19 Configuring additional classpaths

      Additional classpaths for serlvets/beans/etc can be configured by adding entries like in listing 21 below to the Web-module's orion-web.xml file.


      <orion-web-app>
          <classpath path="./path/to/classes/" />
          <classpath path="./path/to/other/classes/" />
      </orion-web>
      Listing 21: Defining additional classpath entires.

      Where the value of the path attribute in the classpath tag is the absolute or relative (to the Web-modules's root) path to a directory where classes used by this Web-module can be found.

    4.20 Configuring context parameters

      To override the value of a certain context parameter with a deployment specific value, add an entry like in listing 22 below to the Web-module's orion-web.xml file.


      <orion-web-app>
          <context-param-mapping name="theName">deploymentValue</context-param-mapping>
      </orion-web>
      Listing 22: Overriding context parameters.

      Where the name attribute of the context-param-mapping tag holds the name of the context parameter to override, and the body of the context-param-mapping tag holds the new value that should be given to the named context parameter.

    4.21 Configuring path to mime-mappings file

      To add a Web-module specific mime-mappings file, add an entry like in listing 23 below to the Web-module's orion-web.xml file.


      <orion-web-app>
          <mime-mappings path="./mime.types" />
      </orion-web>
      Listing 23: Specifying the mime-mappings file to use.

      Where the value of the path attribute in the mime-mappings tag is the absolute or relative (to the Web-modules's root) path to a mime-mapping file.

    4.22 Configuring virtual directories

      To include files that do not reside below the Web-modules document root, add a virtual directory as described in listing 24 below:


      <orion-web-app>
          <virtual-directory real-path="/usr/local/realpath" virtual-path="/the/webdir" />
      </orion-web>
      Listing 24: Specifying an additional virtual directory to mount as a web-directory.

      Where the value of the real-path attribute is the directory to mount as a web-directory at the location of the Web-module specified in the value of the virtual-path attribute.

      Below is an example where the directory /usr/local/greg/research has been added as a vritual directory to the Web-module located at /usr/local/orion/default-web-app at the web-directory /greg/research:


      <orion-web-app>
          <virtual-directory real-path="/usr/local/greg/research" virtual-path="/greg/research" />
      </orion-web>
      Listing 25: Example usage of virtual-directory that will be available at "http://localhost/greg/research".

    4.23 Configuring access-mask

      Access to the Web-module can be restricted by the use of an access-mask. The access-mask is set up to either allow or deny all by default, and can then contain specific ip addresses and/or domain names that should be allowed or denied explicitly.

      Normally, an access-mask that allows access for all contains a table with ip addresses and/or domain names that should not be allowed, while an access-mask that denies access for all contains a table with ip addresses and/or domain names that should be allowed.

      Listing 26 below shows a sample usage of access-mask configuration in the Web-modules orion-web.xml file.


      <orion-web-app>
          <access-mask default="allow">
              <host-access domain="the.hostordomain.com" mode="deny" />
              <ip-access ip="123.124.125.126" mode="deny" netmask="255.255.255.0" />
          </access-mask default>
      </orion-web>
      Listing 26: Sample access-mask usage that allows access to all but for the named domain and ip address.

      In the listing above, the access-mask tag is set to allow access by default. The host-access tag is used with the value of the attribute domain set to a domain to deny access to (deny is the value of the mode attribute). This tag is then followed by a ip-access tag with the value of the ip attribute set to a ip to deny access to (deny is the value of the mode attribute), affecting host/domain according to the value of the netmask attribute.

      Please notice that the access-mask tag can contain any number of host-access and/or ip-access tags.

    4.24 Configuring cluster participation

      In order for the Web-module to participate in a cluster it has to have clustering information, as exemplified in listing 27 below:


      <orion-web-app>
          <cluster-config host="230.0.0.1" id="123" port="9127" />
      </orion-web>
      Listing 27: Sample cluster configuration entry.

      Where the value of the host attribute should be a Multicast host to use for cluster communication together with the value of the port attribute that should be the port to use for the cluster communication. The value of the id attribute should be the identifier for this Web-module within the cluster.

      By default, values bound to the ServletContext is not distributed to the cluster as the Servlet specification advises against it. Listing 28 below shows how this behavour can be overriden so that values bound/rebound/unbound to the ServletContext will be distributed within the cluster.


      <orion-web-app
          replicate-servlet-context="true"
      >
      </orion-web>
      Listing 28: Allowing ServletContext to be distributed.

      Where the value of the replicate-servlet-context attribute should be either "true" or "false" (default).

      For more information about clustering Web-modules, please read the HTTP state replication article.

    4.25 Configuring mime-type based Servlet invocation

      Orion allows for a Servlet to be invoked whenever a request is made for content of a certain mime-type. This is configured as exemplified in listing 29 below:


      <orion-web-app>
          <servlet-chaining servlet-name="xsl" mime-type="text/xml" />
      </orion-web>
      Listing 29: Sample servlet chaining configuration entry

      Where the value of the servlet-name attribute should contain the name of the Servlet to be invoked whenever a mime-type corresponding to the value of the mime-type attribute is requested.

      This feature is commonly used for filtering/transforming certain kinds of output.

    4.26 Configuring request tracking Servlets

      Orion allows for a Servlet to be invoked whenever a Request is made to the Web-module. This is done by adding an entry like in listing 30 below to the Web-module's orion-web-xml file.


      <orion-web-app>
          <request-tracker servlet-name="servletName" />
      </orion-web>
      Listing 30: Sample request tracking configuration entry

      Where the value of the servlet-name attribute is the name of the Servlet to invoke on each request to the Web-module.

      This feature is commonly used for logging purposes and other such tasks.

    4.27 Configuring Servlet filters

      To use Servlets to filter requests made to the Web-module, add an entry like the one in listing 31 below to the Web-module's orion-web-xml file.


      <orion-web-app>
          <servlet-filter servlet-name="servletName" url-pattern="/the/*.pattern" />
      </orion-web>
      Listing 31: Sample Servlet filter configuration entry

      Where the value of the servlet-name attribute is the name of the Servlet to invoke on each request to the Web-module and the value of the optional url-pattern attribute is the URL pattern qualifier.

      The configured Servlet filter may handle the request or simply ignore it, in which case the request is passed on to "normal" processing.

    4.28 Configuring Session tracking

      By default, Orion utilizes cookies to maintain client sessions. If the client cannot use cookies, Orion will utilize URL rewriting (appending the session identifier to all relative URLs) for the Web-module.

      To modify this behaviour, add an entry like the one in listing 32 below:


      <orion-web-app>
          <session-tracking
              autoencode-absolute-urls="false"
              autoencode-urls="true"
              autojoin-sessions="false"
              cookie-domain=".mydomain.com"
              cookie-max-age="in memory only"
              cookies="enabled" />
      </orion-web>
      Listing 32: Sample session tracking configuration entry

      Setting the boolean value of the autoencode-absolute-urls attribute to "true" would tell Orion to rewrite abolute URLs in JSP pages and append any session identifier to them. By default, Orion does not rewrite absolute URLs.

      Setting the boolean value of the autoencode-urls attribute to "true" would tell Orion to rewrite relative URLs in JSP pages and append any session identifier to them. By default, Orion does rewrite relative URLs.

      Setting the boolean value of the autojoin-sessions attribute to "true" would tell Orion that the client should be given a session as soon as the client accesses the site. The default value is "false".

      The value of the cookie-domain attribute can be used to specify the domain the cookies are relevant for. By default Orion does not specify a cookie domain. This setting is often used to share cookie information between nodes of a Web-module running on different hosts.

      The numeric value of the cookie-max-age tells the client for how many seconds to keep record of cookies. If this value is not specified, cookies are kept in memory during a browser session and discarded afterwards.

      By default, Orion tries to primary use cookies for session tracking. This feature can be turned off by specifying a value of "disable" for the cookies attribute.

      Please notice that if both autoencoding and cookies are disabled, sessions cannot be maintained within sites that are not using SSL Sessions.

    4.29 Configuring a session tracking Servlets

      Orion allows for a Servlet to be invoked whenever a session is created. This is done by adding an entry like in listing 33 below to the Web-module's orion-web-xml file.


      <orion-web-app>
          <session-tracking>
              <session-tracker servlet-name="servletName" />
          </session-tracking>
      </orion-web>
      Listing 33: Sample session tracking configuration entry

      Where the value of the servlet-name attribute is the name of the Servlet to invoke whenever a session is created.

      This feature is commonly used for logging purposes and other such tasks.

    4.30 Configuring resource reference mappings

      A Web-module uses JNDI to lookup resources in its context. These JNDI names needs to be mapped to an actual resource JNDI location. By default, Orion maps the default resource of the specified type to the resource reference of the Web-module. As an example, any DataSource resource references the Web-modules has would be mapped to the first configured DataSource available. In order to change this behaviour, add an entry like the one shown in listing 34 below to the Web-modules orion-web.xml file:


      <orion-web-app>
              <resource-ref-mapping location="jdbc/HyperSonicDS" name="jdbc/myDS"/>
      </orion-web>
      Listing 34: Mapping a resource reference to a resource

      Where the value of the location attribute would be the JNDI location of the previously defined resource and map this to the name specified in the name attribute. Notice that the name attribute should match the resource-ref defined in the Web-modules web.xml file.


      ...
      Context context=new InitialContext();
      DataSource ds=(DataSource)context.lookup("java:comp/env/jdbc/myDS");
      ...
      Listing 35: Example of looking up a DataSource

      If the resource needs to be looked up from another context than the default one, such as when using a external third party resource, an entry like the one describe in listing 36 below can be used:


      <orion-web-app>
              <resource-ref-mapping location="jdbc/HyperSonicDS" name="jdbc/myDS">
                  <lookup-context location="foreign/resource/location">
                      <context-attribute name="java.naming.factory.initial" value="classname" />
                      <context-attribute name="name" value="value" />
                  </lookup-context>
              </resource-ref-mapping>
      </orion-web>
      Listing 36: Specifying the context to use when looking up the resource

      Where the value of the location attribute would be the name used to lookup the resource in the foreign context.

      Additional context attributes can be specified by using the context-attribute tag where the name attribute holds the name and the value attribute holds the value for each name-value pair.

      Please notice that the context attribute named "java.naming.factory.initial" is an obligatory attribute that should have the context factory class as its value.

    4.31 Configuring environment entries

      To override the value of a certain environment entry with a deployment specific value, add an entry like in listing 37 below to the Web-module's orion-web.xml file.


                 <orion-web-app>
                     <env-entry-mapping name="theName">deploymentValue</env-entry-mapping>
                 </orion-web>
      Listing 37: Overriding environment entries.

      Where the name attribute of the env-entry tag holds the name of the environment entry to override, and the body of the env-entry-mapping tag holds the new value that should be given to the named environment entry.

    4.32 Mapping security roles to Users/Groups

      The Orion default behaviour to handle mapping of Roles defined in a web.xml file of a Web-module 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-web.xml file of the Web-module, as described in this article.


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

      If the Web-module is part of a J2EE Application it is enough to specify the role-mappings in the orion-application.xml file as described in the Application deployment article. Any mapping defined in the deployment descriptor of the J2EE Application would be inherited by its Web-modules. The Web-module would still be able to override any such mappings.

    4.33 Configuring EJB references

      A Web-module uses JNDI to lookup EJBs in its context. These JNDI names need to be mapped to an actual JNDI locations of EJBs with home/remote interfaces (local-home/local for Locals) matching the specified home/remote (local-home/local for Locals) interfaces of the ejb-reference in the Web-module's web.xml file. By default, Orion maps the ejb-reference to the first encountered EJB that matches the home/remote (or local-home/local) interfaces specified in the ejb-reference tag in the Web-module's web.xml file. As multiple EJBs might be using the same home/remote (or local-home/local) interfaces, it is sometimes necessary to manually configure the mapping between the ejb-reference and the actual EJB. This is done through entries like the one shown in listing 39 below.


      <orion-web-app>
          <ejb-ref-mapping location="ejb/thePayroll" name="ejb/myPayroll"/>
      </orion-web-app>
      Listing 39: Mapping an ejb-reference to the location of an EJB.

      Where the value of the name attribute would be the name used by the Web-module to reference the EJB (and that matches the name specified in the ejb-ref of the Web-modules web.xml file). The value of the location would the the JNDI location of the actual EJB (and match the location value for the EJBs entry in its EJB-mobules orion-ejb-jar.xml file).


      ...
      Context context=new InitialContext();
      LocalPayRollHome payroll=(LocalPayRollHome)context.lookup("java:comp/env/ejb/myPayroll");
      ...
      Listing 40: Example of looking up an EJB from within a Web-module.

    4.34 Configuring extension handlers

      Servlets can be configured to handle content with a certain file extension. This is normally used to allow integration with 3rd party content handlers such as PHP, CGI, etc. To add a content handler, add an entry like in listing 41 to the Web-modules orion-web-xml file.


      <orion-web-app>
          <mime-mapping-deployment extension="txt" request-handler="myServlet"/>
      </orion-web-app>
      Listing 41: Specifying a handler for a certain file extenssion.

      Where the value of the extension attribute specifies the file extension that the handler Servlet specified in the value of the request-handler attribute should handle.

      With an entry like in listing 41 above, any request ending with a "txt" extension would be handled to the Servlet named "myServlet" (as configured in the Web-module's web.xml file).

    4.35 Configuring expiration settings

      Caching policies can be configured by adding an entry like in listing 42 below:


      <orion-web-app>
          <expiration-setting expires="never" url-pattern="*.gif"/>
      </orion-web-app>
      Listing 42: Specifying a cache timeout period for all content that matches the given pattern.

      Where the value of the expires attribute specifies the number of seconds after which the content matching the value of the url-pattern attribute should be considered expired. By setting the value of the expires attribute to "never", the client is told that the content should never expire.

Copyright © 2005 IronFlare AB