Previous Contents Index Next |
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Update 2 Administration Guide

> ## Chapter 13
> Deploying Applications

> This chapter describes how to deploy various Sun Java System Application Server modules and applications.

> Sun Java System Application Server modules and applications include J2EE standard elements and Sun Java System Application Server specific elements. Only Sun Java System Application Server specific elements are described in detail in this chapter.

> To know about packaging and assembling modules and applications for deployment, see the Sun Java System Application Server Developer’s Guide.

> This chapter includes the following topics:

> - About J2EE Modules
> - About J2EE Applications
> - J2EE Standard Descriptors
> - Application Server Descriptors
> - Naming Standards
> - Deployment Directory Structure
> - Runtime Environments
> - About Classloaders
> - Deploying Modules and Applications
> - The Application Deployment Descriptor Files

> ##

> About J2EE Modules

> A J2EE module is a collection of one or more J2EE components of the same container type with deployment descriptors of that type. One descriptor is J2EE standard, the other is Sun Java System Application Server specific. Types of J2EE modules are as follows:

> - Web Application Archive (WAR): A web application is a collection of servlets, HTML pages, classes, and other resources that can be bundled and deployed to several J2EE application servers. A WAR file can consist of the following items: servlets, JSPs, JSP tag libraries, utility classes, static pages, client-side applets, beans, bean classes, and deployment descriptors (web.xml and optionally sun-web.xml).
> - EJB JAR File: The EJB JAR file is the standard format for assembling enterprise beans. This file contains the bean classes (home, remote, local, and implementation), all of the utility classes, and the deployment descriptors (ejb-jar.xml and optionally sun-ejb-jar.xml). If the EJB is an entity bean with container managed persistence, a CMP deployment descriptor, sun-cmp-mapping.xml, may be included as well.
> - Application (RMI/IIOP) Client JAR File: An RMI/IIOP Client is a Sun Java System Application Server specific type of J2EE client. An RMI/IIOP Client supports the standard J2EE Application Client specifications, and in addition, supports direct access to the Sun Java System Application Server. Its deployment descriptors are application-client.xml and optionally sun-application-client.xml.
> - Resource RAR File: RAR files apply to J2EE CA connectors. A connector module is like a device driver. It is a portable way of allowing EJBs to access a foreign enterprise system. Each Sun Java System Application Server connector has a J2EE XML file, ra.xml. A connector must also have a Sun Java System Application Server deployment descriptor, sun-ra.xml.

> Package definitions must be used in the source code of all modules so the classloader can properly locate the classes after the modules have been deployed.

> Because the information in a deployment descriptor is declarative, it can be changed without requiring modifications to source code. At run time, the J2EE server reads this information and acts accordingly.

> EJB JAR and Web modules can also be assembled as separate .jar or .war files and deployed separately, outside of any application.

> ##

> About J2EE Applications

> A J2EE application is a logical collection of one or more J2EE modules tied together by application deployment descriptors. Components can be assembled at either the module or the application level. Components can also be deployed at either the module or the application level.

> Components are assembled into modules and then assembled into a Sun Java System Application Server application .ear file ready for deployment.

> Each module has a Sun Java System Application Server deployment descriptor and a J2EE deployment descriptor. The Sun Java System Application Server Administration interface uses the deployment descriptors to deploy the application components and to register the resources with the Sun Java System Application Server.

> An application consists of one or more modules, an optional Sun Java System Application Server deployment descriptor, and a required J2EE application deployment descriptor. All items are assembled, using the Java ARchive (.jar) file format, into one file with an extension of .ear.

> ##

> J2EE Standard Descriptors

> The J2EE platform provides assembly and deployment facilities. These facilities use JAR files as the standard package for components and applications, and XML-based deployment descriptors for customizing parameters. For more information on the J2EE assembly and deployment process, see Developing Enterprise Applications with the J2EE, v 1.0, Chapter 7.

