The runAssembler command takes a number of command-line flags that you can use individually or in combination to alter the output of the command. The following table summarizes these options. Some the key options are described in more detail below.
Option | Description |
|---|---|
| Pack the assembled EAR file into the archived J2EE enterprise archive format. By default, the EAR is assembled in an “exploded,” open-directory format. |
| Configure the assembled EAR in standalone mode, so that it contains all application resources, including Nucleus configuration files, and does not refer to the ATG installation directory. By default, the EAR is assembled in development mode, in which only classes, libraries, and J2EE modules are imported to the EAR file, and Nucleus configuration and other resources are used directly from the ATG install directory. |
| Overwrite all resources in the existing EAR file. By default, resources in the assembled EAR are only overwritten if the source file is newer, to reduce assembly time. |
| Collapse all JAR files and directories in the CLASSPATH into a single JAR file in the assembled EAR file. By default, these JAR files and directories are copied separately to the EAR file’s |
| Do not assemble a complete EAR file; instead create a JAR file which collapses the JAR files and directories in the CLASSPATH into a single library. |
| Specifies the value to be used to set the display name in the |
| Specifies the value for the |
| Enable the |
| Include the contents from an existing EAR file in the assembled EAR file. |
| Specifies a Java properties file whose settings are used to override the default context root values for any web applications included in the assembled EAR file. To specify the context root for a web application in this properties file, add a line with the following format:
where |
| Instructs By default the
to
The
|
| When assembling the EAR file, does not copy Notes: This switch can only be used with JBoss. It should only be used during development, and not on a production site. Any EAR or WAR files referred to in your ATG installation must be exploded. |
| Includes the comma separated list of jar files on the classpath. This attribute is useful for applying hotfixes. For example:
Note: Special characters appearing in jar file names may cause that file to be ignored. When naming files, it is best to use only alphanumeric characters and the underscore. |
Including an Existing EAR File
When you assemble an EAR file, the application modules you specify may contain EAR files, WAR files, and other J2EE entities. The application assembler automatically includes these, as well as the Nucleus resources used by the application modules themselves.
You can also have the application assembler include an existing EAR file that is not part of a module. To do this, invoke the runAssembler command, and use the –add-ear-file flag to specify the EAR file to include. For example:
runAssembler –add-ear-file resources.ear MyApp.ear –m MyApp DSS
To include more than one existing EAR file, use a separate –add-ear-file flag before the name of each EAR file.
Note: Only use this option to include existing EAR files that are not part of ATG application modules. To include an EAR file that is part of an ATG application module, just include the module name in the list of modules specified with the –m flag. Including the whole module ensures that any Nucleus resources that the existing EAR file depends on are included in the assembled EAR file.
Including Web Services
You can include any of ATG’s prepackaged Web services in an assembled EAR file by including the module that contains the desired services. For example, to include the Commerce services, specify the DCS.WebServices module when you invoke the runAssembler command. To include Web services you have created through the Web Service Creation Wizard, use the runAssembler command’s –add-ear-file flag to specify the EAR file that contains the service.
Using a Non-Default ATG Server
If you run the application assembler without specifying a server name, the resulting application uses the default ATG server. This means that the application gets site-specific configuration settings from standard configuration directories, such as <ATG2007.3dir>/home/localconfig.
If the application is assembled in development mode, the localconfig directory in the ATG installation is set as the last entry in the application’s CONFIGPATH. If the application is in standalone mode, the assembler copies that directory from the ATG installation into the atg_bootstrap.war/WEB-INF/ATG-INF directory in the EAR file (as described in Development Mode and Standalone Mode). This directory is added to the CONFIGPATH just before the ATG-Data/localconfig directory, which is the last entry in the CONFIGPATH. For output files, the application uses the logs and pagebuild subdirectories in the <ATG2007.3dir>/home directory (in development mode) or the ATG-Data/home directory (in standalone mode).
If you’ve configured any additional ATG server instances (see the ATG Installation and Configuration Guide for information), you can build your application with a particular server’s configuration. The effect of specifying a server differs depending on whether you are assembling a development-mode or standalone EAR file.
Specifying a Server for a Development-Mode EAR File
To build a development-mode EAR file that uses a server, run the application assembler with the –server flag. For example:
runAssembler –server myServer MyApp.ear –m MyApp DSS
The localconfig directory for the server is appended to the application’s CONFIGPATH. This means that the last two entries in the CONFIGPATH are the standard localconfig (<ATG2007.3dir>/home/localconfig) followed by the server-specific localconfig (e.g., <ATG2007.3dir>/home/servers/myServer/localconfig).
For output files, the application uses the logs and pagebuild subdirectories in the <ATG2007.3dir>/home/servers/servername directory. Note that you should not use the same server for more than one EAR file. If multiple EAR files are using the same output directories, errors or deadlocks may result.
Specifying a Server for a Standalone EAR File
To build a standalone-mode EAR file that uses a non-default server, you can run the application assembler with the –standalone and –server flags. For example:
runAssembler –standalone –server myServer MyApp.ear –m MyApp DSS
Note: If your production environment is clustered, rather than specify the ATG server when you build the EAR, you should omit the –server flag and instead create a single EAR, which can be deployed to all servers in the cluster. Use the -Datg.dynamo.server.name variable to specify the named instance, and use the java arg to specify the named instance of each server when you run the application.
Note that there are four localconfig directories at the end of the application’s CONFIGPATH. They appear in the following order:
atg_bootstrap.war/WEB-INF/ATG-INF/localconfig(a copy of<ATG2007.3dir>/home/localconfig)ATG-Data/localconfigatg_bootstrap.war/WEB-INF/ATG-INF/home/servers/servername/localconfig(a copy of<ATG2007.3dir>/servers/servername/localconfig)ATG-Data/servers/servername/localconfig
For output files, the application uses the logs and pagebuild subdirectories in the ATG-Data/servers/servername directory. Note that you should not use the same server for more than one EAR file. If multiple EAR files are using the same output directories, errors or deadlocks may result.
Including the Dynamo Administration UI
To be able to administer your application through the Dynamo Administration UI, you must specify the DafEar.Admin module when you run the application assembler. For example:
runAssembler QuincyFunds.ear –m DSSJ2EEDemo DafEar.Admin
The DafEar.Admin module is also required if you want to connect to the application from the client version of the ACC.
The Dynamo Administration UI is included in the EAR file as a web application, atg_admin.war. This WAR file includes all of the JHTML pages that make up the UI. Its web.xml file declares a NucleusProxyServlet that points to the Nucleus component /atg/dynamo/servlet/adminpipeline/AdminHandler:
<servlet> <servlet-name>AdminProxyServlet</servlet-name> <servlet-class>atg.nucleus.servlet.NucleusProxyServlet</servlet-class> <init-param> <param-name>proxyServletPath</param-name> <param-value>/atg/dynamo/servlet/adminpipeline/AdminHandler</param-value> </init-param> <load-on-startup>2</load-on-startup> </servlet> <servlet-mapping> <servlet-name>AdminProxyServlet</servlet-name> <url-pattern>/admin/*</url-pattern> </servlet-mapping>
In this configuration, the ContextPath is /dyn, and the ServletPath is /admin, so the URL for accessing the Dynamo Administration server is:
http://{hostname}:{port}/dyn/admin/To access the Dynamo Administration UI, use the listen port for your application server. For example, if running you are running your ATG application on JBoss with a listen port of 8080, you can access the Dynamo Administration UI on your machine at http://localhost:8080/dyn/admin.
Note: Your database must be running in order for you to use the Administration UI. If necessary, you can override this requirement by copying /atg/dynamo/security/AdminUserAuthority.properties from the <ATG2007.3dir>\DAS\config\config.jar file to <ATG2007.3dir>\home\localconfig\atg\dynamo\security.
