type=page
status=published
title=deploydir
next=disable.html
prev=deploy.html
~~~~~~
deploydir
=========

[[deploydir-1]][[GSRFM00115]][[deploydir]]

deploydir
---------

deploys an exploded format of application archive

[[sthref1031]]

Synopsis

[source,oac_no_warn]
----
asadmin [asadmin-options] deploydir [--help] 
[--force={false|true}] 
[--virtualservers virtual_servers]
[--contextroot context_root]
[--verify={false|true}] 
[--precompilejsp={false|true}] 
[--name component-name] 
[--retrieve local_dirpath] 
[--uniquetablenames={true|false}] 
[--dbvendorname dbvendorname] 
[--createtables={false|true}|--dropandcreatetables={false|true}]
[--deploymentplan deployment_plan]
[--altdd alternate_deploymentdescriptor]
[--runtimealtdd runtime_alternate_deploymentdescriptor]
[--deploymentorder deployment_order]
[--enabled={true|false}] 
[--generatermistubs={false|true}] 
[--availabilityenabled={false|true}] 
[--asyncreplication={true|false}]
[--lbenabled={true|false}]
[--keepstate={false|true}]
[--libraries jar_file[,jar_file]*] 
[--target target] 
[--type pkg-type] 
[--properties(name=value)[:name=value]*]
dirpath
----

[[sthref1032]]

Description


[NOTE]
=======================================================================

The `deploydir` subcommand is deprecated. Use the `deploy` subcommand
instead.

=======================================================================


The `deploydir` subcommand deploys an application directly from a
development directory. The appropriate directory hierarchy and
deployment descriptors conforming to the Java EE specification must
exist in the deployment directory.

Directory deployment is for advanced developers only. Do not use
`deploydir` in production environments. Instead, use the `deploy`
subcommand. Directory deployment is only supported on localhost, that
is, the client and server must reside on the same machine. For this
reason, the only values for the `--host` option are:

* `localhost`
* The value of the `$HOSTNAME` environment variable
* The IP address of the machine

If the `--uniquetablenames`, `--createtables`, and
`--dropandcreatetables` options are not specified, the entries in the
deployment descriptors are used.

The `--force` option makes sure the component is forcefully (re)deployed
even if the specified component has already been deployed or already
exists. Set the `--force` option to false for an initial deployment. If
the specified application is running and the `--force` option is set to
false, the subcommand fails.

This subcommand is supported in remote mode only.

[[sthref1033]]

Options

asadmin-options::
  Options for the `asadmin` utility. For information about these
  options, see the link:asadmin.html#asadmin-1m[`asadmin`(1M)] help page.
`--help`::
`-?`::
  Displays the help text for the subcommand.
`--force`::
  If set to `true`, redeploys the component even if the specified
  component has already been deployed or already exists. Default is
  `false`.
`--virtualservers`::
  One or more virtual server IDs. Multiple IDs are separated by commas.
`--contextroot`::
  Valid only if the archive is a web module. It is ignored for other
  archive types; it will be the value specified by default-context-path
  in web.xml, if specified; defaults to filename without extension.
`--precompilejsp`::
  By default this option does not allow the JSP to be precompiled during
  deployment. Instead, JSPs are compiled during runtime. Default is
  `false`.
`--verify`::
  If set to true and the required verifier packages are installed from
  the Update Tool, the syntax and semantics of the deployment descriptor
  is verified. Default is `false`.
`--name`::
  Name of the deployable component. +
  The name can include an optional version identifier, which follows the
  name and is separated from the name by a colon (`:`). The version
  identifier must begin with a letter or number. It can contain
  alphanumeric characters plus underscore (`_`), dash (`-`), and period
  (`.`) characters. For more information about module and application
  versions, see "link:../application-deployment-guide/overview.html#GSDPG00324[Module and Application Versions]" in
  GlassFish Server Open Source Edition Application Deployment Guide.
`--retrieve`::
  Retrieves the client stub JAR file from the server machine to the
  local directory.
