However, optional packages function as individual Java EE modules standalone or within an enterprise application , rather than as an enterprise application. For example, third-party Web Application Framework classes needed by multiple Web applications can be packaged and deployed in a single JAR file, and referenced by multiple Web application modules in the domain.
Optional packages are delivered as basic JAR files that have no deployment descriptors. You simply designate the JAR as an optional package at deployment time, and WebLogic Server registers the file with the target servers you select. An application module deployed as part of an enterprise application is available only to the enclosing application an application-scoped resource. Using application-scoped resources ensures that an application always has access to required resources, and simplifies the process of deploying the application into new environments.
In contrast to system modules, application modules are owned by the developer who created and packaged the module, rather than the administrator who deploys the module. When deploying an application module, an administrator can change resource properties that were specified in the module, but cannot add or delete resources.
System modules are created by the administrator via the WebLogic Administration Console, and can be changed or deleted as necessary by the administrator. Similarly, standalone application modules created by the administrator can be used to recreate global resources in multiple WebLogic Server environments simply by deploying the modules into new domains.
The Java EE specification enables you to include a client application archive file within an enterprise application. This enables both the server-side and client-side components to be distributed as a single unit. Deployer provides a command-line based interface for performing both basic and advanced deployment tasks.
Use weblogic. Deployer when you want command-line access to WebLogic Server deployment functionality, or when you need to perform a deployment task that is not supported using the Administration Console. The Administration Console provides a series of Web-based deployment assistants that guide you through the deployment process. The Administration Console also provides controls for changing and monitoring the deployment status, and changing selected deployment descriptor values while the deployment unit is up and running.
Use the Administration Console when you need to perform basic deployment functions interactively and you have access to a supported browser. The WebLogic Scripting Tool WLST is a command-line interface that you can use to automate domain configuration tasks, including application deployment configuration and deployment operations. Deployer utility. Blogger January 4, at AM. Mahender August 14, at PM. Newer Post Older Post Home.
Subscribe to: Post Comments Atom. Deployment targets are the servers to which you deploy an application or standalone module. Valid deployment targets include WebLogic Server instances, clusters, and virtual hosts.
During the deployment process, you select the list of targets from the available servers, clusters, and virtual hosts configured in your domain. You can also change the target list at any time after you have deployed a module. You can deploy applications and standalone modules to one or more Managed Servers in a domain, or to the Administration Server in a single-server domain. Although you can deploy to the Administration Server in a multiple-server domain, this practice is not recommended.
The Administration Server in a multiple-server domain should be used only for administration purposes. If you are deploying to a cluster of WebLogic Server instances, by default the deployment targets all server instances in the cluster. This corresponds to homogenous module deployment, which is recommended in most clusters. If you want to deploy a module only to a single server in the cluster that is, "pin" a module to a servers , you can also select the individual server name.
This type of deployment is less common, and should be used only in special circumstances where pinned services are required. Note: Pinning a deployment to a subset of server instances in a cluster rather than a single server is not recommended and will generate a warning message. Virtual hosting allows you to define host names to which servers or clusters respond.
When you use virtual hosting, you use DNS naming to specify one or more host names that map to the IP address of a WebLogic Server or cluster, and you specify which applications are served by each virtual host. You select a configured virtual host name as you would a WebLogic Server instance or cluster name during deployment. Note: If the context root for a Web Application is blank in weblogic.
The deployment staging mode determines how deployment files are made available to target servers that must deploy an application or standalone module. The following table describes the behavior and best practices for using the different deployment staging modes. The Administration Server first copies the deployment unit source files to the staging directories of target servers specified by the Staging Directory Name attribute.
The target servers then deploy using their local copy of the deployment files. Deploying small or moderate-sized applications to multiple WebLogic Server instances. The Administration Server does not copy deployment unit files. Instead, all servers deploy using the same physical copy of the deployment files, which must be directly accessible by the Administration Server and target servers.
With nostage deployments of exploded archive directories, WebLogic Server automatically detects changes to a deployment's JSPs or Servlets and refreshes the deployment. This behavior can be disabled if necessary. Deploying very large applications to multiple targets or to a cluster where deployment files are available on a shared directory. Deploying exploded archive directories that you want to periodically redeploy after changing content.
Deployments that require dynamic update of selected Deployment Descriptors via the Administration Console. The Administration Server does not copy deployment files. Instead, the Administrator must ensure that deployment files are distributed to the correct staging directory location before deployment for example, by manually copying files prior to deployment. Copies of the deployment files that reside in target servers' staging directories are not validated before deployment.
Application deployment generally involves the following tasks:. Java EE 5 includes a deployment specification, JSR, that describes a standard API used by deployment tools and application server providers to configure and deploy applications to an application server. WebLogic Server deployment descriptors are generated as needed to store WebLogic Server configuration data. The WebLogic Server deployment plan generated by a Java EE 5 deployment API deployment tool identifies the WebLogic Server deployment descriptors that were generated for the application during the configuration session.
Although the Java EE 5 deployment API provides a simple, standardized way to configure applications and modules for use with a Java EE 5-compliant application server, the specification does not address many deployment features that were available in previous WebLogic Server releases. WebLogic Server supports the following advanced deployment features to help you reliably deploy and manage applications in a production environment. Whereas the Java EE 5 deployment API deployment specification enables you to generate vendor-specific descriptor values necessary for deploying an application, WebLogic Server extensions to Java EE 5 deployment API allow you to configure many additional deployment properties, including:.
The declared names of services provided in a deployed application JNDI names , which other applications may reference for their own use. Tuning properties that control the performance and behavior of the application on WebLogic Server. The basic Java EE 5 deployment API configuration process provides a simple way for standardized deployment tools to deploy J2EE applications on multiple application server products.
However, it does not help in the process of migrating an application's configuration from one environment to another within an organization. Distributing an application copies deployment files to target servers and places the application in a prepared state.
You can then start the application in Administration mode, which restricts access to the application to a configured Administration channel so you can perform final testing without opening the application to external client connections or disrupting connected clients. You can start an application in administration mode with the -adminmode option as described in Starting a Distributed Application in Administration Mode.
After performing final testing, you can either undeploy the application to make further changes, or start the application in Production mode to make it generally available to clients. Application-scoped resource modules make it possible to include all of an application's required resources within the application module itself, for maximum portability to multiple environments.
WebLogic Server enables you to target individual modules of an Enterprise Application to different server targets, or to deploy only a subset of available modules in an Enterprise Application.
This provides flexible packaging options, allowing you to bundle a group of related modules together in an Enterprise Application, but deploy only selected modules to individual servers in a domain. WebLogic Server enables you to safely update and redeploy a new version of a production application without affecting current HTTP clients to the application.
0コメント