deploying the same ear in the same weblogic 10 domain

I want to deploy the same EAR to the same WebLogic domain after renaming th=
e EAR each time.
The functionality of the EAR is the same but the EAR should read a differen=
t external configuration file. The EAR will send a message to different con=
sumers.

EarA.ear should read /home/EarA/config.properties
EarB.ear should read /home/EarB/config.properties

By putting the property file outside EAR enables me to hand over the respon=
sibility of the property file to the deployers. If I put the property file =
in the EAR, then they will not accept it.

How can I achieve this?

thanx,

Levent

In 10.3, there is the concept of an app file override.

This allows you to have files that will override those contained in an
archive. The WLS infrastructure will push these files out to the
targeted servers and will ensure that the classloaders find these files
before those in the archive and allow getResourceAsStream to load these
files.

----

Generic File Loading Overrides

This feature allows you to place application-specific files to be
overridden into a new optional subdirectory (named /AppFileOverrides) in
the existing plan directory structure. The presence or absence of this
new optional subdirectory controls whether file overrides are enabled
for the deployment. If this subdirectory is present, an internal
ClassFinder is added to the front of the application and module
ClassLoaders for the deployment. As a result, the file override
hierarchy rules follow the existing ClassLoader and resource loading
rules and behaviors for applications. For more information on WLS
application classloading, see WebLogic Server Application Classloading
in Developing Applications with WebLogic Server.
Note: This mechanism is only for overriding resources and does not
override classes.

These are application-specific files and the contents are opaque to WLS,
so the entire file contents will be overridden when an override file is
supplied.

How It Works

The files placed in the /AppFileOverrides subdirectory are staged and
distributed along with the rest of the plan directory contents and are
available on all of the targets. Applications are then able to load
these files as resources using the current ClassLoader (for example,
using the ClassLoader.getResourceAsStream method.) This either finds the
overridden files or the files packaged in the application, depending on
the configuration and whether overridden files are supplied.

For web applications, application file overrides only apply to the
classpath related resources (which are in WEB-INF/classes and
WEB-INF/lib), and do not apply to the resource path for the web
application. Therefore, overrides are seen by web applications using the
classloader.getResourceAsStream() method to lookup resources, but
overrides do not affect web application calls to the
ServletContext.getResourceAsStream() method.

In order to use this feature, you must:

* Specify a plan for the deployment (see Creating a New Deployment
Plan to Configure an Application).
* Specify the config-root within in the plan.
* Provide a config-root/AppFileOverrides subdirectory.

Directory Structure

The contents of the /AppFileOverrides subdirectory use the existing plan
directory structure and directory naming conventions that already exist
for descriptor overrides. For more information on directory naming
conventions, see Packaging Files for Deployment.

Enabling application file overrides causes a directory ClassFinder to be
added to the application and module level ClassLoaders, which point to
the appropriate root directories within the /AppFileOverrides
subdirectory (which is in the plan directory). The ClassFinder inserted
into the front of the application’s ClassLoader is given a structure of
AppDeploymentMBean.getLocalPlanDir + separator + "/AppFileOverrides".
The ClassFinder inserted into the front of the module’s ClassLoaders is
given a structure of AppDeploymentMBean.getLocalPlanDir + separator +
"/AppFileOverrides" + separator + moduleURI.


Levent Tutar wrote:
> I want to deploy the same EAR to the same WebLogic domain after renaming the EAR each time.
> The functionality of the EAR is the same but the EAR should read a different external configuration file. The EAR will send a message to different consumers.
>
> EarA.ear should read /home/EarA/config.properties
> EarB.ear should read /home/EarB/config.properties
>
> By putting the property file outside EAR enables me to hand over the responsibility of the property file to the deployers. If I put the property file in the EAR, then they will not accept it.
>
> How can I achieve this?
>
> thanx,
>
> Levent