application (Oracle GlassFish Server 3.0.1 Domain File Format Reference)

Oracle GlassFish Server 3.0.1 Domain File Format Reference

`application`

Specifies a system application, a Java EE module or application, or an application created using another supported technology such as JRuby.

The application element replaces the web-module, j2ee-application, appclient-module, connector-module, lifecycle-module, extension-module, and ejb-module elements of previous releases, which are converted to application elements during the upgrade process.

Superelements

system-applications, applications

Subelements

The following table describes subelements for the application element.

Table 1–8 application Subelements


Element	Required	Description
`module`	one or more	Specifies a stand-alone module or a component of a Java EE application.
`engine`	one or more	Specifies an engine.
`property`	zero or more	Specifies a property or a variable.

Attributes

The following table describes attributes for the application element.

Table 1–9 application Attributes


Attribute	Default	Description
`name`	none	The name of the application.
`description`	none	(optional) Specifies a text description of this element.
`location`	none	(optional) The location of the application in the GlassFish Server file system. If a relative path is specified, it is relative to the `domain-dir/applications/` directory. Note – Deployment directories may change between GlassFish Server releases.
`libraries`	none	(optional) Specifies a comma-separated list of absolute or relative paths to libraries specific to this module or application. A relative path is relative to `domain-dir/lib/applibs`. If the path is absolute, the path must be accessible to the domain administration server (DAS), which means it must be under `domain-dir`. The libraries are made available to the application in the order in which they are specified.
`object-type`	`user`	(optional) Defines the type of the resource. For an application, the only allowed value is `user`.
`enabled`	`true`	(optional) Determines whether the application is enabled.
`context-root`	none	(optional) The context root at which the application is deployed. The context root can be the empty string or just `/`. The context root can start with the `/` character, but doesn’t have to.
`directory-deployed`	`false`	(optional) Specifies whether the application has been deployed as a directory.

Properties

The following table describes properties for the application element. These properties are specified during deployment using one of the following:

The ---–property or ---–properties option of the asadmin deploy command. For more information, see deploy(1).
The properties table on the deployment page for the application or module type in the Administration Console. For more information, see the Administration Console Online Help.

The properties that are valid for a given application depend on the sniffer attribute values of the child or grandchild engine elements.

Table 1–10 application Properties


Property	Default	Description
`java-web-start-enabled`	`true`	Specifies whether Java Web Start access is permitted for an application client module.
`jar-signing-alias`	`s1as`	Specifies the alias for the security certificate with which the application client container JAR file is signed. Java Web Start won't execute code requiring elevated permissions unless it resides in a JAR file signed with a certificate that the user's system trusts. For your convenience, GlassFish Server signs the JAR file automatically using the self-signed certificate from the domain, `s1as`. Java Web Start then asks the user whether to trust the code and displays the GlassFish Server certificate information. To sign this JAR file with a different certificate, add the certificate to the domain keystore, then use this property. To add a certificate to the domain keystore, see Administering JSSE Certificates in Oracle GlassFish Server 3.0.1 Administration Guide. For example, you can use a certificate from a trusted authority, which avoids the Java Web Start prompt, or from your own company, which users know they can trust.
`class-name`	none	The fully qualified name of a lifecycle module class file. A lifecycle module class must implement the com.sun.appserv.server.LifecycleListener interface.
`classpath`	value of `application-root` attribute of `domain` element	The classpath for a lifecycle module. Specifies where the module is located.
`load-order`	none	Determines the order in which lifecycle modules are loaded at startup. Modules with smaller integer values are loaded sooner. Values can range from `101` to the operating system’s `MAXINT`. Values from `1` to `100` are reserved.
`is-failure-fatal`	`false`	Determines whether the server is shut down if a lifecycle module fails.
`keepSessions`	`false`	If `true`, specifies that active sessions of the application being redeployed are preserved and then restored when redeployment is complete. If any active session of the application fails to be preserved or restored, none of the sessions are available when the redeployment is complete. However, redeployment continues and a warning is logged. To preserve active sessions, the GlassFish Server serializes the sessions and saves them in memory. To restore the sessions, the class loader of the newly redeployed application deserializes any sessions that were previously saved.
`compatibility`	none (no backward compatibility)	Specifies the GlassFish Server release with which to be backward compatible in terms of JAR visibility requirements for applications. The only allowed value is `v2`, which refers to GlassFish version 2 or GlassFish Server version 9.1 or 9.1.1. The Java EE 6 platform specification imposes stricter requirements than Java EE 5 did on which JAR files can be visible to various modules within an EAR file. In particular, application clients must not have access to EJB JAR files or other JAR files in the EAR file unless references use the standard Java SE mechanisms (extensions, for example) or the Java EE `library-directory` mechanism. Setting this property to `v2` removes these Java EE 6 restrictions.
`jruby.home`	`as-install/jruby`	Specifies the directory where JRuby itself (not the GlassFish Server JRuby container) is installed. Overrides the `jruby-home` attribute of `jruby-container`.
`jruby.runtime`	`1`	Specifies the initial number of JRuby runtimes to start. Must be at greater than zero, at least `jruby.runtime.min`, and `jruby.runtime.max` or less. Overrides the `jruby-runtime` attribute of `jruby-runtime-pool`.
`jruby.runtime.min`	`1`	Specifies the minimum number of JRuby runtimes in the pool. Must be greater than zero, `jruby.runtime` or less, and `jruby.runtime.max` or less. Overrides the `jruby-runtime-min` attribute of `jruby-runtime-pool`.
`jruby.runtime.max`	`1`	Specifies the maximum number of JRuby runtimes in the pool. Must be greater than zero, at least `jruby.runtime.min`, and at least `jruby.runtime`. Overrides the `jruby-runtime-max` attribute of `jruby-runtime-pool`.
`jruby.rackEnv`	`development`	Specifies the environment in which a JRuby application such as Rails or Merb runs. Allowed values are `development`, `production`, or `test`.
`jruby.applicationType`	Computed through auto-detection	Specifies the name of a supported framework or the path to a script that initializes the user's framework. Allowed values corresponding to supported frameworks are `rails`, `merb`, or `sinatra`. Setting this property bypasses the normal, and potentially lengthy, auto-detection process and forces deployment on the specified framework. If the deployed application is not written for the specified framework, errors result.
`jruby.MTSafe`	Computed through auto-detection	If `true`, specifies that a framework being started using `jruby.applicationType` is thread-safe and therefore does not need a pool created for it. This property affects applications started using an auto-detected user-provided startup script. If `jruby.applicationType` is set and `jruby.MTsafe` is not set or is set to `false`, the application starts with a pool of application instances, and each instance of the application is accessed by one thread at a time. This property only affects frameworks being launched where the thread safety cannot be automatically determined. Setting `jruby.MTsafe` to `true` does not cause an auto-detected Rails 2.1.`x` application to be launched in thread-safe mode, nor can it be used to force a thread-safe framework to start in pooled mode.