> The J2EE standard deployment descriptors are described in the J2EE specification, v1.3.

> To check the correctness of these deployment descriptors prior to deployment, see the information on the deployment descriptor verifier in the Sun Java System Application Server Developer’s Guide.

> Table 13-1 shows where to find more information about J2EE standard deployment descriptors. The left column lists the deployment descriptors, and the right column lists where to find more information about those descriptors.

> Table 13-1 J2EE Standard Descriptors

> Deployment Descriptor | Where to Find More Information
> --- | ---
> application.xml | Java 2 Platform Enterprise Edition Specification, v1.3, Chapter 8, “Application Assembly and Deployment - J2EE:application XML DTD”
> web.xml | Java Servlet Specification, v2.3 Chapter 13, “Deployment Descriptor,” and JavaServer Pages Specification, v1.2, Chapter 7, “JSP Pages as XML Documents,” and Chapter 5, “Tag Extensions”
> ejb-jar.xml | Enterprise JavaBeans Specification, v2.0, Chapter 16, “Deployment Descriptor”
> application-client.xml | Java 2 Platform Enterprise Edition Specification, v1.3, Chapter 9, “Application Clients - J2EE:application-client XML DTD”
> ra.xml | Java 2 Enterprise Edition, J2EE Connector Architecture Specification, v1.0, Chapter 10, “Packaging and Deployment.”

> You can find specifications here:

> http://java.sun.com/products/

> ##

> Application Server Descriptors

> Sun Java System Application Server uses additional deployment descriptors for configuring features specific to the Sun Java System Application Server. These are optional except for the sun-ra.xml file, which is required for a connector module.

> To check the correctness of these deployment descriptors prior to deployment, see the information on the deployment descriptor verifier in the Sun Java System Application Server Developer’s Guide.

> Table 13-2 shows where to find more information about Sun Java System Application Server deployment descriptors. The left column lists the deployment descriptors, and the right column lists where to find more information about those descriptors.

> Table 13-2 Sun Java System Application Server Descriptors

> Deployment Descriptor | Where to Find More Information
> --- | ---
> sun-application.xml | The Application Deployment Descriptor Files.
> sun-web.xml | Sun Java System Application Server Developer’s Guide to Web Applications
> sun-ejb-jar.xml and sun-cmp-mapping.xml | Sun Java System Application Server Developer’s Guide to Enterprise Java Beans
> sun-application-client.xml and sun-acc.xml | Sun Java System Application Server Developer’s Guide to Clients
> sun-ra.xml | Sun Java System J2EE CA Service Provider Implementation Administrator’s Guide

> Note | The Sun Java System Application Server deployment descriptors must have 600 level access privileges on UNIX systems.

> The DTD schema files for all the Sun Java System Application Server deployment descriptors are located in the install_dir/appserv/lib/dtds directory.

> ##

> Naming Standards

> Names of applications and individually deployed EJB JAR, WAR, and connector RAR modules (as specified by the name attributes in the server.xml file) must be unique in the Sun Java System Application Server. If you do not explicitly specify a name, the default name is the first portion of the file name (without the .war or .jar extension). For details about server.xml, see the Sun Java System Application Server Administrator’s Configuration File Reference.

> Modules of different types can have the same name within an application, because when the application is deployed, the directories holding the individual modules are named with _jar, _war and _rar suffixes. Modules of the same type within an application must have unique names. In addition, database schema file names must be unique within an application.

> Using a Java package-like naming scheme is recommended for module filenames, EAR filenames, module names as found in the <module-name> portion of the ejb-jar.xml files, and EJB names as found in the <ejb-name> portion of the ejb-jar.xml files. The use of this package-like naming scheme ensures that name collisions do not occur. The benefits of this naming practice apply not only to the Sun Java System Application Server, but to other J2EE application servers as well.

