Use of deployment classpath or shared-libraries to pick-up "custom" classes

Question

Hi,
I’m trying to determine an approach to dealing with how classes are found in a deployed ADF application via classpath, etc. I’ve tried to explain the situation below as best I can so it’s clear. If you have any comments/suggestions as to how this could be done, it would be much appreciated
Current Application structure:
Consists of an application initially deployed to OC4J 10.1.3.4 using an alesco-wss.ear file
Application contains a single Web Module, initially deployed as wss.war file within the alesco-wss.ear file above.
The Web Module (wss) was built in JDeveloper 10.1.3.4 using 2 projects, a Model and ViewController project, and uses ADFBC.
The Model project seems to also generate an alesco-model.jar file in the /WEB-INF/lib/ folder, even though Model classes are in the /WEB-INF/classes/ folder below?
Exploded structure of application on application server looks something like:
applications/alesco-wss/META-INF/
/application.xml <- specifies settings for the Application such as Web Module settings
/wss/
/app/ <- directory containing application .jspx pages protected by security
/images/ <- directory containing application images
/infrastructure/ <- directory containing .jspx files for login, logout and error reduced security
/skins/ <- directory containing Skin image, CSS and other files
/WEB-INF/
/classes/ <- directory containing application runtime class files as per package sub-directories
/lib/ <- JAR files used by application (could move some to shared-libaries?) – seems to contain alesco-model.jar
/regions/ <- directory containing .jspx pages used for Regions within JSPX template page
/templates/ <- directory containing template .jspx pages used for development (not really required for deployment)
/adf-faces-config.xml
/adf-faces-skins.xml
/faces-config.xml
/faces-config-backing.xml
/faces-config-nav.xml
/region-metadata.xml
/web.xml
testpage.jspx <- Publicly accessible page just to test
The application runs successfully using the above deployment structure.
We plan to use the exploded deployment structure so that updates to pages, etc. can be applied individually rather than requiring construction and re-deployment of complete .EAR or .JAR files.
What I’m trying to determine/establish is whether there is a mechanism to cater for a customisation of a class, where such a class would be used instead of the original class, perhaps using a classpath mechanism or shared library?
For example, say there is a class “talent2.alesco.model.libraries.ModelUtil.class”, this would in the above structure be found under:
applications/alesco-wss/META-INF/classes/talent2/alesco/model/libraries/ModelUtil.class
Classes using the above class would import “talent2.alesco.model.libraries.ModelUtil”, so they effectively use that full-reference to the class (talent2.alesco.model.libraries as a path, either expanded or within a JAR).
From the Oracle Containers for J2EE Developer’s Guide 10.1.3 page 3-17, it lists the following:
Table 3–1 Configuration Options Affecting Class Visibility
Classloader Configuration Option
Configured shared library <code-source> in server.xml
<import-shared-library> in server.xml
app-name.root <import-shared-library> in orion-application.xml
<library> jars/directories in orion-application.xml
<ejb> JARs in orion-application.xml
RAR file: all JARs at the root.
RAR file: <native-library> directory paths.
Manifest Class-Path of above JARs
app-name.web.web-mod-name WAR file: Manifest Class-Path
WAR file: WEB-INF/classes
WAR file: WEB-INF/lib/ all JARs
<classpath> jars/directories in orion-web.xml
Manifest Class-Path of above jars.
search-local-classes-first attribute in orion-web.xml
Shared libraries are inherited from the app root.
We have reasons why we prefer not to use .JAR files for these “non-standard” or “replaced” classes, so prefer an option that doesn’t involve creating a .JAR file.
Our ideal solution would be to have such classes placed in an alternate directory that is referred to in a classpath such that IF a class exists in that location, it will be used instead of the one in the WEB-INF/classes/ directories, and if not such class is found it would then locate it in the WEB-INF/classes/ directories.
- Can a classpath be set to look for such classes in a directory?
- Do the classes have to replicate the original package directory structure within that directory (<dir>/talent2/alesco/model/libraries)?
- If the class were put in such a directory, without replicating the original package directory structure, I assume the referencing “import” statements would not locate it correctly.
- Is the classpath mechanism “clever” enough to search the package directory structure to locate the class (i.e. just points to <dir>)?
- Or would the classpath mechanism require each individual path replicating the package structure to be added (i.e. <dir>/talent2/alesco/model/libraries/ and any other such package path)?
If we are “forced” to resort to the use of JAR files, does a JAR file used for the purpose of overwrite/extending a sub-set of classes in the original location need to contain ALL related package classes? Or does it effectively “superset” classes it finds in all JAR files, etc. in the whole classpath? That is, it finds talent2.alesco.model.libraries.ModelUtil in the custom.jar file and happily goes on to get the remainder of talent2.alesco.model.libraries classes in the other core JAR/location. Or does it need all of them to be in the first JAR file for that package?
Any help would be appreciated to understand how these various class visibility mechanisms could be used to achieve what is required would be appreciated.
Gene

Answer 1

So, nobody's had any experience with deploying an ADF application, and providing a means for a client to place custom classes in such a way as they're used in preference to the standard application class, effectively to implement a customised class without overwriting the original "standard" class?
Gene