Programming WebLogic Deployment
|
 |
 |
|
 |
 |
Configuring Applications for Deployment
The term configuration refers to the process of preparing an application or deployable resource for deployment to WebLogic Server. The J2EE Deployment API standard (JSR-88) differentiates between a configuration session and deployment. They are distinguished as follows:
- Application Configuration involves: Generation of WebLogic descriptors, which go into a Deployment Plan
- Deployment tasks are: Distributing, Starting, Stopping, Redeploying, Undeploying
The following sections describe how to configure an application for deployment using the WebLogic Deployment API:
- Configuring an Application
- Overview of the Configuration Process
- Application Evaluation
- Performing Front-End Configuration
- Customizing Deployment Configuration
- Deployment Preparation
Configuring an Application
Taking a look once again at the deployment phases, those phases that are covered by configuration are the first four:
- Application evaluation - this phase inspects and evaluates the application files to determine the structure of the application and content of the standard descriptors embedded in it.
- Initialize a deployment session by obtaining a
WebLogicDeploymentManager. See Application Evaluation. - Create a
WebLogicJ2eeApplicationObjectorWebLogicDeployableObjectto represent the J2EE Configuration of an Enterprise Application (EAR) or standalone module (WAR, EAR, RAR, or CAR). If it is an EAR, there will be child objects generated. This is the deployable object as described in the J2EE Deployment API standard (JSR-88). See Creating a Deployable Object. - Front-end configuration - this phase establishes configuration information based on information embedded within the application. This information may be in the form of WebLogic Server descriptors, defaults, and user provided deployment plans.
- Create a
WebLogicDeploymentConfigurationobject to represent the WebLogic Server configuration of an Application. This begins a process that result in a Deployment Plan for this deployment of this object. See Deployment Configuration. - Restore existing WebLogic Server configuration values from an existing deployment plan, if available. See Performing Front-End Configuration.
- Customizing deployment configuration - this phase involves a conversation with the user to establish desired configuration and tuning for the specific deployment. This phase resolves previously unresolved elements and allows for overriding existing configuration and/or establishment of environment specific information.
Modify individual WebLogic Server configuration values based on user inputs and the selected WebLogic Server targets. See Customizing Deployment Configuration.
Within the first four phases, a deployment configuration tool performs several steps. Each step of each phase is described in detail below. But before embarking upon coding these tasks, it is necessary to take note of the tools WebLogic provides to handle configuration information.
The WebLogic Server SessionHelper Class
SessionHelper simplifies the most common operational patterns such as accessing a DeploymentManager, Initializing a configuration session, saving deployment plans, JMS Submodule targeting, and Inspecting applications.
Tools that code directly to WebLogic J2EE Deployment API implementations are encouraged to use SessionHelper and each of the sections that follow, a subsection devoted to SessionHelper will appear so that you can use it in your implementation. Also see the Javadocs for more information about SessionHelper.
Session Cleanup
Temporary files are created during a configuration session. Archives get exploded into the temp area. They can be removed only after session is complete. There is no standard api defined to close out a session. There are close() methods to WebLogicDeployableObject and WebLogicDeploymentConfiguration. SessionHelper.close() cleans everything up after that. It is up to the tool programmer to use these methods or the temp directories may fill up over time.
Overview of the Configuration Process
One of the tasks handled by deployer tools is configuring an application for a successful deployment. Most configuration information for an application is provided in its deployment descriptors. The supported descriptors are listed below. Certain elements in these descriptors refer to external objects and/or must be handled in server-specific ways. Different server vendors manage this in different ways. WebLogic Server uses descriptor extensions for this purpose. These are the WebLogic Server specific deployment descriptors. The mapping between standard descriptors and WebLogic Server descriptors is managed via DDBeans and DConfigBeans, which are described in this document.
Types of Configuration Information
The primary configuration information for an application falls into two distinct but related categories:
J2EE Configuration
The J2EE configuration for an application defines the basic semantics and runtime behavior of the application, as well as the external resources that are required for the application to function. This configuration information is stored in the standard J2EE deployment descriptor files associated with the application, as listed in Table 3-1.
Table 3-1 Standard J2EE Deployment Descriptors
Complete and valid J2EE deployment descriptors are a required input to any application configuration session.
Because the J2EE configuration controls the fundamental behavior of an application, the J2EE descriptors are typically defined only during the application development phase, and are not modified when the application is later deployed to a different environment. For example, when you deploy an application to a testing or production domain, the application's behavior (and therefore its J2EE configuration) should remain the same as when application was deployed in the development domain. See Performing Front-End Configuration for more information.
DDBeans
DDBeans are described by the javax.enterprise.deploy.model package. These objects provide a generic interface to elements in standard deployment descriptors, but can also be used as an XPath based mechanism to access arbitrary XML files that follow the basic form of the standard descriptors. Examples of such files would be WebLogic Server descriptors and Web Services descriptors.
The DDBean representation of a descriptor is a tree of DDBeans, with a specialized DDBean, a DDBeanRoot, at the root of the tree. DDBeans provide accessors for the element name, id attribute, root, and text of the descriptor element they represent.
The DDBeans for an application are populated by the model plug-in, the tool provider implementation of javax.enterprise.deploy.model. An application is represented by the DeployableObject interface. The WebLogic Server implementation of this interface is a public class, weblogic.deploy.api.model.WebLogicDeployableObject. A WebLogic Server based deployer tool acquires an instance of WebLogicDeployableObject object for an application via the createDeployableObject factory methods. This results in the DDBean tree for the application being created and populated by the elements in the J2EE descriptors embedded in the application. If the application is an EAR, multiple WebLogicDeployableObject objects are created. The root WebLogicDeployableObject, extended as WebLogicJ2eeApplicationObject, would represent the EAR module, with its child WebLogicDeployableObject instances being the modules contained within the application. These would be WARs, EJBs, RARs and CARs.
Representing J2EE and WebLogic Server Configuration Information
Both the J2EE deployment descriptors and any available WebLogic Server descriptors are used as inputs to the application configuration process. You use the deployment API to represent both the J2EE configuration and WebLogic Server configuration as Java objects.
The J2EE configuration for an application is obtained by creating either a WebLogicJ2eeApplicationObject for an EAR, or a WeblogicDeployableObject for a standalone module. (A WebLogicJ2eeApplicationObject contains multiple DeployableObject instances to represent individual modules included in the EAR.)
Each WebLogicJ2eeApplicationObject or WeblogicDeployableObject contains a DDBeanRoot to represent a corresponding J2EE deployment descriptor file. J2EE descriptor properties for EARs and modules are represented by one or more DDBean objects that reside beneath the DDBeanRoot. DDBean components provide standard getter methods to access individual deployment descriptor properties, values, and nested descriptor elements.
The Relationship Between J2EE and WebLogic Server Descriptors
J2EE descriptors and WebLogic Server descriptors are directly related in the configuration of external resources. A J2EE descriptor defines the types of resources that the application requires to function, but it does not identify the actual resource names to use. The WebLogic Server descriptor binds the resource definition in the J2EE descriptor name to the name of an actual resource in the target domain.
The process of binding external resources is a required part of the configuration process. Binding resources to the target domain ensures that the application can locate resources and successfully deploy.
J2EE descriptors and WebLogic Server descriptors are also indirectly related in the configuration of tuning parameters for WebLogic Server. Although no elements in the standard J2EE descriptors require tuning parameters to be set in WebLogic Server, the presence of individual descriptor files indicates which tuning parameters are of interest during the configuration of an application. For example, although the ejb.xml descriptor does not contain elements related to tuning the WebLogic Server EJB container, the presence of an ejb.xml file in the J2EE configuration indicates that tuning properties can be configured before deployment.
WebLogic Server Configuration
The WebLogic Server descriptors provide for enhanced features, resolution of external resources, and tuning associated with application semantics. Applications may or may not have these descriptors embedded in the application. The WebLogic Server configuration for an application:
- Binds external resource names to resource definitions in the J2EE deployment descriptor so that the application can function in a given WebLogic Server domain
- Defines tuning parameters for the application containers
- Provides enhanced features for J2EE applications and standalone modules
The attributes and values of a WebLogic Server configuration are stored in the WebLogic Server deployment descriptor files, as shown in Table 3-2.
Table 3-2 WebLogic Server Deployment Descriptors
Because different WebLogic Server domains provide different types of external resources and different levels of service for the application, the WebLogic Server configuration for an application typically changes when the application is deployed to a new environment. For example, a production staging domain might use a different database vendor and provide more usable memory than a development domain. Therefore, when moving the application from development to the staging domain, the application's WebLogic Server descriptor values need to be updated in order to make use of the new database connection and available memory.
The primary job of a deployment configuration tool is to ensure that an application's WebLogic Server configuration is valid for the selected WebLogic targets.
DConfigBeans
DConfigBeans (config beans) are the objects used to convey server configuration requirements to a deployer tool, and are also the primary source of information used to create deployment plans. Config beans are Java Beans and can be introspected for their properties. They also provide basic property editing capabilities.
DConfigBeans are created from information in embedded WebLogic Server descriptors, deployment plans, and input from an IDE style deployer tool.
A DConfigBean is potentially created for every weblogic Descriptor element that is associated with a dependency of the application. Descriptors are entities that describe resources that are available to the application, represented by a JNDI name provided by the server.
Descriptors are parsed into memory as a typed bean tree while setting up a configuration session. The DConfigBean implementation classes delegate to the WebLogic Server descriptor beans. Only beans with dependency properties (e.g. resource references) will have a DConfigBean. The root of descriptor always has a DConfigBeanRoot.
Bean Property accessors return a child DConfigBean for elements that require configuration or a descriptor bean for those that do not. Property accessors return data from the descriptor beans.
Modifications to bean properties result in plan overrides. Plan overrides for existing descriptors are handled via variable assignments. If the application does not come with the relevant WebLogic Server descriptors, they will be automatically created and placed in an external plan directory. For external deployment descriptors, the change is made directly to the descriptor. Embedded descriptors are never modified on disk.
Application Evaluation
The Application Evaluation phase consists of the following possible deployment operations:
- Initialize a deployment session by obtaining a
WebLogicDeploymentManager. - Create a
WebLogicJ2eeApplicationObjectorWebLogicDeployableObjectto represent the J2EE Configuration of an Enterprise Application (EAR) or standalone module (WAR, EAR, RAR, or CAR). If it is an EAR, there will be child objects generated. This is the deployable object as described in the J2EE Deployment API standard (JSR-88)
A deployment manager provides an interface to the WebLogic Server deployment infrastructure. To initialize a deployment session for a deployment tool, you create a new deployment manager.
The deployment manager is implemented using the factory pattern. You first obtain a deployment factory class by specifying its name, weblogic.deployer.spi.factories.internal.DeploymentFactoryImpl, and then register the factory class with a javax.enterprise.deploy.spi.DeploymentFactoryManager instance. For instance:
Class WlsFactoryClass = Class.forname("weblogic.deployer.spi.factories.internal.DeploymentFactoryImpl");
DeploymentFactory myDeploymentFactory = (DeploymentFactory) WlsFactoryClass.newInstance();
DeploymentFactoryManager.getInstance().registerDeploymentFactory(myDeploymentFactory);
After you have registered the deployment factory, you can use it with a specific URI to obtain a deployment manager that has the functionality you require. This requires you to choose a type of deployment manager.
Types of Deployment Managers
WebLogic Server provides a single implementation for javax.enterprise.deploy.spi.DeploymentManager that behaves differently depending on the URI you specify when instantiating the class from a factory. WebLogic Server provides two basic types of deployment manager:
- A disconnected deployment manager has no connection to a WebLogic Server instance. You can use a disconnected deployment manager to configure an application on a remote client machine, but you cannot use it to perform deployment operations. (For example, you cannot use a disconnected deployment manager to distribute an application.)
- A connected deployment manager has a connection to the Administration Server for the WebLogic Server domain, and can be used both to configure and deploy applications.
A connected deployment manager can be further classified as being either local to the Administration Server, or running on a remote machine that is connected to the Administration Server. The local or remote classification determines whether file references are treated as being local or remote to the Administration Server.
Table 3-3 summarizes each basic type of deployment manager.
Connected and Disconnected Deployment Manager URIs
All DeploymentManager's obtained from WebLogicDeploymentFactory support the WebLogic Server extensions. You obtain a specific type of deployment manager by calling the correct method on the deployment factory instance and supplying a string constant defined in weblogic.deployer.spi.factories.WebLogicDeploymentFactory that describes the type of deployment manager you want to obtain. Connected deployment managers require that you pass a valid server URI and credentials to the method in order to obtain a connection to the Administration Server.
Table 3-4 summarizes the method signatures and constants used to obtain the different types of deployment manager.
Table 3-4 URIs for Obtaining a WebLogic Server Deployment Manager
The sample code in Listing 3-1 shows how to obtain a disconnected deployment manager.
Listing 3-1 Obtaining a Disconnected Deployment Manager
Class WlsFactoryClass = Class.forname("weblogic.deployer.spi.factories.internal.DeploymentFactoryImpl");
DeploymentFactory myDeploymentFactory = (DeploymentFactory) WlsFactoryClass.newInstance();
DeploymentFactoryManager.getInstance().registerDeploymentFactory(myDeploymentFactory);
WebLogicDeploymentManager myDisconnectedManager = (WebLogicDeploymentManager)myDeploymentFactory.getDisconnectedDeploymentManager(WebLogicDeploymentFactory.LOCAL_DM_URI);
The deployment factory contains a helper method, createUri() to help you form the URI argument for creating connected deployment managers. For example, to create a disconnected, remote deployment manager, replace the final line of code with:
(WebLogicDeploymentManager)myDeploymentFactory.getDeploymentManager(myDeploymentFactory.createUri(WebLogicDeploymentFactory.REMOTE_DM_URI, "localhost", "7001", "weblogic", "weblogic"));
Using SessionHelper to Obtain a Deployment Manager
The SessionHelper helper class provides several convenience methods to help you easily obtain a deployment manager without manually creating and registering the deployment factories, as in Listing 3-1. The SessionHelper code required to obtain a disconnected deployment manager consists of a single line:
DeploymentManager myDisconnectedManager = SessionHelper.getDisconnectedDeploymentManager();
Likewise, you can use the SessionHelper to obtain a connected deployment manager, as shown below:
DeploymentManager myConnectedManager = SessionHelper.getDeploymentManager("adminhost", "7001", "weblogic", "weblogic"));
This method assumes a remote connection to an admin server (adminhost). See the Javadocs for more information about SessionHelper.
Creating a Deployable Object
The second part of Application Evaluation is creating the Deployable Object, a container for the application you are intending to deploy. Once you have initialized a configuration session by obtaining a WebLogicDeploymentManager, you can create the deployable object in one of two ways. The direct approach uses the WebLogicDeployableObject class of the model package. You do this as shown below:
WebLogicDeployableObject myDeployableObject = WebLogicDeployableObject.createWebLogicDeployableObject("myAppFileName");
Once the deployable object is created, a configuration can be created for the applications deployment.
Using SessionHelper to obtain a Deployable Object
The SessionHelper helper class provides a convenience method to help you easily obtain a deployable object. The SessionHelper code required to obtain a deployable object is pretty simple:
SessionHelper.setApplicationRoot(root);
WebLogicDeployableObject myDeployableObject = SessionHelper.getDeployableObject();
As you can see, there is no application specified in the getDeployableObject() call. SessionHelper assumes that the application in the root directory set by setApplicationRoot() is the one being used. This is the structure described in the section of the previous chapter. Once you have set the application root directory, SessionHelper can perform other operations automatically without further complications, such as explicitly naming the dispatch file location, the deployment plan location, etcetera.
If this is not the directory structure you are using or if there are several applications in the same directory, you may set the application file name using the setApplication method. This is done as follows:
SessionHelper.setApplication(AppFileName);
Thus you can continue to use SessionHelper even if you have another directory structure in mind. The getDeployableObject method will automatically assume the application you have set is being deployed.
Summary
Application Evaluation consists of obtaining a deployment manager and a deployable object container for your application. These set the stage for further deployment operations.
Performing Front-End Configuration
The Front-End configuration phase is comprised of two possible logical operations:
- Create a
WebLogicDeploymentConfigurationobject to represent the WebLogic Server configuration of an Application. This begins a process that result in a Deployment Plan for this deployment of this object. - Restore existing WebLogic Server configuration values from an existing deployment plan, if available
A deployment plan is an XML document that contains the environmental configuration for an application, referred to as its front-end configuration. It separates the environment specific details of an application from the logic of the application. A deployment plan is not required for every application. It is required if the application expects specific attributes to be provided by the descriptors, as opposed to the generic values generated automatically. You may have a deployment plan for each environment in which the application will be deployed.
The deployment plan has several purposes:
- It describes the application structure. It will tell you what modules are in the application.
- It allows developers and administrators to update the configuration of an application without modifying the application archive.
- It contains environment specific descriptor override information. By modifying this file, you can override environment variables for the application so that it can be used in a different environment.
The information in a deployment plan can be loaded into and extracted from a deployment configuration. The deployment configuration is the active java object that is used by the Deployment Manager to obtain configuration information. The deployment plan exists outside of the application so that it can be changed without manipulating the application.
Deployment Configuration
The server configuration for an application is encapsulated in the javax.enterprise.deploy.spi.DeploymentConfiguration interface. A DeploymentConfiguration can also be viewed as the object representation of a deployment plan. A DeploymentConfiguration is associated with a DeployableObject via the DeploymentManager.createConfiguration method. Following the creation of the DeploymentConfiguration, a DConfigBean tree representing the configurable and tunable elements contained in any and all WebLogic Server descriptors is available. If there are no WebLogic Server descriptors in the application, then a DConfigBean tree is created using available default values. Binding properties that have no defaults will be left unset.
It is the responsibility of the deployer tool to ensure the DConfigBean tree is fully populated before using it to distribute an application. The DConfigBeans can be populated from scratch as shown in the configuration code below:
public class DeploymentSession {
DeploymentManager dm;
DeployableObject dObject = null;
DeploymentConfiguration dConfig = null;
Map beanMap = new HashMap();
...
// Assumes app is a web app.
public void initializeConfig(File app) throws Throwable {
/**
* Init the wrapper for the DDBeans for this module. This example assumes
* it is using the WLS implementation of the model api.
*/
dObject= WebLogicDeployableObject.createDeployableObject(app);
//Get basic configuration for the module
dConfig = dm.createConfiguration(dObject);
/**
* At this point the DeployableObject is populated. Populate the
* DeploymentConfigurationbased on its content.
* We first ask the DeployableObject for its root.
*/
DDBeanRoot root = dObject.getDDBeanRoot();
/**
* The root DDBean is used to start the process of identifying the
* necessary DConfigBeans for configuring this module.
*/
System.out.println("Looking up DCB for "+root.getXpath());
DConfigBeanRoot rootConfig = dConfig.getDConfigBeanRoot(root);
collectConfigBeans(root, rootConfig);
/**
* The DeploymentConfiguration is now initialized, although not necessarily
* completely setup.
*/
FileOutputStream fos = new FileOutputStream("test.xml");
dConfig.save(fos);
}
// bean and dcb are a related DDBean and DConfigBean.
private void collectConfigBeans(DDBean bean, DConfigBean dcb) throws Throwable{
DConfigBean configBean;
DDBean[] beans;
if (dcb == null) return;
/**
* Maintain some sort of mapping between DDBeans and DConfigBeans
* for later processing.
*/
beanMap.put(bean,dcb);
/**
* The config bean advertises xpaths into the web.xml descriptor it
* needs to know about.
*/
String[] xpaths = dcb.getXpaths();
if (xpaths == null) return;
/**
* For each xpath get the associated DDBean and collect its associated
* DConfigBeans. Continue this recursively until we have all DDBeans and
* DConfigBeans collected.
*/
for (int i=0; i<xpaths.length; i++) {
beans = bean.getChildBean(xpaths[i]);
for (int j=0; j<beans.length; j++) {
/**
* Init the DConfigBean associated with each DDBean
*/
System.out.println("Looking up DCB for "+beans[j].getXpath());
configBean = dcb.getDConfigBean(beans[j]);
collectConfigBeans(beans[j], configBean);
}
}
This example merely iterates through the DDBean tree, requesting the DConfigBean for each DDBean to be instantiated.
DeploymentConfiguration objects may be persisted as deployment plans via DeploymentConfiguration.save(). A deployer tool may allow the user to import a saved deployment plan into the DeploymentConfiguration object instead of populating it from scratch. DeploymentConfiguration.restore() provides this capability. This supports the idea of having a repository of deployment plans for an application, with different plans being applicable to different environments.
Similarly the DeploymentConfiguration may be pieced together via partial plans, which were presumably saved in a repository from a previous configuration session. A partial plan maps to a module-root of a DConfigBean tree. DeploymentConfiguration.saveDConfigBean() and DeploymentConfiguration.restoreDConfigBean() provides this capability.
Parsing of the WebLogic Server descriptors in an application occurs automatically when a DeploymentConfiguration is created. The descriptors ideally conform to the most current schema. For older applications that include descriptors based on WebLogic Server 8.1 and earlier DTDs, a transformation is performed. Old descriptors are supported but they cannot be modified using a deployment plan. Therefore, any DOCTYPE declarations must be converted to name space references, and element specific transformations must be performed.
Reading in Information with SessionHelper
SessionHelper.initializeConfiguration will process all standard and WebLogic Server descriptors in the application.
Prior to invoking initializeConfiguration, you can specify an existing deployment plan to associate with the application using the SessionHelper.setPlan() method. With a plan set, you may read in a deployment plan with the DeploymentConfiguration.restore() method, in accordance with the J2EE Deployment API standard (JSR-88). In addition, the DeploymentConfiguration.initializeConfiguration() method automatically restores configuration information once a plan is set.
When initiating a configuration session with the SessionHelper class, you can easily initiate and fill a deploymentConfiguration object with deployment plan information as illustrated below:
DeploymentManager dm = SessionHelper.getDisconnectedDeploymentManager();
SessionHelper helper = SessionHelper.getInstance(dm);
// specify location of archive
helper.setApplication(app);
// specify location of existing deployment plan
helper.setPlan(plan);
// initialize the configuration session
helper.initializeConfiguration();
DeploymentConfiguration dc = helper.getConfiguration();
The above code produces the deployment configuration and its associated WebLogicDDBeanTree. At this point, you begin constructing the WebLogicDConfigBean tree as usual.
Validating a Configuration
Validation of the configuration occurs mostly during the parsing of the descriptors, which occurs when the app's descriptors are processed. Validation consists of ensuring the descriptors are valid xml documents and that they abide by their respective schemas.
Summary
Performing Front-End configuration involves creating a WebLogicDeploymentPlan and populating it and its associated bean trees with configuration information from a deployment plan. Although a deployment plan is optional, a valid WebLogicDeploymentConfiguration is required in order to change configuration values in the deployment configuration (described below).
Customizing Deployment Configuration
The Customizing Deployment Configuration phase involves modifying individual WebLogic Server configuration values based on user inputs and the selected WebLogic Server targets. The configuration at this point is only as good as the descriptors or pre-existing plan associated with the application. The DConfigBeans are designed as Java Beans and can be introspected, allowing the tool to present their content in some meaningful way. The properties of a DConfigBean are, for the most part, those that are configurable. Key properties (those that provide uniqueness) are also exposed. Setters are only exposed on those properties that can be safely modified. In general, properties that describe application behavior are not modifiable. All properties are typed as defined by the descriptor schemas.
The property getters return subordinate DConfigBeans, arrays of DConfigBeans, descriptor beans, arrays of descriptor beans, simple values (primitives and java.lang objects), or arrays of simple values. Descriptor beans represent descriptor elements that, while modifiable, do not require DConfigBean features. e.g. there is no standard descriptor element they are directly related to.
Editing a configuration is accomplished by invoking the property setters.
The pure JSR-88 DConfigBean class allows the tool to access beans via the getDConfigBean(DDBean) method, or via introspection. The former approach is convenient for tools that present the standard descriptor based on the DDBean's in the application's DeployableObject, and then provide direct access to each DDBean's configuration (its DConfigBean). This provides configuration of the essential resource requirements an application may have. The latter approach (introspection) allows a tool to present the application's entire configuration, while perhaps highlighting the required resource requirements.
Introspection is, of course, required in both approaches in order to present or modify descriptor properties. The difference is in how the tool presents the information: either driven by standard descriptor content or WebLogic Server descriptor content.
A system of modifying configuration information would include a user interface to ask for changes. A system for obtaining and setting such changes is illustrated in the code sample below:
// Introspect the DConfigBean tree and ask for input on properties with setters
private void processBean(DConfigBean dcb) throws Exception {
if (dcb instanceof DConfigBeanRoot) {
System.out.println("Processing configuration for descriptor: "+dcb.getDDBean().getRoot().getFilename());
}
// get property descriptor for the bean
BeanInfo info = Introspector.getBeanInfo(dcb.getClass(),Introspector.USE_ALL_BEANINFO);
PropertyDescriptor[] props = info.getPropertyDescriptors();
String bean = info.getBeanDescriptor().getDisplayName();
PropertyDescriptor prop;
for (int i=0;i<props.length;i++) {
prop = props[i];
// only allow primitives to be updated
Method getter = prop.getReadMethod();
if (isPrimitive(getter.getReturnType())) // see isPrimitive method below
{
writeProperty(dcb,prop,bean); //see writeProperty method below
}
// recurse on child properties
Object child = getter.invoke(dcb,new Object[]{});
if (child == null) continue;
// traversable if child is a DConfigBean.
Class cc = child.getClass();
if (!isPrimitive(cc)) {
if (cc.isArray()) {
Object[] cl = (Object[])child;
for (int j=0;j<cl.length;j++) {
if (cl[j] instanceof DConfigBean) processBean((DConfigBean) cl[j]);
}
} else {
if (child instanceof DConfigBean) processBean((DConfigBean) child);
}
}
}
}
// if the property has a setter then invoke it with user input
private void writeProperty(DConfigBean dcb, PropertyDescriptor prop, String bean)
throws Exception {
Method getter = prop.getReadMethod();
Method setter = prop.getWriteMethod();
if (setter != null) {
PropertyEditor pe = PropertyEditorManager.findEditor(prop.getPropertyType());
if (pe == null && String[].class.isAssignableFrom(getter.getReturnType())) pe = new StringArrayEditor(); // see StringArrayEditor class below
if (pe != null) {
Object oldValue = getter.invoke(dcb,new Object[0]);
pe.setValue(oldValue);
String val = getUserInput(bean,prop.getDisplayName(),pe.getAsText());
// see getUserInput method below
if (val == null || val.length() == 0) return;
pe.setAsText(val);
Object newValue = pe.getValue();
prop.getWriteMethod().invoke(dcb,new Object[]{newValue});
}
}
}
private String getUserInput(String element, String property, String curr) {
try {
System.out.println("Enter value for "+element+"."+property+". Current value is: "+curr);
return br.readLine();
} catch (IOException ioe) {
return null;
}
}
// Primitive means a java primitive or String object here
private boolean isPrimitive(Class cc) {
boolean prim = false;
if (cc.isPrimitive() || String.class.isAssignableFrom(cc)) prim = true;
if (!prim) {
// array of primitives?
if (cc.isArray()) {
Class ccc = cc.getComponentType();
if (ccc.isPrimitive() || String.class.isAssignableFrom(ccc)) prim = true;
}
}
return prim;
}
/**
* Custom editor for string arrays. Input text is converted into tokens using
* commas as delimiters
*/
private class StringArrayEditor extends PropertyEditorSupport {
String[] curr = null;
public StringArrayEditor() {super();}
// comma separated string
public String getAsText() {
if (curr == null) return null;
StringBuffer sb = new StringBuffer();
for (int i=0;i<curr.length;i++) {
sb.append(curr[i]);
sb.append(',');
}
if (curr.length > 0) sb.deleteCharAt(sb.length()-1);
return sb.toString();
}
public Object getValue() { return curr; }
public boolean isPaintable() { return false; }
public void setAsText(String text) {
if (text == null) curr = null;
StringTokenizer st = new StringTokenizer(text,",");
curr = new String[st.countTokens()];
for (int i=0;i<curr.length;i++) curr[i] = new String(st.nextToken());
}
public void setValue(Object value) {
if (value == null) {
curr = null;
} else {
String[] v = (String[])value; // let caller handle class cast issues
curr = new String[v.length];
for (int i=0;i<v.length;i++) curr[i] = new String(v[i]);
}
}
}
Beyond the mechanics of the rudimentary user interface, any interface that would enable changes to the configuration by an administrator or user would use the property setters as shown above.
Targets
Targets are associated with WebLogic servers, clusters, web servers, virtual hosts and JMS servers. This is captured in the weblogic.deploy.api.spi.WebLogicTarget Javadocs.
Application Naming
In WebLogic Server, application names are provided by the deployment tool. Names of modules contained within an application are based on the associated archive or root directory name of the modules. These names are persisted in the configuration MBeans constructed for the application.
In J2EE deployment there is no mention of the configured name of an application or its constituent modules, other than in the TargetModuleID object. Yet TargetModuleIDs exist only for applications that have been distributed to a WebLogic Server domain. Hence there is a need to represent application and module names in a deployer tool prior to distribution. This representation should be consistent with the names assigned by the server when the application is finally distributed.
The tool plug-in constructs its view of an application via the DeployableObject and J2eeApplicationObject classes. These represent standalone modules and EARs, respectively. Each of these has a direct relationship to a DDBeanRoot object. When presented with a distribution where the name is not configured, one will be derived for it. If the distribution is a File object, the file's name will be used. If the archive is offered as an input stream, a random name will be used for the root module.
Deployment Preparation
The deployment preparation phase involves saving the resulting plan from a configuration session. It is handled by the DeploymentConfiguration.save() method (another standard J2EE Deployment API method). You can use the SessionHelper.savePlan() method to do this; it saves new copy of deployment plan along with any external documents in the plan directory.
The DeploymentConfiguration.save methods will create an XML file based on the deployment plan schema, consisting of a serialization of the current collection of DConfigBeans, along with any variable assignments and definitions. The DConfigBean trees are always saved as external descriptors. These descriptors will only be saved if they do not already exist in the application archive or the external configuration area. i.e., the save operation will not overwrite existing descriptors. The DeploymentConfiguration.saveDConfigBean method will, however, overwrite files. This is not to say that any changes made to the configuration are lost. Rather they are handled using variable assignments.
As noted before, the DeploymentConfiguration.restore methods are used to create config beans based on a previously saved deployment plan (see Performing Front-End Configuration). An entire collection of config beans may be restored or the tool can restore a subset of the config beans. e.g., it is possible to save/restore just the config beans for a specific module in an application. This allows for a degree of flexibility in configuring an application.