`--dbvendorname`::
  Specifies the name of the database vendor for which tables are
  created. Supported values include `db2`, `mssql`, `mysql`, `oracle`,
  `derby`, `javadb`, `postgresql`, and `sybase`. These values are
  case-insensitive. If not specified, the value of the
  `database-vendor-name` attribute in `glassfish-ejb-jar.xml` is used.
  If no value is specified, a connection is made to the resource
  specified by the `jndi-name` subelement of the `cmp-resource` element
  in the `glassfish-ejb-jar.xml` file, and the database vendor name is
  read. If the connection cannot be established, or if the value is not
  recognized, SQL-92 compliance is presumed.
`--createtables`::
  If specified as true, creates tables at deployment of an application
  with unmapped CMP beans. If specified as false, tables are not
  created. If not specified, the value of the `create-tables-at-deploy`
  entry in the `cmp-resource` element of the `glassfish-ejb-jar.xml`
  file determines whether or not tables are created. No unique
  constraints are created for the tables.
`--dropandcreatetables`::
  If specified as true when the component is redeployed, the tables
  created by the previous deployment are dropped before creating the new
  tables. Applies to deployed applications with unmapped CMP beans.
  Preexisting tables will not be dropped on the initial deployment of an
  application or on a deployment that follows an explicit undeploy. If
  specified as false, tables are neither dropped nor created. If not
  specified, the tables are dropped if the `drop-tables-at-undeploy`
  entry in the `cmp-resource` element of the `glassfish-ejb-jar.xml`
  file is set to true, and the new tables are created if the
  `create-tables-at-deploy` entry in the `cmp-resource` element of the
  `glassfish-ejb-jar.xml` file is set to true.
`--uniquetablenames`::
  Guarantees unique table names for all the beans and results in a hash
  code added to the table names. This is useful if you have an
  application with case-sensitive bean names. Applies to applications
  with unmapped CMP beans.
`--deploymentplan`::
  Deploys the deployment plan, which is a JAR file that contains
  \{product---name} descriptors. Specify this option when deploying a
  pure EAR file. A pure EAR file is an EAR without \{product---name}
  descriptors.
`--altdd`::
  Deploys the application using a Java EE standard deployment descriptor
  that resides outside of the application archive. Specify an absolute
  path or a relative path to the alternate deployment descriptor file.
  The alternate deployment descriptor overrides the top-level deployment
  descriptor packaged in the archive. For example, for an EAR, the
  `--altdd` option overrides `application.xml`. For a standalone module,
  the `--altdd` option overrides the top-level module descriptor such as
  `web.xml`.
`--runtimealtdd`::
  Deploys the application using a \{product---name} runtime deployment
  descriptor that resides outside of the application archive. Specify an
  absolute path or a relative path to the alternate deployment
  descriptor file. The alternate deployment descriptor overrides the
  top-level deployment descriptor packaged in the archive. For example,
  for an EAR, the `--runtimealtdd` option overrides
  `glassfish-application.xml`. For a standalone module, the
  `--runtimealtdd` option overrides the top-level module descriptor such
  as `glassfish-web.xml`. Applies to \{product---name} deployment
  descriptors only (`glassfish-*.xml`); the name of the alternate
  deployment descriptor file must begin with `glassfish-`. Does not
  apply to `sun-*.xml` deployment descriptors, which are deprecated.
`--deploymentorder`::
  Specifies the deployment order of the application. This is useful if
  the application has dependencies and must be loaded in a certain order
  at server startup. The deployment order is specified as an integer.
  The default value is 100. Applications with lower numbers are loaded
  before applications with higher numbers. For example, an application
  with a deployment order of 102 is loaded before an application with a
  deployment order of 110. If a deployment order is not specified, the
  default value of 100 is assigned. If two applications have the same
  deployment order, the first application to be deployed is the first
  application to be loaded at server startup. +
  The deployment order is typically specified when the application is
  first deployed but can also be specified or changed after initial
  deployment using the `set` subcommand. You can view the deployment
  order of an application using the `get` subcommand
