text:
�:zDoa�, mimetypeapplication/epub+zipPK �:zD iTunesMetadata.plistm��
Deploying Applications with the WebLogic Deployment API
12c (12.1.2)
June 2013
This document describes the WebLogic Deployment API and performing deployment operations programmatically for WebLogic Server applications.
Oracle Fusion Middleware Deploying Applications with the WebLogic Deployment API, 12c (12.1.2)
Copyright © 2007, 2013, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate failsafe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.
This chapter describes application deployment in WebLogic Server. Application deployment distributes the information created in Chapter 3, "Configuring Applications for Deployment" to the Administration Server for server-side processing and application startup. Your deployment tool must be able to successfully complete the deployment operations outlined in this chapter.
This chapter includes the following sections:
Your deployment tool must instantiate and register the
DeploymentFactory objects it uses. You can implement your own mechanism for managing
DeploymentFactory objects. WebLogic Server
DeploymentFactory objects are advertised in a manifest file stored in the
wldeploy.jar file. The manifest contains entries of the fully qualified class names of the factories, separated by whitespace. For example, if you assume that the
DeploymentFactory- objects reside in a fixed location and are included in the deployment tool classpath, the deployment tool registers any
DeploymentFactory objects it recognizes at startup. See Example 4-1.
Example 4-1 Registered Deployment Factory in the Manifest File
MANIFEST.MF: Manifest-version: 1.0 Implementation-Vendor: BEA Systems Implementation-Title: WebLogic Server 9.0 Mon May 29 08:16:47 PST 2006 221755 Implementation-Version: 22.214.171.124 J2EE-DeploymentFactory-Implementation-Class: weblogic.deploy.spi.factories.DeploymentFactoryImpl . . .
The standard
DeploymentFactory interface is extended by
weblogic.deploy.api.WebLogicDeploymentFactory. The additional methods provided in the extension are:
String[] getUris(): Returns an array of URI's that are recognized by
getDeploymentManager. The first URI in the array is guaranteed to be the default
DeploymentManager URI,
deployer:WebLogic. Only published URI's are returned in this array.
String createUri(String protocol, String host, String port): Returns a usable URI based on the arguments.
Your deployment tool must allocate a
DeploymentManager from a
DeploymentFactory, which is registered with the
DeploymentFactoryManager class, in order to perform deployment operations. In addition to configuring an application for deployment, the
DeploymentManager is responsible for establishing a connection to a Java EE server. The
DeploymentManager implementation is accessed using a
The following sections provide information on how a
DeploymentManager connects to a server instance:
Use the
DeploymentFactory.getDeploymentManager method to get a
DeploymentManager object. This method takes a URI, user ID and password as arguments. The URI has the following patterns:
When connecting to an Administration Server, the URI must also include the host and port, such as
deployer:WebLogic:localhost:7001. See Understanding DeploymentManager URI Implementations.
The following provides additional information on
DeploymentManager arguments:
When obtaining a disconnected
DeploymentManager, you do not need to include the
host:port because there is no connection to an Administration Server. For example, the URI can be
The user ID and password arguments are ignored if the deployment tool uses a pre-authenticated
You can access the URI of any
DeploymentManager implementation using the
DeploymentFactory.getUris() method.
getUris is an extension of
Depending on the URI specified during allocation, the
DeploymentManager object will have one of the following characteristics:
deployer:WebLogic: The
DeploymentManager is running locally on an Administration Server and any files referenced during the deployment session are treated as if they are local to the Administration Server.
deployer:WebLogic.remote: The
DeploymentManager is running remotely to the WebLogic Server Administration Server and any files referenced during the deployment session are treated as being remote to the Administration Server and may require uploading. For example, a distribute operation includes uploading the application files to the Administration Server.
deployer:WebLogic.authenticated: This is an internal, unpublished URI, usable by applications such as a console servlet that is already authenticated and has access to the domain management information. The
DeploymentManager is running locally on a WebLogic Administration Server and any files referenced during the deployment session are treated as if they are local to the Administration Server.
You can explicitly force the uploading of application files by using the
WebLogicDeploymentManager method enableFileUploads() method.
DeploymentManagers are either connected or disconnected. Connected
DeploymentManagers imply a connection to a WebLogic Server Administration Server. This connection is maintained until it is explicitly disconnected or the connection is lost. If the connection is lost, the
DeploymentManager reverts to a disconnected state.
Explicitly disconnecting a
DeploymentManager is accomplished using the
DeploymentManager.release method. There is no corresponding method for reconnecting the
DeploymentManager. Instead the deployment tool must allocate a new
Allocating a new
Most of the functional components of a
DeploymentManager are defined in the Java EE Deployment API specification. However, Oracle has extended the
DeploymentManager interface with the capabilities required by existing WebLogic Server-based deployment tools. Oracle WebLogic Server deployment extensions are documented at
The JSR-88 programming model revolves around employing
TargetModuleID objects (
TargetModuleIDs) and
ProgressObject objects. In general, target modules are specified by a list of
TargetModuleIDs which are roughly equivalent to deployable root modules and sub-module level MBeans. The
DeploymentManager applies the
TargetModuleIDs to deployment operations and tracks their progress. A deployment tool needs to query progress using a
ProgressObject returned for each operation. When the
ProgressObject indicates the operation is completed or failed, the operation is done.
The following sections provide an overview of WebLogic
DeploymentManager features:
WebLogic Server allows for a
DeploymentOptions argument (
weblogic.deploy.api.spi.DeploymentOptions) which supports the overriding of certain deployment behaviors. The argument may be
null, which provides standard behavior. Some of the options supported in this release are:
admin (test) mode
Retirement Policy
See DeploymentOptions Javadoc.
Distribution of new applications results in:
the application archive and plan is staged on all targets.
the application being configured into the domain.
Redistribution honors the staging mode already configured for an application.
The standard distribute operations does not support version naming. WebLogic Server provides
WebLogicDeploymentManager to extend the standard with a distribute operation that allows you to associate a version name with an application.
ProgressObject returned from a distribute provides a list of
TargetModuleIDs representing the application as it exists on the target servers. The targets used in the distribute are any of the supported targets. The
TargetModuleID represents the application's module availability on each target.
For new applications,
TargetModuleIDs represent the top level
AppDeploymentMBean objects.
TargetModuleIDs do not have child
TargetModuleIDs based on the modules and sub-modules in the application since the underlying
MBeans would only represent the root module. For pre-existing applications, the
TargetModuleIDs are based on
DeployableMBeans and any
AppDeploymentMBean and
SubAppDeploymentMBean in the configuration.
If you use the
distribute(Target[],InputStream,InputStream) method to distribute an application, the archive and plan represented by the input streams are copied from the streams into a temporary area prior to deployment which impacts performance.
The standard start operation only supports root modules; implying only entire applications can be started. Consider the following configuration.
<AppDeployment Name="myapp"> <SubDeployment Name="webapp1", Targets="serverx"/> <SubDeployment Name="webapp2", Targets="serverx"/> </AppDeployment>
TargetModuleID returned from
getAvailableModules(ModuleType.EAR) looks like:
myapp on serverx (implied) webapp1 on serverx webapp2 on serverx
start(tmid) would start
webapp1 and
webapp2 on
To start
webapp1, module level control is required. Configure module level control by manually creating a
TargetModuleID hierarchy.
WebLogicTargetModuleID root = dm.createTargetModuleID("myapp",
WebLogicTargetModuleID web = dm.createTargetModuleID(root,"webapp1",ModuleType.WAR);
dm.start(new TargetModuleID[]{web});
This approach uses the
TargetModuleID creation extension to manually create an explicit
TargetModuleID hierarchy. In this case the created
TargetModuleID would look like
myapp on serverx (implied) webapp1 on serverx
start operation does not modify the application configuration. Version support is built into the
TargetModuleIDs, allowing the user to start a specific version of an application. Applications may be started in normal or administration (test) mode.
deploy operation combines a
distribute and
start operation. Web applications may be deployed in normal or administration (test) mode. You can specify application staging using the
DeploymentOptions argument.
deploy operations use
TargetModuleIDs instead of
Targets for targeting, allowing for module level configuration.
deploy operation may change the application configuration based on the
TargetModuleIDs provided.
The standard
stop operation only supports root modules; implying only entire applications can be stopped. See the Application Start.
Oracle provides versioning support, allowing you to stop a specific version of an application. The
stop operation does not modify the application configuration. See Version Support.
The standard undeploy operation removes an application from the configuration, as specified by the
TargetModuleIDs. Individual modules can be undeployed. The result is that the application remains on the target, but certain modules are not actually configured to run on it. See the Application Start section for more detail on module level control.
WebLogicDeploymentManager extends undeploy in support of removing files from a distribution. This is a form of in-place redeployment that is only supported in Web applications, and is intended to allow you to remove static pages. See Version Support.
Standard redeployment support only applies to entire applications and employs side-by-side versioning to ensure uninterrupted session management. The
WebLogicDeploymentManager extends the
redeploy() method and provides the following additional support:
The in-place redeployment strategy works by immediately replacing a running application's deployment files with updated deployment files, such as:
Partial redeployment which involves adding or replacing specific files in an existing deployment.
Updating a configuration using a redeployment of a deployment plan
DeploymentManager implements the JSR-88 specification and restricts operations to root modules. Module level control is provided by manually constructing a module specific
TargetModuleID hierarchy using
When a new version of an application is redeployed, the old version should eventually be retired and undeployed. There are 2 policies for retiring old versions of applications:
(Default) The old version is retired when new version is active and old version finishes its in-flight operations.
The old version is retired when new version is active, retiring the old after some specified time limit of the new version being active.
The old version is not retired if the new version is in administration (test) mode.
Side-by-side versioning is used to provide retirement extensions, as suggested in the JSR-88 redeployment specification. This ensures that an application can be redeployed without interruption in service to its current clients. Details on deploying side-by-side versions can be found in "Redeploying Applications in a Production Environment" in Deploying Applications to Oracle WebLogic Server.
A Web application may be started in normal or administration (test) mode. Normal mode indicates the Web application is fully accessible to clients. Administration (test) mode indicates the application only listens for requests using the
admin channel. Administration (test) mode is specified by the
DeploymentOptions argument on the WebLogic Server extensions for
deploy and
redeploy. See DeploymentOptions Javadoc.
ProgressObjects to determine deployment state of your applications. These objects are associated with
DeploymentTaskRuntimeMBeans.ProgressObjects support the cancel operation but not the stop operation.
ProgessObjects are associated with one or more
TargetModuleIDs, each of which represents an application and its association with a particular target. For any
ProgressObject, its associated
TargetModuleIDs represent the application that is being monitored.
ProgressObject maintains a connection with the deployment framework, allowing it to provide a deployment tool with up-to-date deployment status. The deployment state transitions from running to completed or failed only after all
TargetModuleIDs involved have completed their individual deployments. The resulting state is
completed only if all
TargetModuleIDs are successfully deployed.
released state means that the
DeploymentManager was disconnected during the deployment. This may be due to a manual release, a network outage, or similar communication failures.
Example 4-2 shows how a
ProgressObject can be used to wait for a deployment to complete:
Example 4-2 Example Code to Wait for Completion of a Deployment
package weblogic.deployer.tools; import javax.enterprise.deploy.shared.*; import javax.enterprise.deploy.spi.*; import javax.enterprise.deploy.spi.status.*; /** * Example of class that waits for the completion of a deployment * using ProgressEvent's. */ public class ProgressExample implements ProgressListener { private boolean failed = false; private DeploymentManager dm; private TargetModuleID[] tmids; public void main(String[] args) { // set up DeploymentManager, TargetModuleIDs, etc try { wait(dm.start(
tmids)); } catch (IllegalStateException ise) { //... dm not connected } if (failed) System.out.println("oh no!"); } void wait(ProgressObject po) { ProgressHandler ph = new ProgressHandler(); if (!po.getDeploymentStatus().isRunning()) { failed = po.getDeploymentStatus().isFailed(); return; } po.addProgressListener(ph); ph.start(); while (ph.getCompletionState() == null) { try { ph.join(); } catch (InterruptedException ie) { if (!ph.isAlive()) break; } } StateType s = ph.getCompletionState(); failed = (s == null ||
s.getValue() == StateType.FAILED.getValue()); po.removeProgressListener(ph); } class ProgressHandler extends Thread implements ProgressListener { boolean progressDone = false; StateType finalState = null; public void run(){ while(!progressDone){ Thread.currentThread().yield(); } } public void handleProgressEvent(ProgressEvent event){ DeploymentStatus ds = event.getDeploymentStatus(); if (ds.getState().getValue() != StateType.RUNNING.getValue()) { progressDone = true; finalState = ds.getState(); } } public StateType getCompletionState(){ return finalState; } } }
The following sections provide information on how to target objects:
The standard modules types are defined by
javax.enterprise.deploy.shared.ModuleType. This is extended to support WebLogic Server-specific module types: JMS, JDBC, INTERCEPT and CONFIG.
JSR-88 defines a secondary descriptor as additional descriptors that a module can refer to or make use of. These descriptors are linked to the root
DConfigBean of a module such that they are visible to a Java Beans based tool as they are child properties of a
DConfigBeanRoot object. Secondary descriptors are automatically included in the configuration process for a module.
An EJB or Web application may include a
webservers.xml descriptor. If present, the module is automatically configured with the WebLogic Server equivalent descriptor for configuring Web services as secondary descriptors. The deployment plan includes these descriptors as part of the module, not as a separate module.
CMP support in EJBs is configured using RDBMS descriptors that are identified for CMP beans in the
weblogic-ejb-jar.xml descriptor. The RDBMS descriptors support CMP11 and CMP20. Any number of RDBMS descriptors may be included with an EJB module. Provide these descriptors in the application archive or configuration area (
approot/plan). Although they are not created by the configuration process, they may be modified like any other descriptor. RDBMS descriptors are treated as secondary descriptors in the deployment plan.
JDBC modules are described by a single deployment descriptor with no archive. If the module is part of an EAR, the JDBC descriptors are specified in
weblogic-application.xml as configurable properties. You can deploy JDBC modules to WebLogic servers and clusters. Configuration changes to JDBC descriptors are handled as overrides to the descriptor.
If a JDBC module is part of an EAR, its configuration overrides are incorporated in the deployment plan as part of the EAR, not as separate modules.
JMS modules are described by a single deployment descriptor with no archive. If the module is part of an EAR, the JMS descriptors are specified in
weblogic-application.xml as configurable properties. JMS modules are deployed to JMS servers. Configuration changes to JMS descriptors are handled as overrides to the descriptor. JMS descriptors may identify "targetable groups". These groups are treated as sub-modules during deployment.
If the JMS module is part of an EAR, its configuration overrides are incorporated in the deployment plan as part of the EAR, not as separate modules.
Intercept modules are described by a single deployment descriptor with no archive. If the module is part of an EAR, the Intercept descriptors are specified in
weblogic-application.xml as configurable properties. Intercept modules are deployed to WebLogic Server servers and clusters. Configuration changes to Intercept descriptors are handled as overrides to the descriptor.
If the Intercept module is part of an EAR, its configuration overrides are incorporated in the deployment plan as part of the EAR, not as separate modules.
The Java EE Deployment API specification's definition of a target does not include any notion of its type. WebLogic Server supports standard modules and Oracle-specific module types as valid deployment targets. Target support is provided by the
weblogic.deploy.api.spi.WebLogicTarget an�$,�d
weblogic.deploy.api.spi.WebLogicTargetType classes. See Module Types.
TargetModuleID objects uniquely identify a module and a target it is associated with.
TargetModuleIDs are the objects that specify where modules are to be started and stopped. The object name used to identify the
TargetModuleID is of the form:
parent-name is the name of the ear this module is part of.
configured-name is the name used in the WebLogic Server configuration for this application or module
target-name is the server, cluster or virtual host where there module is targeted
target-type is the description of the target derived from
TargetModuleID.toString() will return this object name.
TargetModuleID is extended by
weblogic.deploy.api.spi.WebLogicTargetModuleID. This class provides the following additional functionality:
getServers—servers associated with the
TargetModuleID's target
isOnCluster—whether target is a cluster
isOnServer—whether target is a server
isOnHost—whether target is a virtual host
isOnJMSServer—whether target is a JMS server
getVersion—the version name
createTargetModuleID—factory for creating module specific targeting
WebLogicTargetModuleID is defined in more detail in the Javadocs.
WebLogicDeploymentManager is also extended with convenience methods that simplify working with
TargetModuleIDs. They are:
filter—returns a list of
TargetModuleIDs that match on application, module, and version
TargetModuleIDs based on an
TargetModuleIDs have a hierarchical relationship based on the application upon which they are based. The root
TargetModuleID of an application represents an EAR module or a stand-alone module. Child
TargetModuleIDs are modules that are defined by the root module's descriptor. For EARs, these are the modules identified in the
application.xml descriptor for the EAR. JMS modules may have child
TargetModuleIDs (sub-modules) as dictated by the JMS deployment descriptor. These may be children of an embedded module or the root module. Therefore, JMS modules can have three levels of
TargetModuleIDs for an application.
Typically, you get
TargetModuleIDs in a deployment operation or one of the
DeploymentManager.get*Modules() methods. These operations provide
TargetModuleIDs based on the existing configuration. In certain scenarios where more specific targeting is desired than is currently defined in the configuration, you may use the
createTargetModuleID method. This method creates a root
TargetModuleID that is specific to a module or sub-module within the application. This
TargetModuleID can then be used in any deployment operation. For operations that include the application archive, such as
deploy(), using one of these
TargetModuleIDs may result in the application being reconfigured. For example:
<AppDeployment Name="myapp", Targets="s1,s2"/>
The application is currently configured for all modules to run on
s1 and
s2. To provide more specific targeting, a deployment tool can do the following:
Target s1 = find("s1",dm.getTargets()); // find() is not part of this api WebLogicTargetModuleID root = dm.createTargetModuleID("myapp",ModuleType.EAR,s1); WebLogicTargetModuleID web = dm.createTargetModuleID(root,"webapp1",ModuleType.WAR); dm.deploy(new TargetModuleID[]{web},myapp,myplan,null);
myapp is reconfigured and
webapp is specifically targeted to only run on
s1. The new configuration is:
<AppDeployment Name="myapp", Targets="s1,s2"> <SubDeployment Name="webapp", Targets="s1"/> </AppDeployment>
Consider the deployment of a stand-alone JMS module, one that employs sub-modules. The module is defined by the file, simple-
jms.xml, which defines sub-modules,
sub1 and
sub2. The descriptor is fully configured for the environment hence no deployment plan is required, although the scenario described here would be the same if there was a deployment plan.
The tool to deploy this module performs the following steps:
// init the jsr88 session. This uses a WLS specific helper class, // which does not employ any WLS extensions DeploymentManager dm = SessionHelper.getDeploymentManager(host,port,user,pword); // get list of all configured targets // The filter method is a location where you could ask the user // to select from the list of all configured targets Target[] targets = filter(dm.getTargets()); // the module is distributed to the selected targets ProgressObject po = dm.distribute(targets,new File("jms.xml"),plan); // when the wait comes back the task is done waitForCompletion(po); // It is assumed here that it worked (there is no exception handling) // the TargetModuleIDs (tmids) returned from the PO correspond to all the // configured app/module mbeans for each target the app was distributed to. // This should include 3 tmids per target: the root module tmid and the // submodules' tmids. TargetModuleID[] tmids = po.getResultTargetModuleIDs(); // then to deploy the whole thing everywhere you would do this po = dm.start(tmids); // the result is that all sub-modules would be deployed on all the selected // targets, since they are implicitly targeted wherever the their parent is // targeted // To get sub-module level deployment you need to use WebLogic Server // extensions to create TargetModuleIDs that support module level targeting. // The following deploys the topic "xyz" on a JMS server WebLogicTargetModuleID root = dm.createTargetModuleID(tmids[i].getModuleID(),tmids[i],jmsServer); WebLogicTargetModuleID topic = dm.createTargetModuleID(root,"xyz",WebLogicModuleType.JMS); // now we can take the original list of tmids and let the user select // specific tmids to deploy po = dm.start(topic);
This chapter describes how to configure an application or deployable resource for deployment to a WebLogic Server instance using deployment descriptors. Certain elements in these descriptors refer to external objects and may require special handling depending on the server vendor. WebLogic Server uses descriptor extensions—WebLogic Server specific deployment descriptors. The mapping between standard descriptors and WebLogic Server descriptors is managed using
DDBeans and
This chapter includes the following sections:
This section provides information on the basic steps a deployment tool must implement to configure an application for deployment:
Application Evaluation—Inspection and evaluation of application files to determine the structure of the application and content of the embedded descriptors.
Initialize a deployment session by obtaining a
WebLogicDeploymentManager. See Application Evaluation.
Create a
WebLogicJ2eeApplicationObject or
WebLogicDeployableObject to represent the Java EE Configuration of an enterprise application (EAR) or stand-alone module (WAR, EAR, RAR, or CAR). If the object is an EAR, child objects are generated. See Java EE Deployment API standard (JSR-88) at
http://jcp.org/en/jsr/detail?id=88 and Create a Deployable Object.
Front-end Configuration—Creation of configuration information based on content embedded within the application. This content may be in the form of WebLogic Server descriptors, defaults, and user provided deployment plans.
Create a
WebLogicDeploymentConfiguration object to represent the WebLogic Server configuration of an application. This is the first step in creating a deployment plan for this object. See Deployment Configuration.
Restore existing WebLogic Server configuration values from an existing deployment plan, if available. See Perform Front-end Configuration.
Deployment Configuration—Modification of individual WebLogic Server configuration values based on user inputs and the selected WebLogic Server targets.
A deployment tool must provide the ability to modify individual WebLogic Server configuration values based on user inputs and selected WebLogic Server targets. See Customizing Deployment Configuration.
Deployment Preparation—Generation of the final deployment plan and preliminary client-side validation of the application.
A deployment tool must have the ability to save the modified WebLogic Server configuration information to a new deployment plan or to variable definitions in an existing Deployment Plan.
The following sections provide background information on the types of configuration information, how it is represented, and the relationship between Java EE and WebLogic Server descriptors:
Representing Java EE and WebLogic Server Configuration Information
The Relationship Between Java EE and WebLogic Server Descriptors
The Java EE configuration for an application defines the basic semantics and run-time 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 Java EE deployment descriptor files associated with the application, as listed in Table 3-1.
Table 3-1 Standard Java EE Deployment Descriptors
|Application or Standalone Module
|Java EE Descriptor
Enterprise Application
Web Application
Enterprise JavaBean
Resource Adapter
Client Application Archive
Complete and valid Java EE deployment descriptors are a required input to any application configuration session.
Because the Java EE configuration controls the fundamental behavior of an application, the Java EE 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 Java EE configuration) should remain the same as when application was deployed in the development domain. See Perform Front-end Configuration for more information.
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 Java EE 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 Java EE applications and stand-alone 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
|Application or Standalone Module
|WebLogic Server Descriptor
Enterprise Application
Web Application
Enterprise JavaBean
Resource Adapter
Client Archive
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.
Both the Java EE 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 Java EE configuration and WebLogic Server configuration as Java objects.
The Java EE configuration for an application is obtained by creating either a
WebLogicJ2eeApplicationObject for an EAR, or a
WeblogicDeployableObject for a stand-alone module. (A
WebLogicJ2eeApplicationObject contains multiple
DeployableObject instances to represent individual modules included in the EAR.)
WebLogicJ2eeApplicationObject or
WeblogicDeployableObject contains a
DDBeanRoot to represent a corresponding Java EE deployment descriptor file. Java EE descriptor properties for EARs and modules are represented by one or more
DDBean objects that reside beneath the
DDBean components provide standard getter methods to access individual deployment descriptor properties, values, and nested descriptor elements.
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.
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.
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 deployment tool acquires an instance of
WebLogicDeployableObject object for an application using the
createDeployableObject factory methods. This results in the
DDBean tree for the application being created and populated by the elements in the Java EE 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, such as WARs, EJBs, RARs and CARs.
Java EE descriptors and WebLogic Server descriptors are directly related in the configuration of external resources. A Java EE 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 Java EE 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.
Java EE descriptors and WebLogic Server descriptors are also indirectly related in the configuration of tuning parameters for WebLogic Server. Although no elements in the standard Java EE 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 Java EE configuration indicates that tuning properties can be configured before deployment.
DConfigBeans (config beans) are the objects used to convey server configuration requirements to a deployment 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 deployment tool.
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, such as resource references, have a
DConfigBean. The root of descriptor always has a
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 using variable assignments. If the application does not come with the relevant WebLogic Server descriptors, they are 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 consists of obtaining a deployment manager and a deployable object container for your application. Use the following steps:
Obtain a deployment factory class by specifying its name,
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);
The following sections provide information on how to obtain a deployment manager:
WebLogic Server provides a single implementation for
javax.enterprise.deploy.spi.DeploymentManager that behaves differently depending on the
URI specified 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. Use a disconnected deployment manager to configure an application on a remote client machine. It cannot be used it to perform deployment operations. (For example, a deployment tool 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 by a deployment tool to both to configure and deploy applications.
A connected deployment manager is 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 deployment manager types.
Table 3-3 WebLogic Server Deployment Manager Usage
|Deployment Manager Connectivity
Configuration tools only
Cannot perform deployment operations
Configuration and deployment tools local to the Administration Server
All files are local to the Administration Server machine
Configuration and Deployment for Tools on a remote machine (not on the Administration Server)
Distribution and Deployment operations cause local files to be uploaded to the Administration Server
DeploymentManager obtained from the
WebLogicDeploymentFactory supports WebLogic Server extensions. When creating deployment tools, 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 required. Connected deployment managers require 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 managers.
Table 3-4 URIs for Obtaining a WebLogic Server Deployment Manager
|Type of Deployment Manager
String value of
connected, local
connected, remote
The sample code in Example 3-1 shows how to obtain a disconnected deployment manager.
Example 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"));
SessionHelper helper class provides several convenience methods to help you easily obtain a deployment manager without manually creating and registering the deployment factories as shown in Example 3-1. The
SessionHelper code required to obtain a disconnected deployment manager consists of a single line:
DeploymentManager myDisconnectedManager = SessionHelper.getDisconnectedDeploymentManager();
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 Administration Server (
adminhost). See the Javadocs for more information about
The following sections provide information on how to create a deployable object, which is the container your deployment tool uses to deploy applications. Once you have initialized a configuration session by Obtain a Deployment Manager, create a deployable object for your deployment tool in one of the following ways:
The direct approach uses the
WebLogicDeployableObject class of the model package as shown below:
WebLogicDeployableObject myDeployableObject = WebLogicDeployableObject.createWebLogicDeployableObject("myAppFileName");
Once the deployable object is created, a configuration can be created for the applications deployment.
SessionHelper helper class provides a convenient method to obtain a deployable object. The
SessionHelper code required to obtain a deployable object is shown below:
SessionHelper.setAppK\��licationRoot(root); WebLogicDeployableObject myDeployableObject = SessionHelper.getDeployableObject();
There is no application specified in the
getDeployableObject() call.
SessionHelper uses the application in the root directory set by
setApplicationRoot(). Once the application root directory is set,
SessionHelper can be used to perform other operations, such as explicitly naming the dispatch file location or the deployment plan location.
You can also set the application file name using the
setApplication method as shown below:
This method allows you to continue using
SessionHelper independent of the directory structure. The
getDeployableObject method returns the application specified.
Front-end configuration involves creating a
WebLogicDeploymentPlan and populating it and its associated bean trees with configuration information:
Front-end configuration phase consists of two logical operations:
Loading information from a deployment plan to a deployment configuration. If a deployment configuration does not yet exist, this includes creating a
WebLogicDeploymentConfiguration object to represent the WebLogic Server configuration of an application. This is the first step in the process of process of creating a deployment plan for this object.
Restoring any existing WebLogic Server configuration values from an existing deployment plan.
A deployment tool must be able to:
Extract information 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.
A deployment plan is an XML document that contains the environmental configuration for an application and is sometimes referred to as an application's front-end configuration. A deployment plan:
Separates the environment specific details of an application from the logic of the application.
Is not required for every application. However, a deployment plan typically exists for each environment an application is deployed to.
Describes the application structure, such as what modules are in the application.
Allows developers and administrators to update the configuration of an application without modifying the application archive.
Contains environment-specific descriptor override information (tunables). By modifying a deployment plan, you can provide environment specific values for tunable variables in an application.
The server configuration for an application is encapsulated in the
javax.enterprise.deploy.spi.DeploymentConfiguration interface. A
DeploymentConfiguration provides an object representation of a deployment plan. A
DeploymentConfiguration is associated with a
DeployableObject using the
DeploymentManager.createConfiguration method. Once a
DeploymentConfiguration object is created, 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 for an application, then a
DConfigBean tree is created using available default values. Binding properties that have no defaults are left unset.
When creating a deployment tool, you must ensure that the
DConfigBean tree is fully populated before the tool distributes an application.
The following code provides an example on how to populate
Example 3-2 Example Code to Populate DConfigBeans
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 using
DeploymentConfiguration.save(). A deployment 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 using 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() provide 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.
SessionHelper.initializeConfiguration processes 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 can read in a deployment plan using the
DeploymentConfiguration.restore() method. 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
Validation of the configuration occurs mostly during the parsing of the descriptors which occurs when an application's descriptors are processed. Validation consists of ensuring the descriptors are valid XML documents and that the descriptors conform to their respective schemas.
The Customizing Deployment Configuration phase involves modifying individual WebLogic Server configuration values based on user inputs and the selected WebLogic Server targets.
In this phase, a configuration 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 a 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, meaning there are no standard descriptor elements they are directly related to. Editing a configuration is accomplished by invoking the property setters.
The Java JSR-88
DConfigBean class allows a tool to access beans using the
getDConfigBean(DDBean) method or introspection. The former approach is convenient for a tool that presents the standard descriptor based on the
DDBeans in the application's
DeployableObject and provides direct access to each
DDBean's configuration (its
DConfigBean). This provides configuration of the essential resource requirements an application may have. Introspection allows a tool to present the application's entire configuration, while highlighting the required resource requirements.
Introspection is required in both approaches in order to present or modify descriptor properties. The difference is in how a tool presents the information:
Driven by standard descriptor content or
WebLogic Server descriptor content.
A system of modifying configuration information must include a user interface to ask for configuration changes. See Example 3-3.
Example 3-3 Code Example to Modify Configuration Information
. . . // 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 enables changes to the configuration by an administrator or user can use the property setters shown in Example 3-3.
Targets are associated with WebLogic Servers, clusters, Web servers, virtual hosts and JMS servers. See
weblogic.deploy.api.spi.WebLogicTarget and Support for Querying WebLogic Target Types.
In WebLogic Server, application names are provided by a 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 Java EE 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 deployment tool prior to distribution. This representation should be consistent with the names assigned by the server when the application is finally distributed.
Your deployment tool plug-in must construct a view of an application using the
DeployableObject and
J2eeApplicationObject classes. These classes represent stand-alone modules and EARs, respectively. Each of these classes is directly related to a
DDBeanRoot object. When presented with a distribution where the name is not configured, the deployment tool must create a name for the distribution. If the distribution is a
File object, use the filename of the distribution. If an archive is offered as an input stream, a random name is used for the root module.
The deployment preparation phase involves saving the resulting plan from a configuration session. Use the
DeploymentConfiguration.save() method (a standard Java EE Deployment API method). You can also use the
SessionHelper.savePlan() method to save a new copy of deployment plan along with any external documents in the plan directory.
DeploymentConfiguration.save methods creates an XML file based on the deployment plan schema that consists of a serialization of the current collection of
DConfigBeans, along with any variable assignments and definitions.
DConfigBean trees are always saved as external descriptors. These descriptors are only be saved if they do not already exist in the application archive or the external configuration area, meaning a save operation does not overwrite existing descriptors. The
DeploymentConfiguration.saveDConfigBean method does overwrite files. This is does not mean that any changes made to a configuration are lost, it means that they are handled using variable assignments.
As noted before, the
DeploymentConfiguration.restore methods are used to create configuration beans based on a previously saved deployment plan (see Perform Front-end Configuration). You can restore an entire collection of configuration beans or you can restore a subset of the configuration beans. It is also possible to save or restore the configuration beans for a specific module in an application.
Temporary files are created during a configuration session. Archives are exploded into the temp area and can only be removed after session configuration is complete. There is no standard API defined to close out a session. Use the
close() methods to
WebLogicDeployableObject and
SessionHelper.close() to clean up after a session. If you do not clean up after closing sessions, the disk containing your temp directories may fill up over time.
This preface describes the document accessibility features and conventions used in this guide—Deploying Applications with the WebLogic Deployment API.
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at
Access to Oracle Support
Oracle customers have access to electronic support through My Oracle Support. For information, visit
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
The following text conventions are used in this document:
Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.
Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.
Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.
The following sections describe the contents and organization of this guide— Deploying Applications with the WebLogic Deployment API:
This document is a resource for:
Software developers who want to understand the WebLogic Deployment API. This API adheres to the specifications described in the Java EE Deployment API standard (JSR-88, see
http://jcp.org/en/jsr/detail?id=88) and extends the interfaces provided by that standard.
Developers and Independent Software Vendors (ISVs) who want to perform deployment operations programmatically for WebLogic Server applications.
System architects who are evaluating WebLogic Server or considering the use of the WebLogic Deployment API.
Design, development, test, and pre-production phases of a software project. It does not directly address production phase administration, monitoring, or tuning application performance with the WebLogic Deployment API. The deployment API includes utilities to make software updates during production but it mirrors the functionality of the deployment tools already available.
This guide emphasizes:
Value-added features of the WebLogic Deployment API.
How to manage application deployment using the WebLogic Deployment API.
It is assumed that the reader is familiar with Java EE concepts, the Java EE Deployment API standard (JSR-88) at
http://www.jcp.org/en/jsr/detail?id=088, the Java programming language, Enterprise Java Beans (EJBs), and Web technologies.
This chapter, Chapter 1, "Introduction and Roadmap," describes the organization and scope of this guide.
Chapter 2, "Understanding the WebLogic Deployment API," describes the packages, interfaces, and classes of the API. This section also includes information on extensions to the Java EE Deployment API standard (JSR-88, see
http://jcp.org/en/jsr/detail?id=88), utilities, helper classes, and new concepts for WebLogic Server deployment.
Chapter 3, "Configuring Applications for Deployment," describes the process of preparing an application or deployable resource for deployment to WebLogic Server.
Chapter 4, "Performing Deployment Operations," provides information on the deployment life cycle and controls for a deployed application.
For additional information about deploying applications and modules to WebLogic Server, see these documents:
Developing Applications for Oracle WebLogic Server describes how to deploy applications during development using the
wldeploy Ant task, and provides information about the WebLogic Server deployment descriptor for enterprise applications.
The WebLogic Server Java EE programming guides describe the Java EE and WebLogic Server deployment descriptors used with each Java EE application and module:
Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server
Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server
Developing JDBC Applications for Oracle WebLogic Server describes the XML deployment descriptors for JDBC application modules.
Developing JMS Applications for Oracle WebLogic Server describes the XML deployment descriptors for JMS application modules.
This document contains the following updates to describe the new deployment features introduced in this release of WebLogic Server:
Staging deployment plans—An application's deployment plan can be staged independently of the application archive, allowing you to stage a deployment plan when the application is not staged. See "Deployment Plan Staging Modes".
JMX API for Deployment Operations—The Java Management Extensions (JMX) API for deployment operations supports all of the common functionality available in the Java EE Deployment API specification (JSR-88). You can use the JMX API as an alternative to JSR-88 to perform deployment tasks on specific target servers. See "The JMX API for Deployment Operations".
For a comprehensive listing of the new WebLogic Server features introduced in this release, see What's New in Oracle WebLogic Server.


text:
Release Date: 05/04/12
When Tudor explorers returned from the New World, they brought back a name out of half-forgotten Viking legend: skraylings. Red-sailed ships followed in the explorers' wake, bringing Native American goods – and a skrayling ambassador – to London. But what do these seemingly magical beings really want in Elizabeth I's capital?
Mal Catlyn, a down-at-heel swordsman, is seconded to the ambassador's bodyguard, but assassination attempts are the least of his problems. What he learns about the skraylings and their unholy powers could cost England her new ally – and Mal Catlyn his soul.
I love a new author and one that brings mystery, intrigue as well as a fantasy flavour is usually one that I can't wait to get started on. Here, Anne brings Nordic myth alongside Elizabethan to life in this no holds barred twisted tail where the price of freedom may be a war that can ill be afforded. Its cleverly plotted, the author brings the time period to life and when you add solid prose alongside pace together it's a tale that really hits on so many levels.
Sadly, that said, I did have a few problems with it such as connecting with the lead character which I never felt that I truly did throughout the whole title which made this a bit of a struggle. That said however, I do feel that perhaps that now that the author has a firmer footing in her world, that future releases will fix this. I'll wait and see.
All in it is a book that was definitely interesting, but without a character to latch onto that helps flesh it out emotionally, then I really have problems giving it the full treatment that such careful plotting deserves.

subset: commoncrawl


text:
To achieve sustainable development in all health related sectors, we have to empower the next generation of decision-makers. Hence, we foster several initiatives in close cooperation with our partners:
Startup Track
The World Health Summit Startup Track highlights and showcases outstanding ideas and innovative business concepts that have the potential to revolutionize healthcare and improve Global Health.
It offers young entrepreneurs three days of access to world leaders in science, industry and politics.
Click here for terms of application
New Voices in Global Health
The New Voices in Global Health initiative promotes the active participation of young scientists in the World Health Summit.
Selected participants will present their work at the WHS in October in Berlin. Abstracts will be published digitally.
Click here for terms of application
Next Generation of Science Journalists Award
Launching a career as science journalist proves to be an arduous endeavor - medical science journalism is no exception.
To help recognize emerging experts, the "Next Generation of Science Journalists" Award is being granted by the World Health Summit in cooperation with Deutsches Ärzteblatt, the European Union of Science Journalists' Associations (EUSJA), the Pulitzer Center on Crisis Reporting, and the International Journalists' Programmes (IJP).
Young Physician Leaders
In the IAP for Health program Young Physician Leaders (YPL) top young professionals are being trained at the European School of Management and Technology (ESMT) in special leadership programs and will attend the World Health Summit.
The World Health Summit places five candidates in this unique network. For further information, please download this PDF or send an email to contact(at)worldhealthsummit.org.
Further information on the YPL initiativ


text:
- Destinations
- RTW Travel
- Trip Planning
- Art & Culture
- Food & Drink
- Lifestyle
- Learning
- Outdoors
- Series
Ariana Salvo Travel Articles
- Six Islands to Visit Before They Disappear
If you are an island lover, and Venice and the Maldives are not at the top of your travel list, you may want to move them up. Rising sea levels and increasingly severe and frequent storms mean many low-lying islands all over the world are slowly but surely being engulfed by the sea. Ariana Salvo shares six very different island destinations to visit before they disappear beneath the waves.
Read more
- Five Enchanting Islands of the North Atlantic
Always wanted to visit the islands of the north Atlantic, but uncertain what to expect? Join Ariana Salvo on an exploration of five Atlantic island destinations that you will find yourself returning to again and again—that's if you ever leave!
Read more
- Mediterranean Islands: 6 Destinations Not to Miss
The islands of the Mediterranean have captured human imagination since the beginning of time. The following six Mediterranean islands, often overlooked by outsiders, epitomize the distinctiveness of the region's history, culture, cuisine and natural beauty.
Read more
- 6 Things You Didn't Know About Ecotourism
You probably know that ecotourism is a great way to travel responsibly, to enjoy the planet, while simultaneously preserving it for future generations to enjoy too. Here Ariana Salvo shares six things you may not know about ecotourism…
Read more
- From Tourist to Agent of Change: What You Need to Know About Voluntourism
Is voluntourism for you? Ariana Salvo shares some insights from her recent expedition to an organic cocoa farming community in the Dominican Republic and offers a few things to consider before you get started with voluntourism.
Read more


text:
Ruptured aneurysm caused Lassiter death
Published 8:00 pm, Monday, May 28, 2007
BAD AXE The death of a 51-year-old Chandler Township woman caught many people by surprise last week and left law enforcement officials puzzled after they returned to the Limerick Road home for the second death investigation in less than six months.
Now that the autopsy results are in, Huron County Prosecuting Attorney Mark J. Gaertner said it was determined the death of Marilyn F. Lassiter, found dead in the bathroom of her Limerick Road home Thursday evening, was from natural causes.
Gaertner said Dr. Kanu Virani, forensic pathologist/Oakland County medical examiner, was called to conduct the autopsy Friday afternoon. He determined Lassiters death was a result of a ruptured aneurysm on the right side of her brain.
Virani was able to determine she (Lassiter) had a history of aneurysms and treatment for aneurysms, Gaertner said of Lassiters past medical history.
Virani indicated that the frothing at the mouth that Dr. (Richard E.) Lockard (Huron County Medical Examiner) noted at the scene was attributed to the aneurysms. And the bruising noticed on her body was not a factor in her death, but later detectives found out Mrs. Lassiter was working outside doing some heavy lawn work using a shovel that may have caused the bruising to her abdomen and breast.
A brain aneurysm is a ballooning-out of the wall of an artery in the brain. Often this wall is weakened by disease, injury or an abnormality present at birth. Aneurysms often are caused or made worse by high blood pressure. While they can lead to death, they aren't always life-threatening.
As for the time of Lassiters death, Gaertner said the autopsy determined Lassiter had been dead for a couple of days before her body was discovered by Huron County Sheriffs Deputy Warren Kuhl around 6:15 p.m. Thursday.
Lassiter's daughter contacted Huron Central Dispatch/9-1-1 just minutes after 6 p.m. Thursday asking for a police officer to check on her mother's well being. "When Deputy Kuhl, the same deputy that was first to arrive at the Lassiter home to investigate the shooting death of her husband in December, arrived at the home this time he found the house was open, windows were open and she (Marilyn Lassiter) was found inside the home, Gaertner said.
Marilyn Lassiter was scheduled to be arraigned on Tuesday in Huron County Circuit Court on felony charges of manslaughter and felony firearms in the Dec. 12 shooting death of her husband, Lionel Lassiter Jr.
Prosecutors had claimed Marilyn Lassiter pointed or aimed a .357 Smith & Wesson revolver at her husband, discharging the weapon and causing his death.
Lassiter's attorney and Lassiter had stated Lionel Lassiter pointed a shot gun at Marilyn Lassiter first, threatening to kill her.
The manslaughter charge carried a possible sentence of up to 15 years in prison. Marilyn and Lionel Lassiter were married for 27 years. The couple moved from southern Michigan to Chandler Township a year ago.
Gaertner said Tuesday he will file a dismissal of the criminal charges against Lassiter with the court.


text:
Our clients know when they come to us they'll get big results with little attitude. Direct communication between client and artist means your ideas are easily translated into
creative products.
We believe in working with you as a team to meet your goals.
Our goal is productive innovation.
Our pride is your satisfaction.


text:
The thoughts and sympathies of the Canadian Soccer League, which has a number of Brazilian-born players within its ranks, are with the Chapecoense soccer club of Brazil following the loss of most of the entire team following the crash of a charter flight on its way to the first leg of the South American Cup in Colombia Monday.
Most of the team from Chapeco, Brazil, with coaches, guests and 20 journalists, were among the 71 of the approximately 80 on board reported to have been killed. Early reports say at least three soccer players are listed as having survived.
The Chapecoense Real team was set to play the Colombian club team Atletico Nacional of Medellin on Wednesday and the flight was nearing its destination at Medellin when the crash occurred in an area called Cerro El Gordo.
Erik Barbosa, one of two part-time staff persons at the CSL office and a native of Bogota, Colombia, is a supporter of the home side Atletico Nacional in what what was considered to be a big match capturing the attention of South Americans throughout the continent. "The loss of an almost entire soccer team is a loss of huge proportions to South Americans who like their soccer players, " said Barbosa.
The crash compares to the loss of the entire Torino of Italy team that lost all 22 players near Turin in 1949 and the Alianza Lima soccer team from Peru which lost 16 players and its coach in 1987 while returning home from a league match to the Peruvian capital. Also, the Manchester United team from England that went down leaving Munich in 1958 after playing a key game in Germany. Eight Manchester United players and eight journalists were killed.
The CSL has sent a message of condolences to the Chapecoense Real club.


text:
What is The Protectors?
The Protectors (in short TPC) is a stand-alone mod of the game Warlords Battlecry 3, produced by Infinite Interactive. Stand-alone means that it can be run without having the original game installed.
Currently, TPC is under development (since 2010) and has not reached a stable version. However, there are beta versions available for download for the public at The Protectors official website.All users are encouraged to report bugs and suggest improvements on TPC forum, as they are considered beta testers. Also, by becoming a member of the site you will receive email updates on new patches and important dev-blog entries. Becoming a member of the site will also ensure your name's (or nickname's) appearance in the credits list once the mod is fully developed.
The mod has bought a lot of changes to the original game in the past few years. The most important ones which are fully implemented as of today are:
- New campaign/ New storyline. The Protectors has a new story-driven exciting campaign full of memorable scenarios, cutscenes, locations and adventures. (approximately 90 new scenarios currently)
- Modified unit/ building/ tech tree in order to make a fun and balanced game.
- New campaign mode: Chapters. Along the normal wbc3 campaign style, there are also short campaigns with preset heroes in a preset universe.These are called chapters and give flavor to TPC storyline. There are 18 chapters, one for each race + a prologue, all happening around the same Etheria, some interacting with each other, some happening in a different time-line.
- Special characters/ companions. TPC revives the old Warlords Battlecry 1 characters like Robert, Setroth, Paridian etc. and brings new ones into the game. These units are persistent in campaign mode (xp gained in battle is saved for the next one) and spawn next to your hero (in most scenarios) regardless of army setup points. They have unique powers and dialogues and their presence affect many things, including story outcome.
- Improved editor. The in game editor is now easier to use because of features like: right-clicking to decrement selection, more control over scene events, ability to add item chests, create random terrain and more.
- Improved scene events. Now have the ability to make dialogue choices, change terrain, orchestrate units and buildings, add special effects (visual and audio), control player camera, change units/buildings owners, etc.
- Racial control panels. Each race has a suiting control panel. Some from the original series, some TPC made.
- Music collection. All from Steve Fawkner and co. Total soundtrack number currently is of 67, each fitting to the fantasy-travelling-battle style of the game.
- New interface. The TPC menu gives a better first impresion due to its new button layout, intro clips and short hint movies randomly shown from time to time. The hero creation screen in particular has suffered a lot of useful changes.
- New units and buildings. All fitting original wbc graphics.
- Racial synergy bonus (in short RSB). When the hero leads his own race he has a powerful racial special spell, unique for every race. This can change the tides of a battle, but can only be used once per scenario and is not long lasting. Timing is important.
- Global extra notifications. Useful mostly in MP, players will now be announced which hero/companion dies or whom has used his RSB.
- New terrain. All fitting original wbc graphics.
- Hero creation quiz. Responding to a series of questions with multiple answers will make it easier to choose a hero race and class.
- New items/ item graphics/ item sets. All fit with original wbc graphics.
- Improved AI. Now uses buildings such as mortars.
- Ironman, Bronzeman, Tinman mode. A hero can gain and loose xp in more ways now, depending on how much a player likes to risk.
- Hero proficiency. Every TPC hero must have a proficiency. This is a skill which automatically levels up with the hero.
- Cheat codes. Only working in SP and are not permanent to the hero.
- Improved spells. Such as controlled blinking, weather affected pyromancy and more.
- Improved in-game shops, temples, quests. Stocks change, neutral powerups and more.
- Campaign dialogues/ text-based quests. These can affect and be affected by many things such as hero class, in-game time, items, companions, completed scenarios, location, storyline, quests, crowns, etc.
- Campaign time importance increased. Actions can now be time-conditioned, so that you have a limited time (in days/years) to complete a quest (traveling, fighting, obtaining an item, etc.) without affecting reward or availability.
- New victory conditions/ game types. Along Slug Fest, Capture the Flag, King of the Hill and more.
- Improved random name generator. Mostly used by the AI, gives more distinction between races.


text:
ALBUQUERQUE (KRQE) – The New Mexico Health Insurance Exchange will continue to use the federal website through next year even though a lot of people say that website is to blame for low numbers in the state.
According to Albuquerque Business First, the state board voted 11-1 to stay with the federal exchange.
Board members worried the state wasn't ready to launch its own exchange.
They feared a repeat of all the problems people ran into using the federal site.
They say the state's exchange didn't have a contract for a full call center to be up and running by November.
The New Mexico Exchange interim CEO says the delay will cost the state an extra $3.6 million.


text:
$100.00 $110.00
A $110 value you can get for $100.
Pick one of Anupy's first two cookbooks and get a basic set of Indian spices including garam masala, mustard and cumin seeds, coriander, turmeric, and red chile powders. This is why Indian As Apple Pie will have you cooking up Indian food in no time - all of our spices and recipes are right here. AND you get Anupy's amazing spice storage device that will let you pull out those spices when you need them and neatly tuck them away when you don't.
$125.00 $135.00
Kits: Custom Spices, Spice Tiffin, and Cookbook A $135 value you can get for $125.This...
$120.00 $132.00
Kits: Starter Spices, Spice Tiffin, and 2 Cookbooks A $130 value you can get for...


text:
You've Raised Early-Stage Funding! Now What?
Four ways to set yourself up for success with your new high-maintenance stakeholders
Four ways to set yourself up for success with your new high-maintenance stakeholders
Four tips for getting your house in order before adding a new resident
Use these translations to decode the 3 most common messages to understand what your investors are actually telling you.
Feeling burnt out with your current job and ready to forge your own career? Here are 4 things all entrepreneurs should consider before taking the plunge.
Three things all entrepreneurs need to know to cope with big wins and big losses in the business world
With too many tasks, too many hats, and too few hours in the day, hack your days with these four tricks to gaining more control.
From showing up 10 minutes late, to wasting 10 minutes on Facebook, these responses will help keep your team in line.
Three ways retailers are staying in the game as millennials put as much distance as they can between them and potential debt.
Learn the value of keeping a Dream List, and use these tactics to push yourself towards your dream life.
Women need to stick together and use these tools to continue to increase the number of successful women entrepreneurs.
Four tips to getting your house in order for your ideal buyer
Three key strategies to get your business the attention it deserves and close the funding deals that mean the most.
3 ways for young entrepreneurs to earn trust in the workplace and pave the way for your own success.
Lenders want plastic more than ever.
Entrepreneurs make mistakes, and that's okay. Here are the strategies you'll need to recover and move forward.
Think you'll never get to travel? Think again with the guidance you need to leave your job, travel the world and land your dream gig when you return.
Learn how to read between the lines and spot the red flags when an investor just isn't that into you.
Learn to leverage independent contractors for greater productivity and stability of your business.
You just landed a meeting with a large corporate target. Now land the account with money in the bank.
Use this Three-Tiered Approach to Securing Your Financial Future.


text: Ashe County Cheese Company & StoreOnlineWebsite - www.ashecountycheese.comSend an email - firstname.lastname@example.com E. Main St.West Jefferson, NC 28694PhonePrimary - (336) 246-2501Toll Free - (800) 445-1378Fax - (336) 246-6135 The Ashe County Cheese viewing room is open year-round at no charge. Our cheese-making schedule changes from week to week, so be sure to check our cheese-making schedule on our website or call ahead! The Ashe County Cheese Store, includes more than 20 varieties of original Ashe County Cheese as well our own county butter, homemade fudge, and the popular fresh cheese curds. We also offer other fine cheeses, locally made wines and a variety of gifts, souvenirs and old-fashioned snacks and candies. AmenitiesFree parkingHandicap accessibleMotorcoach / RV parking


text:
The Duke speaks out
It was all smiles from our previously rotund Australian as he notched another couple of goals against the Hammers to break his duck in front of the home fans. Despite an unsuccessful hunt for the hat trick the Duke was nevertheless happy with his brace:
"I was desperate to score in front of the crowd here and it was a great feeling. It's always easier when you get it out the way early. Sometimes strikers go through a patch when they don't score for a long time, so it was good to get a couple in the match. Scoring early was a good thing. It went down the left and Charles put in a beautiful cross.
The second goal was an easy chance, but the way it came to me, it came in between my legs. I just went down and it hit both legs and went in. Maybe there was a bit of luck. A hat-trick creeps into your mind, of course, and you want to get as many as you can. It looked like I could have got another one, but it wasn't to be.'


text:
Mingo County Sheriff Eugene Crum has been shot dead outside the county courthouse in Williamson, West Virginia. It's the latest in a string of incidents where criminals have targeted high-profile law-enforcement personnel.
Here's what we know so far:
1. He Was Eating Lunch
#BREAKING NEWS CONFIRMED:Mingo County Sheriff Crum was shot 4 times and has died.Deputy who was with Sheriff apprehended suspect.
— april_kaull (@april_kaull) April 3, 2013
The Charleston Daily Mail reports "a vehicle pulled up beside the sheriff, so he rolled down his window, and was then shot." The Williamson Daily News gives additional detail:
Crum was in his vehicle, witnesses say, when a male drove up to a parking lot on 3rd Avenue, exited his vehicle, walked to Crum's SUV, and shot him point blank.
2. A Suspect Has Been Shot & Caught
A suspect is in custody, according to WYNT.
WSAZ reporter Melanie Chapman tweets that the suspect was shot and is in the hospital:
#BREAKING – #WVStatePolice confirm the suspect in the #Mingo shooting WAS shot – taken to Logan Regional Medical Center. More to come. #WSAZ
— Melanie Chapman (@MChapmanWSAZ) April 3, 2013
3. It's the Latest in a String of Brazen Slayings of High-Profile Law Enforcement
This comes after recent killing of of a DA and his wife at their home in Texas, the slaying of Colorado corrections head at his home, and three months ago the killing of a DA outside another Texas courthouse. The Aryan Brother white-supremacist prison gang is suspected in the previous killings.
4. He Was Known for Cracking Down on Drugs
Crum, who was sworn in January 1, ran on a platform of cracking down on drug dealers and recently made a large OxyContin bust:
I told the residents of this county while campaigning for the office of sheriff that getting drugs off the streets was my main objective, today, I signed my first criminal complaint since taking the oath of office and it was a warrant for possession and delivery of prescription drugs.
5. This County Voted for a Felon over Obama
Mingo County is known for intense anti-Obama sentiment and voted for a felon over Barack Obama in the 2012 primary.
No Comments
Leave a Reply
Discuss on Facebook


text:
Natural Curing
Medical conventions are perfect for some individuals who are looking to cure disease, infection, or health problems. Other individuals, however, search for more Natural Curing methods when looking to combat a disease. From natural antibiotics to home curing for pink eye, there are many resources out there for those approaching health difficulties in a more Natural Curing approach. The following discusses just some of the resources available for those seeking Natural Curing methods.
Knowing how to take a more homeopathic approach to curing diseases is not new. The first medical remedies were derived from a strong natural curing background. Herbs, minerals, and vitamins were used to cure problems that plagued villages and small cities. Natural cures were made from the products and natural growth found in that particular part of the world and these natural curing remedies were promoted in an almost iconic fashion.
Today, the means may have changed but natural curing methods still exist. This can be seen in the homeopathic approaches to many common diseases. For instance, the home remedies for herpes are derived from an herbal combination that includes Vitamin C and other common minerals and vitamins. Further, home remedies for herpes include changes in diet and substance intake. Natural curing herpes involves a reduction of the amount of sugars that are ingested and limiting certain fluids that can impact sexual health.
Natural curing can be seen in more common diseases as well. Using purified water and a cold compress, home remedies for pink eye involve common household items and easily accessible ingestibles. In this way, a common disease can be combatted using natural curing methods.
The root of most natural curing methods is through the boosting of the immune system. The immune system is the part of the body that works to fight off infection and disease. From home remedies for ADD to natural cures for constipation, the main goal is to get that immune system working and allow it to function at optimum levels. Performing at optimum levels include Vitamin intake and herbal immune boosts. This allows for natural curing while improving the overall health of the body. Essentially, natural curing is not about the disease but the body as a whole.
Natural curing methods can be found in a variety of places. Mainly, however, the solutions are found online. The internet provides a vast wealth of information regarding natural curing methods. The solutions to many problems, including the home remedies for pink eye and herpes discussed previously, as well as many others.
This information can be extremely useful to those seeking unconventional remedying means. Consult a trusted healthcare advisor when making any decisions, however. Seek advice from a homeopathic expert or natural curing specialist before you make any changes. This can help to ensure that your natural curing efforts are successful and that they are undertaken with care and consideration of potential side effects. Use your resources wisely and begin your plan today.


text:
The world is facing all sorts of financial crisis and no one remains untouched. If you find yourself being tensed about your financial situation you are not alone.
But moral support in the form of this knowledge would not be enough. So what do you do to pick up things and make it alright again? With several liabilities on your head, you might be feeling the strain during months that are very taxing.
When this happens and you would want instant help, you could think of approaching Instant Payday Loans Bad Credit.
Whether you want the loan in 24 hours or in a few days, it will not matter as our team is going to work on bringing it to you really fast. We are not strict that you make use of this money for certain or intended purposes only.
You get freedom from the lenders to spend the amount on anything you please as long as you can repay on time.
Service from our side, here at Instant Payday Loans Bad Credit can be availed within 24 hours.
We guarantee that you will be approved for reasonable interest rates as long as you live in Canada, have steady income and also a bank account that is able to facilitate loan transactions.
We will accept your loan application, have it processed and then pass it only to those lenders who match your requirements. We do our very best to bring you the loan for a flexible term and also at reasonable interest rates.
The entire process for loan application through us is going to be online and that is why you are going to be able to get the loan so quickly. You need to fill out a form on our Apply Now page and have it submitted.
You can send in the loan application at any time and from where ever you can do so. We want to make every step of the way very convenient for you and so we do not torment you with paperwork or ask you to come down and meet us in person.
If you would like to interact with us and decide for yourself before applying, do Contact Us today!


text:
HS GIRLS BASKETBALL: MHS starts slow, finishes strong in blowout vs. Central
Published 5:20 pm, Friday, February 6, 2015
For the first time in several games, the Midland High girls basketball team started out sluggish. But then the Lady Bulldogs woke up in the second quarter to coast to a 70-29 District 3-6A win against San Angelo Central Friday night at Chaparral Center.
After switching to a suffocating full-court press to start the second, the Lady Bulldogs went on a whopping 28-4 run. Once trailing, 12-6, MHS (26-5, 8-1 in District 3-6A) went on to dominate the Lady Bobcats (7-22, 2-7).
Still, MHS head coach Wes Torres knows his team didn't play close to a perfect game. He know his girls need to be at the top of their game as the regular season comes to a close.
"There are some things we've got to get better at to excel in the playoffs and to compete against the caliber teams we'll see in the playoffs,"Torres said. "We've got to be able to change it up and do some different things and that's what we've been working on."
Aubrie Elliott scored a game-high 20 points for MHS, while Alexandrea Washington added 13 points. Kaylyn Evans also chipped in 11 points for the Lady Bulldogs.
Latavia Dosson led Central with seven points.
Central (7-22, 2-7 in District 3-6A) - Bri Contreras 6, Klaire Markell 2, Alexis Jackson 2, Ruby Shell 3, Kandice McCarty 4, Latavia Dosson 7, Cadye Nelms 5
MHS (26-5, 8-1 in District 3-6A) - Arcie Guardiola 4, Miranda Mast 6, Aubrie Elliott 20, Alexis Washington 7, Alexandrea Washington 13, Teandra Eldridge 4, Rylee Rushton 1, Claire Lancaster 2, Kaylyn Evans 11, Valvareesha Hall 2
Central 12 4 9 5 --29
Free throws - Central 6-10, MHS 10-17. 3-point goals - Central 0, MHS 1 (Alexandrea Washington). Total fouls - Central 11, MHS 8. Fouled out - none.
Next game: MHS vs. Lee at Chaparral Center, 6 p.m. Tuesday