You would assume two complementing products of the same supplier, released during the same period, to be installation compatible.
However, when installing the Oracle Application Server (I tried it in version 4.0.8.1) next to Oracle8i (v8.1.5), a number of problems can occur.
The following tips are fairly obvious:
- Both installations need a different value for the ORACLE_HOME setting.
This setting points to the root installation of your Oracle product, and is used by a lot of Oracle related tools.
This includes the tools the OAS and Oracle8i use themselves.
Make sure you set the DEFAULT_HOME to the product whose tools you'll need.
That would probably be the OAS.
- Oracle8i as well as the OAS install a Java Virtual Machine, and Oracle specific class libraries.
This can be a source of problems, especially in the OAS.
Make sure the OAS finds its version of the Oracle class libraries and JRE before any possiby conflicting libraries.
Be especially wary of CORBA class libraries, as most contain different versions of the classes in the 'org.omg' package.
Because of possible Java conflicts, Oracle actually advises against installing the OAS and Oracle8i on the same machine.
The next one is less obvious:
-
If you set the OAS ORACLE_HOME to be the DEFAULT_HOME, you have to manually start the database listener when your system boots (thereby starting the OAS node listener first).
Not doing so can cause an unstable OAS.
To be blunt: it seems a lot of things can cause the OAS to become unstable.
Expect to spend a couple of days of your project on repairing your development server.
- Step 1: stop and start the OAS.
- Step 2: reboot.
- Step 3: remove all applications in the OAS, restart it, and install them all over again.
- Step 4: Lucky you, you get to deinstall and install the OAS again.
A couple of other nice Java and OAS "need-to-knows":
-
When developing servlets in the OAS it is good to know that a bug in its servlet engine causes it to ignore the last parameter on an URL, when the URL is encoded using the HttpServletResponse.encodeURL() method.
This method must ensure the session info is passed along with the URL if the user doesn't use HTTP cookies.
When receiving the request in a servlet, not even the parametername can be found.
A workaround to this problem is to always end your requests with a dummy parameter, like this: "http://www.drbob42.com/servlet/OASServlet?name=hubert?dummy=bar".
Without the addition of "dummy", the "name" parameter would not get through.
-
Deploying an EJB to the OAS works like a charm, especially using the wizard in JDeveloper 3.
Deploying a new version of the same EJB can be less straightforward.
Using standard settings, you'll get a FileIOException during downloading of the client stubs of your EJB.
The reason for this is that the OAS nodemanager holds a file of your old EJB in use ("_client.jar"), preventing oasdeploy from overwriting it.
You can workaround this by writing a batch script that stops the OAS and the nodemanager (remember, it is the nodemanager that holds the file, stopping the OAS or disabling filecaching won't help!), deploys the EJB, and starts the nodemanager and the OAS up again.
Conclusion: I liked the deployment wizard of JDeveloper, but for it to be useful just once was a bit disappointing.
I now deploy using a batch script in the 'Tools' menu, which needs to stop all OAS processes, copy and jar all needed classfiles, deploy the EJB, and start everything up again with commandline tools, .
-
We are experiencing a nasty Classloader bug in the OAS that causes some classes to fail to load when using Class.forName() in a servlet.
A loop trying to load those classes 50 times (!) with growing pauses now "fixes" this most of the times, but not always...