`--enabled`::
  Allows users to access the application. If set to `false`, users will
  not be able to access the application. This option enables the
  application on the specified target instance or cluster. If you deploy
  to the target `domain`, this option is ignored, since deploying to the
  domain doesn't deploy to a specific instance or cluster. The default
  is `true`.
`--generatermistubs`::
  If set to `true`, static RMI-IIOP stubs are generated and put into the
  `client.jar`. If set to `false`, the stubs are not generated. Default
  is `false`.
`--availabilityenabled`::
  This option controls whether high-availability is enabled for web
  sessions and for stateful session bean (SFSB) checkpointing and
  potentially passivation. If set to false (default) all web session
  saving and SFSB checkpointing is disabled for the specified
  application, web application, or EJB module. If set to true, the
  specified application or module is enabled for high-availability. Set
  this option to true only if high availability is configured and
  enabled at higher levels, such as the server and container levels.
`--asyncreplication`::
  This option controls whether web session and SFSB states for which
  high availability is enabled are first buffered and then replicated
  using a separate asynchronous thread. If set to true (default),
  performance is improved but availability is reduced. If the instance
  where states are buffered but not yet replicated fails, the states are
  lost. If set to false, performance is reduced but availability is
  guaranteed. States are not buffered but immediately transmitted to
  other instances in the cluster.
`--lbenabled`::
  This option controls whether the deployed application is available for
  load balancing. The default is true.
`--keepstate`::
  This option controls whether web sessions, SFSB instances, and
  persistently created EJB timers are retained between redeployments. +
  The default is false. This option is supported only on the default
  server instance, named `server`. It is not supported and ignored for
  any other target. +
  Some changes to an application between redeployments prevent this
  feature from working properly. For example, do not change the set of
  instance variables in the SFSB bean class. +
  For web applications, this feature is applicable only if in the
  `glassfish-web-app.xml` file the `persistence-type` attribute of the
  `session-manager` element is `file`. +
  For stateful session bean instances, the persistence type without high
  availability is set in the server (the `sfsb-persistence-type`
  attribute) and must be set to `file`, which is the default and
  recommended value. +
  If any active web session, SFSB instance, or EJB timer fails to be
  preserved or restored, none of these will be available when the
  redeployment is complete. However, the redeployment continues and a
  warning is logged. +
  To preserve active state data, \{product---name} serializes the data
  and saves it in memory. To restore the data, the class loader of the
  newly redeployed application deserializes the data that was previously
  saved.
`--libraries`::
  A comma-separated list of library JAR files. Specify the library JAR
  files by their relative or absolute paths. Specify relative paths
  relative to domain-dir`/lib/applibs`. The libraries are made available
  to the application in the order specified.
`--target`::
  Specifies the target to which you are deploying. Valid values are: +
  `server`;;
    Deploys the component to the default server instance `server` and is
    the default value.
  `domain`;;
    Deploys the component to the domain. If `domain` is the target for
    an initial deployment, the application is deployed to the domain,
    but no server instances or clusters reference the application. If
    `domain` is the target for a redeployment (the `--force` option is
    set to true), and dynamic reconfiguration is enabled for the
    clusters or server instances that reference the application, the
    referencing clusters or server instances automatically get the new
    version of the application. If redeploying, and dynamic
    configuration is disabled, the referencing clusters or server
    instances do not get the new version of the application until the
    clustered or standalone server instances are restarted.
  cluster_name;;
    Deploys the component to every server instance in the cluster.
  instance_name;;
    Deploys the component to a particular stand-alone server instance.
`--type`::
  The packaging archive type of the component that is being deployed.
  Possible values are as follows: +
  `car`;;
    The component is packaged as a CAR file.
  `ear`;;
    The component is packaged as an EAR file.
  `ejb`;;
    The component is an EJB packaged as a JAR file.
  `osgi`;;
    The component is packaged as an OSGi bundle.
  `rar`;;
    The component is packaged as a RAR file.
  `war`;;
    The component is packaged as a WAR file.