> JNDI lookup names for EJBs must also be unique. Here too, establishing a consistent naming convention may help. For example, appending the application name and the module name to the EJB name would be one way to guarantee unique names. In this case, mycompany.pkging.pkgingEJB.MyEJB would be the JNDI name for an EJB in the module pkgingEJB.jar, which is packaged in the application pkging.ear.

> Make sure your package and file names do not contain spaces or characters that are illegal for your operating system.

> ##

> Deployment Directory Structure

> When you deploy an application, the directories holding the individual modules are named with _jar, _war and _rar suffixes. If you use the asadmin deploydir command to deploy a directory instead of an EAR file, your directory structure must follow this convention.

> Module and application directory structures follow the structure outlined in the J2EE specification.

> Here is an example directory structure of a simple application containing a web module, an EJB module, and a client module.

> + converter_1/ |--- converterClient.jar |--+ META-INF/ | |--- MANIFEST.MF | |--- application.xml | '--- sun-application.xml |--+ war-ic_war/ | |--- index.jsp | |--+ META-INF/ | | |--- MANIFEST.MF | '--+ WEB-INF/ | |--- web.xml | '--- sun-web.xml |--+ ejb-jar-ic_jar/ | |--- Converter.class | |--- ConverterBean.class | |--- ConverterHome.class | '--+ META-INF/ | |--- MANIFEST.MF | |--- ejb-jar.xml | '--- sun-ejb-jar.xml '--+ app-client-ic_jar/ |--- ConverterClient.class '--+ META-INF/ |--- MANIFEST.MF |--- application-client.xml '--- sun-application-client.xml

> Here is an example directory structure of an individually deployed connector module.

> + MyConnector/ |--- readme.html |--- ra.jar |--- client.jar |--- win.dll |--- solaris.so '--+ META-INF/ |--- MANIFEST.MF |--- ra.xml '--- sun-ra.xml

> ##

> Runtime Environments

> Whether you deploy a component as an individually deployed module or as an application, deployment affects both the file system and the server configuration. See the Module Runtime Environment and Application Runtime Environment figures.

> #### Module Runtime Environment

> The following figure, Module Runtime Environment, illustrates the environment for individually deployed module-based deployment.

> Figure 13-1 Module Runtime Environment

> For file system entries, modules are extracted as follows:

> instance_dir/applications/j2ee-modules/module_name
> instance_dir/generated/ejb/j2ee-modules/module_name
> instance_dir/generated/jsp/j2ee-modules/module_name

> The generated/ejb directory contains stubs and ties; the generated/jsp directory contains compiled JSPs.

> Lifecycle modules are extracted as follows:

> instance_dir/applications/lifecycle-modules/module_name

> Configuration entries are added in server.xml as follows:

> <server>
> <applications>
> <type-module>
> ...module configuration...
> </type-module>
> </applications>
> </server>

> The type of the module in server.xml can be lifecycle, ejb, web, or connector. For details about server.xml, see the Sun Java System Application Server Administrator’s Configuration File Reference.

> #### Application Runtime Environment

> Figure 13-2 illustrates the environment for application-based deployment.

> Figure 13-2 Application Runtime Environment

> For file system entries, applications are extracted as follows:

> instance_dir/applications/j2ee-apps/app_name
> instance_dir/generated/ejb/j2ee-apps/app_name
> instance_dir/generated/jsp/j2ee-apps/app_name

> The generated/ejb directory contains stubs and ties; the generated/jsp directory contains compiled JSPs.

> Configuration entries are added in server.xml as follows:

> <server>
> <applications>
> <j2ee-application>
> ...application configuration...
> </j2ee-application>
> </applications>
> </server>

> For details about server.xml, see the Sun Java System Application Server Administrator’s Configuration File Reference.

> ##

> About Classloaders

> Understanding Sun Java System Application Server classloaders can help you determine where and how you can position supporting JAR and resource files for your modules and applications.

> In a Java Virtual Machine (JVM), the classloaders dynamically load a specific java class file needed for resolving a dependency. For example, when an instance of java.util.Enumeration needs to be created, one of the classloaders loads the relevant class into the environment. For a more detailed discussion on Classloaders, see the Sun Java System Application Server Developer’s Guide.

