or How to deploy into an application-specific OCJ4-container on Oracle AS 10.1.3 without JBOExecption during deployment when your application uses ADF Lately our developers were working on an application which uses ADF and requested an Oracle AS 10.1.3 J2EE implementation as webserver for the deployment of this Java application.
The webserver was quickly and effortlessly installed and the ear-file was soon ready to install. A deadline was lurking for the acceptance testing by the client and up to now everthing went smoothly until …the deployment.
During development everthing was run against an OC4J-standalone implementation where the ADFinstaller was run via JDeveloper 10.1.3. Now the deployment failed constantly with a nagging and unexplainable JBOException at the end. Even after having run the ADFinstaller!
What went wrong?
We had created a second OC4J-container for the application so we don’t install into the home-container. Nowhere, nor in the install guide of the ADFruntime installer, nor in the install guide of the AS is mentioned that the ADFruntime-installer is just for the container it was originally installed in, namely “home”.
All the other OC4J-containers which can be added are (initially) not able to use the ADFruntime-jars because the new container does not know they exist. Searching Metalink for “JBOException” does not result in any articles which mention problems of AS 10.1.3 with ADF, especially not in combination with non-home installed applications. By pure chance I snuffed though the Knowledge Base Article Overview for Application Servers and stumbled across DOC_ID 371937.1 “How to Configure a 2:nd OC4J Instance for ADF use Within Oracle Application Server 10.1.3”.
Basically, what you have to do is repeat all entries which the ADF-installer inserts into the server.xml and application.xml files of the home-container in the acording xml-files for each OC4J-container under the application server which are destined to run ADF-based applications. Just cut them out of the article and plug them into the server and application.xml onder {OH}/j2ee/(but check your paths first if your AS install is not default). Then, restart your midtier instance.
Having done that,the ADF-containing ear-file deploys without the JBOException.
When you think about this, you know you should have expected this behaviour. A seperate container means a seperate virtual machine. Therefore a different classpath exists. ADF is “just” another library, so it should be container specific instead of globally availlable.
B.T.W. did you have fun deploying the .ear file? Also deploying on a cluster without multicast is loads of fun 😉