OC4J has its own class loading rules, and those rules matter when a generated application brings its own libraries. This note records the configuration that worked for a generated Web Services project.
Class loading
Prefer the parent first policy for shared libraries such as the servlet API and the XML parser, and the application first policy for the libraries that ship with the generated project. Mixing the two for the same package produces a linkage error that is hard to read.
- Keep one XML parser implementation on the class path.
- Remove duplicate copies of the logging bridge from the shared library.
- Let the container supply the transaction manager.
- Package the application libraries in one place, not in two.
Shared library setup
Create a shared library for the common libraries and reference it from the application. The library should hold the versions that the container expects, while the archive holds the versions that the application needs. Record both versions in the deployment notes so that the next upgrade starts from a known state.
Deployment settings
| Setting | Value used in the working configuration |
|---|---|
| Class loading | Parent first for shared libraries, application first for project libraries |
| Transaction | Container managed |
| Logging | One bridge, routed to the container log |
| Parser | Single implementation supplied by the container |
After deployment, call one service operation and read the response. A successful call confirms the class path, the transaction manager and the parser in one step.