> ##

> Deploying Modules and Applications

> This section describes the different ways to deploy J2EE applications and modules to the Sun Java System Application Server. It covers the following topics:

> - Deployment Names and Errors
> - The Deployment Life Cycle
> - Using Availability Features (Enterprise Edition)
> - Deploying a Module or Application
> - Deploying a WAR Module
> - Deploying an EJB JAR Module
> - Deploying a Lifecycle Module
> - Deploying an RMI/IIOP Client
> - Deploying a J2EE CA Resource Adapter
> - Deploying Static Content
> - Access to Shared Frameworks

> ### Deployment Names and Errors

> A unique name is generated in the server.xml file when you deploy an application or module. Do not change this name. During deployment, the server detects any name collisions and does not load an application or module having a non-unique name. Messages are sent to the server log when this happens. For more about naming, see Naming Standards.

> If an error occurs during deployment, the application or module is not deployed. If a module within an application contains an error, the entire application is not deployed.

> For details about server.xml, see the Sun Java System Application Server Administrator’s Configuration File Reference.

> ### The Deployment Life Cycle

> After an application is initially deployed, it may be modified and reloaded, redeployed, disabled, reenabled, and finally undeployed (removed from the server). This section covers the following topics related to the deployment life cycle:

> - Dynamic Deployment
> - Disabling a Deployed Application or Module
> - Dynamic Reloading

> #### Dynamic Deployment

> You can deploy, redeploy, and undeploy an application or module without restarting the server. This is called dynamic deployment. Note that if you change the deployment settings when you redeploy you have to restart the server.

> Although primarily for developers, dynamic deployment can be used in operational environments to bring new applications and modules online without requiring a server restart. Whenever a redeployment is done, the sessions at that transit time become invalid. The client must restart the session.

> #### Disabling a Deployed Application or Module

> You can disable a deployed application or module without removing it from the server. Each application and module has an enabled attribute in the server.xml file and a corresponding option in the Administration interface, which you can change. For details about server.xml, see the Sun Java System Application Server Administrator’s Configuration File Reference.

> #### Dynamic Reloading

> If dynamic reloading is enabled, you do not have to redeploy an application or module when you change its code. All you have to do is copy the changed class files into the deployment directory for the application or module. The server checks for changes periodically and redeploys the application, automatically and dynamically, with the changes.

> This is useful in a development environment, because it allows code changes to be tested quickly. Dynamic reloading is not recommended for a production environment, however, because it may degrade performance. In addition, whenever a reload is done, the sessions at that transit time become invalid. The client must restart the session.

> To enable dynamic reloading, you can do one of the following:

> ##### Use the Administration interface

> 1. Open the Applications component under your server instance.
> 2. Go to the Applications page.
> 3. Check the Reload Enabled box to enable dynamic reloading.
> 4. Enter a number of seconds in the Reload Poll Interval field to set the interval at which applications and modules are checked for code changes and dynamically reloaded.
> 5. Click on the Save button.
> 6. Go to the server instance page and select the Apply Changes button.

> ##### Edit the server.xml file

> Edit the following attributes of the server.xml file’s applications element:

> - dynamic-reload-enabled="true" enables dynamic reloading.
> - dynamic-reload-poll-interval-in-seconds sets the interval at which applications and modules are checked for code changes and dynamically reloaded.

> For details about server.xml, see the Sun Java System Application Server Administrator’s Configuration File Reference.

> In addition, to load new servlet files, reload EJB related changes, or reload deployment descriptor changes, you must do the following:

> 1. Create an empty file named .reload at the root of the deployed application:

> instance_dir/applications/j2ee-apps/app_name/.reload

> or individually deployed module:

> instance_dir/applications/j2ee-modules/module_name/.reload

