views:

1444

answers:

3

My shop has been running Oracle's Application Server for several years. As such, before we knew better, we have developed a norm of having application config files stored outside of the WAR file and the app-specific config directory is added to each application using an Oracle-specific deployment descriptor. This deployment descriptor allows us to add classpath elements at the application layer rather than having to include all dependencies in the WAR.

Now we are faced with upgrading to WebLogic 10.3 and I need to find an alternative for our applications that depend on external configs.

Is there a way in WebLogic to add external jars or directories to the classloader at the application level? I've found ways to add them to the system classloader, but I'd prefer to add them to the application level to avoid having to re-work the applications beyond modifying deployment descriptors.

Is such a thing possible in WebLogic 10?

A: 

To my knowledge, this is not possible with Weblogic. External configuration files need indeed to be added to the system classpath. You can tweak a bit the classloader (see filtering and loading order) but there is nothing allowing to add dependencies at the "application level" a la OAS. For this, you'll have to run separated domains if the scenario mentioned above is not an option.

Pascal Thivent
A: 

External jars can be referenced by deployments using the shared libraries.

Roughly, the external jars should be 'deployed' as libraries. Then they can be referenced from your app's weblogic-application.xml using library-ref descriptors.

refer to this doc.

Though, I dont think you can provide external directories/config files other than by using system classpath.

Shreeni
A: 

After further research, we've learned about WebLogic's Generic File Loading Overrides feature.

This feature allows us to use a Deployment Plan for our application and specify a "config-root" for the application. Within the config-root, we can create a directory called "AppFileOverrides" and override any file in the WEB-INF/classes or WEB-INF/lib directories.

This feature works by injecting a classloader just in front of the Web Application classloader, thus any resource loaded from the classpath will be found in this classloader before anything bundled into the web application archive.

Using this feature, we are able to add configuration files (and in theory, classes) that don't exist in the war file at all. Thus, we are able to mimic the functionality of keeping configuration files outside the war.

Moving forward, I'm encouraging our developers to include the configurations inside the war file, but this will work nicely for legacy apps and for situations where we need to change the configuration for a given deployment target (dev vs production)

Randy