| Skip Navigation Links | |
| Exit Print View | |
|
Oracle GlassFish Server 3.1 Application Deployment Guide |
1. Overview of Oracle GlassFish Server 3.1 Application Deployment
Deploying Applications and Modules
To Deploy an Application or Module
To Change Targets for a Deployed Application or Module
To List Deployed Applications or Modules
To Redeploy an Application or Module
To Disable an Application or Module
To Enable an Application or Module
To Undeploy an Application or Module
To Reload Changes to Applications or Modules Dynamically
To Deploy an Application or Module Automatically
To Deploy an Application or Module by Using a Deployment Plan
To Deploy an Application or Module in a Directory Format
Modifying the Configuration of a Web Application or Module
To Set a Web Context Parameter
To Unset a Web Context Parameter
To List Web Context Parameters
To Set a Web Environment Entry
To Unset a Web Environment Entry
To List Web Environment Entries
Web Module Deployment Guidelines
To Deploy and Configure a Stand-Alone Connector Module
Redeploying a Stand-Alone Connector Module
Deploying and Configuring an Embedded Resource Adapter
Assembling and Deploying an Application Client Module
To Assemble and Deploy an Application Client
To Prepare Another Machine for Running an Application Client
To Undeploy an Application Client
Lifecycle Module Deployment Guidelines
Web Service Deployment Guidelines
OSGi Bundle Deployment Guidelines
Transparent JDBC Connection Pool Reconfiguration
A. The asadmin Deployment Subcommands
B. GlassFish Server Deployment Descriptor Files
Note - The GlassFish Server Web Profile supports the EJB 3.1 Lite specification, which allows enterprise beans within web applications, among other features. The GlassFish Server Full Platform Profile supports the entire EJB 3.1 specification. For details, see JSR 318 (http://jcp.org/en/jsr/detail?id=318
The following guidelines apply to deploying an EJB module in GlassFish Server:
JNDI Name. — If no JNDI name for the EJB JAR module is specified in the jndi-name element immediately under the ejb element in glassfish-ejb-jar.xml, or there is no glassfish-ejb-jar.xml file, a default, non-clashing JNDI name is derived. A warning message is logged, recording the JNDI name used to look up the EJB JAR module.
Because the EJB 3.1 specification defines portable EJB JNDI names, there is less need for GlassFish Server specific JNDI names. By default, GlassFish Server specific default JNDI names are applied automatically for backward compatibility. To disable GlassFish Server specific JNDI names for an EJB module, set the value of the <disable-nonportable-jndi-names> element in the glassfish-ejb-jar.xml file to true. The default is false.
Stateful Session Bean and Timer State. — Use the --keepstate option of the redeploy(1) subcommand or the <keepstate> element in the glassfish-ejb-jar.xml file to retain stateful session bean instances and persistently created EJB timers across redeployments. The --keepstate option of the redeploy subcommand takes precedence. The default for both is false. This option is not supported and ignored in a clustered environment.
Some changes to an application between redeployments can prevent this feature from working properly. For example, do not change the set of instance variables in the SFSB bean class. Other examples would be changes to EJB names, or adding or removing EJBs to or from an application.
EJB Singletons. — EJB Singletons are created for each server instance in a cluster, and not once per cluster.
Stubs and Ties. — Use the get-client-stubs(1) subcommand in remote mode to retrieve stubs and ties.
Compatibility of JAR Visibility Requirements. — Use the compatibility element of the glassfish-application.xml or glassfish-ejb-jar.xml file to specify the GlassFish Server release with which to be backward compatible in terms of JAR visibility requirements for applications. The current allowed value is v2, which refers to GlassFish Server 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. Setting this element to v2 removes these Java EE 6 restrictions.
|