> 1. Explicitly update the .reload file’s timestamp (touch .reload in UNIX) each time you make the above changes.

> For JSPs, changes are reloaded automatically at a frequency set in the reload-interval property of the jsp-config element in the sun-web.xml file. To disable dynamic reloading of JSPs, set reload-interval="-1".

> ### Using Availability Features (Enterprise Edition)

> When you deploy an application, you can choose to enable availability for the application (availability enabled set to true) or you can choose Specified by Container to automatically use the availability setting specified in the web or EJB container level. If availability is enabled, the application can fail over HTTP sessions and stateful session beans. If you want availability enabled for an application, it must also be enabled at all higher levels (server instance and web container or EJB container) as well.

> For more information about availability, see Chapter 20, "Configuring Session Persistence (Enterprise Edition)."

> ### Tools for Deployment

> This section discusses the various tools that can be used to deploy modules and applications. The deployment tools include:

> - The asadmin Utility
> - The Administration Interface
> - Sun ONE Studio

> #### The asadmin Utility

> You can use the asadmin utility to deploy or undeploy applications and individually deployed modules on local servers. Concurrent deployment on multiple machines is not supported. This section describes the asadmin utility only briefly.

> To deploy a lifecycle module, see Deploying a Lifecycle Module.

> ##### asadmin deploy

> The asadmin deploy command deploys a WAR, JAR, RAR, or EAR file. To deploy an application, specify --type application in the command. To deploy an individual module, specify --type ejb, web, connector. The syntax is as follows, with defaults shown for optional parameters that have them:

> asadmin deploy --user admin_user [--password admin_password] [--host localhost] [-port 4848] [--secure | -s] [--passwordfile file_name] [--virtualservers virtual_servers] [--type application|ejb|web|connector] [--contextroot contextroot] [--force=true] [--precompilejsp=false] [--verify=false] [--name component_name] [--upload=true] [--availabilityenabled] [--retrieve local_dirpath] [--instance instance_name] filepath

> Note | The availabilityenabled option is only available in the Sun Java System Application Server, Enterprise Edition.

> For example, the following command deploys an individual EJB module:

> asadmin deploy --user jadams --password secret --host localhost --port 4848 --type ejb --instance server1 packagingEJB.jar

> ##### asadmin deploydir

> The asadmin deploydir command deploys an application or module in an open directory structure. The structure must be as specified in Deployment Directory Structure. The location of the dirpath under instance_dir/applications/j2ee-apps or instance_dir/applications/j2ee-modules determines whether it is an application or individually deployed module. The syntax is as follows, with defaults shown for optional parameters that have them:

> asadmin deploydir --user admin_user [--password admin_password] [--host localhost] [-port 4848] [--secure | -s] [--passwordfile file_name] [--virtualservers virtual_servers] [--type application|ejb|web|connector] [--contextroot contextroot] [--force=true] [--precompilejsp=false] [--verify=false] [--availabilityenabled] [--name component_name] [--instance instance_name] dirpath

> Note | The availabilityenabled option is only available in the Sun Java System Application Server, Enterprise Edition.

> For example, the following command deploys an individual EJB module:

> asadmin deploydir --user jadams --password secret --host localhost --port 4848 --type ejb --instance server1 packagingEJB

> ##### asadmin undeploy

> The asadmin undeploy command undeploys an application or module. To undeploy an application, specify --type app in the command. To undeploy a module, specify --type ejb, web, or connector. The syntax is as follows, with defaults shown for optional parameters that have them:

> asadmin undeploy --user admin_user [--password admin_password] [--host localhost] [-port 4848] [--secure | -s] [--passwordfile file_name] [--type application|ejb|web|connector] [--instance instance_name] component_name

> For example, the following command undeploys an individual EJB module:

> asadmin undeploy --user jadams --password secret --host localhost --port 4848 --type ejb --instance server1 packagingEJB

> #### The Administration Interface