`--properties` or `--property`::
  Optional keyword-value pairs that specify additional properties for
  the deployment. The available properties are determined by the
  implementation of the component that is being deployed or redeployed.
  The `--properties` option and the `--property` option are equivalent.
  You can use either option regardless of the number of properties that
  you specify. +
  You can specify the following properties for a deployment: +
  `jar-signing-alias`;;
    Specifies the alias for the security certificate with which the
    application client container JAR file is signed. Java Web Start will
    not run code that requires elevated permissions unless it resides in
    a JAR file signed with a certificate that the user's system trusts.
    For your convenience, \{product---name} signs the JAR file
    automatically using the certificate with this alias from the
    domain's keystore. Java Web Start then asks the user whether to
    trust the code and displays the \{product---name} certificate
    information. To sign this JAR file with a different certificate, add
    the certificate to the domain keystore, then use this property. 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. Default is `s1as`, the alias for the
    self-signed certificate created for every domain.
  `java-web-start-enabled`;;
    Specifies whether Java Web Start access is permitted for an
    application client module. Default is true.
  `compatibility`;;
    Specifies the \{product---name} release with which to be backward
    compatible in terms of JAR visibility requirements for applications.
    The only allowed value is `v2`, which refers to Sun GlassFish
    Enterprise Server version 2 or Sun Java System Application Server
    version 9.1 or 9.1.1. Beginning in Java EE 6, the Java EE platform
    specification imposed 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 restrictions.
  `keepSessions={false|true}`;;
    Superseded by the `--keepstate` option. +
    If the `--force` option is set to `true`, this property can by used
    to specify whether active sessions of the application that is being
    redeployed are preserved and then restored when the redeployment is
    complete. Applies to HTTP sessions in a web container. Default is
    `false`.::
    `false`::
      Active sessions of the application are not preserved and restored
      (default).
    `true`::
      Active sessions of the application are preserved and restored. +
      If any active session of the application fails to be preserved or
      restored, none of the sessions will be available when the
      redeployment is complete. However, the redeployment continues and
      a warning is logged. +
      To preserve active sessions, \{product---name} 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.
  `preserveAppScopedResources`;;
    If set to `true`, preserves any application-scoped resources and
    restores them during redeployment. Default is `false`. +
  Other available properties are determined by the implementation of the
  component that is being redeployed. +
  For components packaged as OSGi bundles (`--type=osgi`), the `deploy`
  subcommand accepts properties arguments that can be used to wrap a WAR
  file as a WAB (Web Application Bundle). The subcommand looks for a key
  named `UriScheme` and, if present, uses the key as a URL stream
  handler to decorate the input stream. Other properties are used in the
  decoration process. The \{product---name} OSGi web container registers
  a URL stream handler named `webbundle`, which is used to wrap a plain
  WAR file as a WAB. For more information about usage, see the related
  example in the link:deploy.html#deploy-1[`deploy`(1)] help page.

[[sthref1034]]

Operands

dirpath::
  Path to the directory containing the exploded format of the deployable
  archive. This is the path to the directory on the server machine.

[[sthref1035]]

Examples

[[GSRFM589]][[sthref1036]]

Example 1   Deploying an Application From a Directory

In this example, the exploded application to be deployed is in the
`/home/temp/sampleApp` directory. Because the `--force` option is set to
true, if an application of that name already exists, the application is
redeployed.

[source,oac_no_warn]
----
asadmin> deploydir --force=true --precompilejsp=true /home/temp/sampleApp
Application deployed successfully with name sampleApp.
WARNING : deploydir command deprecated. Please use deploy command instead.
Command deploydir executed successfully
----

[[sthref1037]]

Exit Status

0::
  subcommand executed successfully
1::
  error in executing the subcommand

[[sthref1038]]

See Also

link:asadmin.html#asadmin-1m[`asadmin`(1M)]

link:get.html#get-1[`get`(1)], link:deploy.html#deploy-1[`deploy`(1)],
link:redeploy.html#redeploy-1[`redeploy`(1)],
link:set.html#set-1[`set`(1)],
link:undeploy.html#undeploy-1[`undeploy`(1)]

link:../application-deployment-guide/toc.html#GSDPG[GlassFish Server Open Source Edition Application Deployment
Guide]