Today one of the biggest challenges facing an administrator of a J2EE deployment platform is to successfully transition the application from a development environment to testing and production environments. Along with the application to be deployed, developers need to transfer the knowledge about the dependent resources for an application. It is always a challenge for application deployers and system administrators to resolve such dependencies for each application when transitioning the application from development to the live environment. For example, many applications assume that a JDBC data source has already been created. This means that you cannot deploy an application until that data source has been provisioned. It is worth reading the following two articles on dev2dev to learn more about automatic provisioning on WebLogic Server: What to Expect When Promoting a WebLogic Platform Application to Production and Automating WebLogic Platform Application Provisioning: A Case Study.
The J2EE runtime environment or container provided by the application server vendor provides many infrastructure services to the application that can be configured with the deployment descriptors, for example, security, transaction, and persistence. J2EE also provides a way in which you can abstract many things that are not constant in an application by configuring them in the deployment descriptors rather than hard-coding them in the application, for example, application-specific variables, references to external resources like databases, and EJBs. In this case, changing such configurations by changing the application deployment descriptors does not require any changes in the application source.
If we do have to make an application change, then we have to carry out a lot of work—in particular unpacking the application archive and repacking it. To take advantage of the vendor-specific application configuration options used for optimizing the performance of application components in production, vendor-specific deployment descriptors inside the archives should be modified too (for example, the EJB pool size).
It would be useful for administrators or deployers to be able to make changes to the application configuration without having to extract and rearchive the application. Given these considerations, developers can use a command-line tool provided by BEA,
weblogic.PlanGenerator, to export an application's configuration. They can then select the WebLogic-specific deployment descriptor properties that have to change when the application is deployed in another environment (for example, EJB pool size, EJB cache size). This tool will create a deployment plan with variable definitions for the selected descriptor properties. Later, when the application is to be deployed using any one of the WebLogic deployment tools, the plan variables are presented to the deployer for customization.
WebLogic-specific deployment descriptor properties are classified as:
For an entire category of deployment descriptors, a template deployment plan can be generated through the command-line tool as follows:
weblogic.PlanGenerator java weblogic.PlanGenerator [options] [Path to application] where options can be [-debug |-noexit |-plan <myplan.xml>| -useplan <myplan.xml>|-root </weblogic/install/myapp>| -dependencies |-declarations |-configurables |-dynamics | -all |-none |-variables <global>]
Here is an example of the plan generated when running the generator on a simple WAR file:
<deployment-plan xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <application-name>shoppingcart.war</application-name> <variable-definition> <!-- lots of variables deleted --> <variable> <name>SessionDescriptor_InvalidationIntervalSecs_1</name> <value xsi:nil="true"></value> </variable> <variable> <name>SessionDescriptor_CookieMaxAgeSecs_12</name> <value xsi:nil="true"></value> </variable> </variable-definition> <module-override> <module-name>shoppingcart.war</module-name> <module-type>war</module-type> <module-descriptor external="false"> <root-element>weblogic-web-app</root-element> <uri>WEB-INF/weblogic.xml</uri> <!-- lots of variables deleted --> <variable-assignment> <name> SessionDescriptor_InvalidationIntervalSecs_13 </name> <xpath> /weblogic-web-app/session-descriptor/invalidation-interval-secs </xpath> </variable-assignment> </module-descriptor> <module-descriptor external="false"> <root-element>web-app</root-element> <uri>WEB-INF/web.xml</uri> </module-descriptor> </module-override> <config-root xsi:nil="true"></config-root> </deployment-plan>
Note that the plan generator can generate a plan variable only from schema-based descriptors and not from DTD-based ones. You can use the
weblogic.DDConverter command-line tool to generate schema-based descriptors from DTD-based ones. See the product documentation for more information.
Another extension to the J2EE Deployment API is the introduction of deployment validation. Many applications assume that resources such as JDBC connection pool or JMS destination have already been configured. So the application deployment may fail if those resources are not available at deployment time. When deploying applications, it is the administrator's or deployer's responsibility to create or provision those resources in the new environment.
To solve this problem, WebLogic Server has a deployment validation feature. This feature covers validation of the deployment unit and runtime resources required for that deployment unit. The deployment tools like WebLogic Server Administration Console or WebLogic Workshop provide interactive phases of configuration, custom configuration, and pre-deployment validation. While deploying applications with these tools, the resources on which the application depends will be automatically detected, and the user will be prompted for an option to configure/deploy the external resources.
For example, if an application depends on a JDBC data source, the containers will check if that data source (and its corresponding connection pool) exists. If it does not exist, the user will be presented with an option to configure and deploy that resource. This certainly is an enhancement that should be considered in a deployment API; incorporating error details from deployment tools is very useful. Furthermore, the error details can be used to offer creation of missing resources or selecting suitable alternatives.