> You can use the Administration interface to deploy modules and applications to both local and remote Sun Java System Application Server sites. To use this tool, follow these steps:

> 1. Open the Applications component under your server instance.
> 2. Go to the Enterprise Applications, Web Applications, Connector Modules, or EJB Modules page.
> 3. Click on the Deploy button.
> 4. Enter the full path to the module or application (or click on Browse to find it), then click on the OK button.
> 5. Enter the module or application name.

> You can also redeploy the module or application if it already exists by checking the appropriate box. This is optional.

> 6. Assign the application or module to one or more virtual servers by checking the boxes next to the virtual server names.
> 7. Choose whether to enable availability, which enables failover at this level if it is enabled at higher levels (Enterprise Edition only).
> 8. Click on the OK button.

> To deploy a lifecycle module, see Deploying a Lifecycle Module.

> #### Sun ONE Studio

> You can use Sun ONE Studio to deploy J2EE applications and modules. For more information about using Sun ONE Studio, see the Sun ONE Studio, Enterprise Edition Tutorial.

> Note | In Sun ONE Studio, deploying a module or application is referred to as executing it. Execution also includes making sure the server is running and displaying the correct URL to activate the module or application.

> ### Deploying a Module or Application

> You can deploy applications or individual modules that are independent of applications. The runtime and file system implications of application-based or individual module-based deployment are described in Runtime Environments.

> Individual module-based deployment is preferable when components need to be accessed by:

> - Other modules
> - J2EE Applications
> - RMI/IIOP clients (Module-based deployment allows shared access to a bean from an RMI/IIOP client, a servlet, or an EJB.)

> Modules can be combined into an EAR file and then deployed as a single module. This is similar to deploying the modules of the EAR independently.

> ### Deploying a WAR Module

> You deploy a WAR module in one of the ways described in Tools for Deployment.

> You can keep the generated source for JSPs by adding the -keepgenerated property to the jsp-config element in sun-web.xml. If you include this property when you deploy the WAR module, the generated source is kept in instance_dir/generated/jsp/j2ee-apps/app_name/module_name if it is in an application or instance_dir/generated/jsp/j2ee-modules/module_name if it is in an individually deployed web module. For more information about the -keepgenerated property, see the Sun Java System Application Server Developer’s Guide to Web Applications.

> ### Deploying an EJB JAR Module

> You deploy an EJB JAR module in one of the ways described in Tools for Deployment.

> You can keep the generated source for stubs and ties by adding the -keepgenerated flag to the rmic-options attribute of the java-config element in server.xml. If you include this flag when you deploy the EJB JAR module, the generated source is kept in instance_dir/generated/ejb/j2ee-apps/app_name/module_name if it is in an application or instance_dir/generated/ejb/j2ee-modules/module_name if it is in an individually deployed EJB JAR module. For more information about the -keepgenerated flag, see the Sun Java System Application Server Admin istrator’s Configuration File Reference. For more information about rmic, see the Java 2 SDK Tools and Utilities documentation at http://java.sun.com/docs/index.html.

> ### Deploying a Lifecycle Module

> For general information about lifecycle modules, see the Sun Java System Application Serverr Developer’s Guide.

> You can deploy a lifecycle module using the following tools:

> - The asadmin Utility
> - The Administration Interface

> #### The asadmin Utility

> To deploy a lifecycle module, use the asadmin create-lifecycle-module command. The syntax is as follows, with defaults shown for optional parameters that have them:

> asadmin create-lifecycle-module --user admin_user [--password admin_password] [--host localhost] [-port 4848] [--secure | -s] [--passwordfile file_name] [--instance instance_name] --classname classname [--classpath classpath] [--loadorder load_order_number] [--failurefatal=false] [--enabled=true] [--description text_description] [--property (name=value)[:name=value]*] modulename

> For example:

> asadmin create-lifecycle-module --user jadams --password secret --host localhost --port 4848 --instance server1 --classname RMIServer MyRMIServer

> To undeploy a lifecycle module, use the asadmin delete-lifecycle-module command. The syntax is as follows, with defaults shown for optional parameters that have them:

> asadmin delete-lifecycle-module --user admin_user [--password admin_password] [--host localhost] [-port 4848] [--secure | -s] [--passwordfile file_name] [--instance instance_name] module_name

> For example:

> asadmin delete-lifecycle-module --user jadams --password secret --host localhost --port 4848 --instance server1 MyRMIServer

> To list the lifecycle modules that are deployed on a server instance, use the asadmin list-lifecycle-modules command. The syntax is as follows, with defaults shown for optional parameters that have them:

> asadmin list-lifecycle-modules --user admin_user [--password admin_password] [--host localhost] [-port 4848] [--secure | -s] [--passwordfile file_name] instance_name

> For example:

> asadmin list-lifecycle-module --user jadams --password secret --host localhost --port 4848 server1

> #### The Administration Interface

> You can also use the Administration interface to deploy a lifecycle module. Follow these steps:

> 1. Open the Applications component under your server instance.
> 2. Go to the Life Cycle Modules page.
> 3. Click on the Deploy button.
> 4. Enter the following information:
> - Name (required) - The name of the life cycle module.
> - Class Name (required) - The fully qualified name of the life cycle module’s class file.
> - Classpath (optional) - The classpath for the life cycle module. Specifies where the module is located. The default location is under the application root directory.
> - Load Order (optional) - Determines the order in which life cycle 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.
> - Failure Fatal (optional) - Determines whether the server is shut down if the life cycle module fails. The default is false.
> - Enable (optional) - Determines whether the life cycle module is enabled. The default is true.
> 5. Click OK.

> ### Deploying an RMI/IIOP Client

> Deployment is only necessary for clients that communicate with EJBs. Deploying an RMI/IIOP client is a three-step process:

> 1. Deploy the EAR or EJB JAR to be accessed by the RMI/IIOP client.
> 2. Assemble the necessary client files and deploy the client.
> 3. After deployment, a client JAR file is created in the following location for an application:

> instance_dir/applications/j2ee-apps/app_name/app_name Client.jar

> or in the following location for an individually deployed module:

> instance_dir/applications/j2ee-modules/module_name/module_name Client.jar

> The client JAR contains the ties and necessary classes for the RMI/IIOP client. Copy this file to the client machine, and set the APPCPATH environment variable on the client to point to this JAR.

> You are now ready to run the client. For more information, see the Sun Java System Application Server Developer’s Guide to Clients.

> ### Deploying a J2EE CA Resource Adapter

> You deploy a connector module in one of the ways described in Tools for Deployment.

> ### Deploying Static Content

> Static content (HTML, images, etc.) can be hosted both on the web server and on the Sun Java System Application Server. However, when a WAR is registered, the static content gets deployed on the application server. All of the samples shipped with Sun Java System Application Server host the static content on the application server.

> For example, to access a static file index.html on the application server, use: http://server:port/tcontext_root/index.html

> ### Access to Shared Frameworks

> When J2EE applications and modules use shared framework classes (such as components and libraries) the classes can be put in the path for the System Classloader or the Common Classloader rather than in an application or module. If you assemble a large, shared library into every module that uses it, the result is a huge file that takes too long to register with the server. In addition, several versions of the same class could exist in different classloaders, which is a waste of resources.

> For more information about the system classloader, see About Classloaders.

> ##

> The Application Deployment Descriptor Files

> Sun Java System Application Server applications include two deployment descriptor files:

> - A J2EE standard file (application.xml), described in the Java Servlet Specification, v2.3, Chapter 13, “Deployment Descriptors.”
> - An optional Sun Java System Application Server specific file (sun-application.xml), described in this section.

> For more information on application deployment descriptor files, see the Sun Java System Application Server Developer’s G uide.

> Previous Contents Index Next

> Copyright 2005 Sun Microsystems, Inc. All rights reserved.