JDeveloper 10.1.3 Deployment to OAS 10.1.2

Well, my last post (xmlns:xsi Strikes Again) is a good example of what happens when you don't follow the documentation.

Once again, when deploying a project developed with JDeveloper 10.1.3 to Oracle Application Server 10.1.2, you must create the following J2EE 1.3-compliant configuration files:

1. application.xml
2. web.xml
3. orion-application.xml
4. data-sources.xml
5. oc4J-connectors.xml

Full instructions for deploying from JDeveloper 10.1.3 to OAS 10.1.2 are located in section 22.11 of the Oracle Application Development Framework Developer's Guide and section 34.6.2 of the Oracle Application Development Framework Developer's Guide for Forms/4GL Developers.

Note: Inspect these files after creating them - you may still find the OAS 10.1.2-offending xmlns:xsi attribute in some of them.

xmlns:xsi Strikes Again

I thought I would work through a simple JSF tutorial - very easy, no data sources, just three JSPs. But when I try to deploy it to my OAS 10g 10.1.2.0.2 dev server, I get the dreaded

Deployment failed: Nested exception
Resolution:

Base Exception:
java.rmi.RemoteException
deploy failed!: ; nested exception is:
oracle.oc4j.admin.internal.DeployerException: Unknown assembly root-tag attribute: xmlns:xsi. deploy failed!: ; nested exception is:
oracle.oc4j.admin.internal.DeployerException: Unknown assembly root-tag attribute: xmlns:xsi

This is a compatibility problem between JDeveloper 10.1.3 and OAS 10.1.2 that I've run into before. So I searched my JDeveloper project folders for xmlns:xsi, found two files, removed the offending tag and I still get the error.

WTF?

This is why there's an I Hate Oracle club. . .

Screw it. It's Friday afternoon; I have a sailboat race tomorrow, and, unlike Larry Ellison, I'll probably win.

#%@$&! data-sources.xml!

After chugging along happily with my project and figuring out how to connect to an Oracle database using the jdbc thin driver from a servlet I ran into yet another JDev 10.1.3 - OAS 10.1.2 gotcha - the data-sources.xml file.

This file contains the jndi database connection info used by an OC4J to connect an application to a backend database. Although the ADF Developer's Guide for Forms/4GL Developers contains instructions for creating OAS 10.1.2 compliant deployment descriptor files, it doesn't mention that when JDev 10.1.3 actually loads data into these files it won't be OAS 10.1.2 compliant.

My project ran great with JDev's 10.1.3 embedded OC4J, but when I tried to deploy it to my OAS 10.1.2 OC4J, I got errors complaining of unrecognized tags in the data-sources.xml file. I searched the J2EE directory in OAS 10.1.2, found a sample data-sources.xml file, and copied what I hoped was the correct information from my JDev 10.1.3-created data-sources.xml file. Long story short: it worked. But what a PITA.

Unknown assembly root-tag attribute: xmlns:xsi. deploy failed!

Well, I got an .EAR file created with JDev 10.1.3 to deploy on my 10.1.2 OAS yesterday, but today with a new project I get the above error.

This is an issue with the configuration files being J2EE 1.5-compliant when they need to be J2EE 1.4-compliant.

I have tried searching the directory for the xmlns.xsi attribute, and found a few files with it. Then I reliazed I hadn't changed the J2EE library for the deployment project. I changed it, regenerated the .EAR file, but I'm still getting the error. I also followed the instructions in table 34-3 of the ADF Developers Guide for Forms/4GL Developers, but still getting the error. Tried deleting the OC4J container on the OAS 10.1.2 server in case it was trying to deploy the old .EAR from a temp file, but that didn't work either.

I also created a new deployement profile with a different name, generated an .EAR file with that name, and am still getting the error. A search of the directory for the xmlns.xsi. tag shows it doesn't exist! Why then is OAS complaining? Where is it finding this tag? What the heck is going on?

I'm sure I've missed one simple step, and when I find it I'll post the whole process here step-by-step so I don't have to keep figuring it out each time I want to deploy from JDev 10.1.3 to OAS 10.1.2.

This is why there are dents in the walls surrounding my cubicle - dents shaped like my forehead.

Update: Okay, got it to work. I kept it as simple as possible, creating J2EE 1.4-compliant configuration files for the project, turning off the automatic data-sources.xml creation option in JDev's preferences, and created an .EAR file from the project itself instead of creating a seperate project just for deployment.

So, as promised, here's the steps I'm using to develop and deploy a project from JDev 10.1.3 to OAS 10.1.2:

1. Turned off default data-sources.xml generation in JDev's Tools -> Preferences dialog.
2. After creating the application and adding a project, changing the project properties libraries options to use J2EE 1.4 (more on how to do this on ADF Developers' Guide section 22-11).
3. Created the following J2EE 1.4-compliant configuration files in the project properties dialog (more info in the ADF Developers' Guide for Forms/4GL Developers table 34-3):
1. application.xml
2. web.xml
3. orion-application.xml

I didn't create data-sources.xml or oc4J-connections.xml configuration files because my apps are very simple - a http servlet and html page. I will probably have to add them when I move on to my JSP which will have to query a 10g database.

Time for lunch - woohoo!

JDeveloper and Libraries - an Import Lesson

Although I've run through several of the Oracle JDeveloper 10.1.3 tutorials, none of them dealt with adding libraries to a project. Today, I copy and pasted some sample code that imports from the javax.servlet.http package. JDev complained it couldn't find it. So I guessed I needed to add a library to the project. I fumbled my way around for a while and finally added the J2EE library. This seemed to work - JDev is no longer complaining and the code compiles. I'm sure there's a way to configure JDev to add libraries by default, but I haven't figured it out.

Progress - Sort Of

Found some more information on configuring JDeveloper 10.1.3 to build applications that can run on OAS 10.1.2. I had to install the JDev 10.1.3 ADF runtime library on the OAS (instructions in Section 22-12 of the Oracle® Application Development Framework Developer's Guide (10.1.3). Then I found additional steps for creating deployment files in section 34.6.2 of the Oracle® Application Development Framework Developer's Guide For Forms/4GL Developers Guide. I was still unable to deploy from JDev, so I copied the .EAR file to the OAS, and tried deploying with Enterprise Manager. Success! But now I'm getting a "500 Internal Server Error". I believe this is yet another J2EE/JDK version issue. (JDev uses J2EE 5 and JDK 1.5, OAS 10.1.2. uses an older version). At least the application is deployed and shows a loaded status and I'm not getting 404 Page Not Found errors when I try to run it from the browser.

The 500 Internal Server Error's stack dump shows it's related to ADF - maybe I can make a simple JSP without ADF and get it to run. I only need JDev so I can build a very simple page anyways.

Update: Success! I copied a one-line example of a JSP into a new JDev web applications project, followed the steps to package it for OAS 10.1.2, deployed it from JDev, and IT WORKED.

It's Friday afternoon - I'm going sailing and them I'm going to drink some beer, and then I'm going to repeat that process Saturday and Sunday. Nice weekend all!

JDeveloper 10.1.3 and OAS 10.1.2.0.2: I Give In

Still can't get the sample application built on Jdev 10.1.3 to deploy to my OAS 10g 10.1.2.0.2 app server. Spent lots of time browsing the OTN forums and Metalink and it mostly boils down to JDev 10.1.3 and OAS 10.1.2.0.2 using different JDKs. One fix (an unrecognized xml tag) got me past the first error, but new errors cropped up and now I'm throwing in the towel and downloading JDev 10.1.2.

I waste more time trying to configure Oracle than I actually do getting to develop on it.

PITA.

Update: I spoke too soon. After installing JDev 10.1.2 I discovered the tutorials I need to learn from are no longer available. So it's back to 10.1.3. Tomorrow I'll post a plea for help on the OTN JDeveloper forum. There's got to be a set of steps to get applications built on JDev 10.1.3 to work on OAS 10.1.2.

Fun With JDeveloper 10.1.3

While searching for the cause of my application's deployement problem, I discovered a post on the OTN forums where it was noted that applications developed with JDeveloper 10.1.3 that are deployed on OAS 10g 10.1.2 must be compiled using the Sun JDK 1.4, not the Sun JDK 1.5. The post, written by one of Oracle's JDeveloper evangelists, helpfully gave the reference for the howto. It is located in Section 22-11 of the Oracle ADF Developers Guide, 101.3

I don't know if this is the cause of my problem, and it isn't Oracle's fault that apps developed with Sun's JDK 1.5 won't necessarily run with JDK 1.4, and I'm sure it made sense to upgrade JDev to JDK 1.5, but it would be nice if somewhere on the download page for JDev 10.1.3 there was a big notice alerting folks of OAS 10.1.2 of this issue.

Step 1: Learning How To Deploy an EAR File to OAS 10g

This morning I worked through the JDeveloper tutorial "Deploying A Web Application" to learn how to package and deploy an EAR file to an OAS 10g Application Server. The tutorial uses a stand-alone OC4J instance instead, but I figured deploying to a real, live OAS 10g R2 10.1.2.0.2 server couldn't be much different.

I followed the tutorial and everything worked as advertised. Then I created an OC4J instance on my 10.1.2.0.2 middle-tier. I created an application server connection for the OC4J instance, tested the connection successfuly, and attempted to deploy the EAR file created during the tutorial.

This is what I get in the JDeveloper deployment log:

---- Deployment started. ---- Apr 25, 2007 1:15:29 PM
Target platform is Oracle Application Server 10g 10.1.2 (Windows) (hw-05-0193_test).
Wrote WAR file to C:\oracle\jdeveloper\jdev\mywork\OrderEntry\ViewController\deploy\WebArchive.war
Running dependency analysis...
Wrote JAR file to C:\oracle\jdeveloper\jdev\mywork\OrderEntry\Model\deploy\ModelArchive.jar
Wrote EAR file to C:\oracle\jdeveloper\jdev\mywork\OrderEntry\Deployment\deploy\OrderEntryApplication.ear
Invoking DCM servlet client...
C:\oracle\jdevstudio_10.1.3.2\jdk\jre\bin\javaw.exe -Djava.protocol.handler.pkgs=HTTPClient -jar C:\oracle\jdevstudio_10.1.3.2\jdev\lib\oc4j_remote_deploy.jar http://hw-05-0193.emts.tybrin.com:18101/Oc4jDcmServletAPI/ ias_admin **** redeploy c:\oracle\mid1012 C:\oracle\jdeveloper\jdev\mywork\OrderEntry\Deployment\deploy\OrderEntryApplication.ear OrderEntryApplication test
Initializing log
Servlet interface for OC4J DCM commands
Command timeout defined at 600 seconds
Executing DCM command...
Executing command redeploy c:\oracle\mid1012 C:\oracle\jdeveloper\jdev\mywork\OrderEntry\Deployment\deploy\OrderEntryApplication.ear OrderEntryApplication test
Command = REDEPLOY
Reading application's ear file
Ear file was successfully read
Opening connection to Oc4jDcmServlet
Setting userName to ias_admin
Sending command to DCM servlet
HTTP response code = 200, HTTP response msg = OK
Command was successfully sent to Oc4jDcmServlet
Receiving session id from servlet to check command status
Session id = 0a0b0d0346b5c27f8ee09107497488b1f5557e188584
Please, wait for command to finish...
Checking command status...
Setting userName to ias_admin
Setting Cookie to JSESSIONID=0a0b0d0346b5c27f8ee09107497488b1f5557e188584
Checking command status
HTTP response code = 200, HTTP response msg = OK
Command has not finished yet
Checking command status...
Setting userName to ias_admin
Setting Cookie to JSESSIONID=0a0b0d0346b5c27f8ee09107497488b1f5557e188584
Checking command status
HTTP response code = 200, HTTP response msg = OK
Command has finished
Receiving command exit value
Receiving command output
**** No output was received from command
Closing connection to Oc4jDcmServlet
#### DCM command did not complete successfully (-8)
#### HTTP return code was -8
Exit status of DCM servlet client: -8
Elapsed time for deployment: 29 seconds
#### Deployment incomplete. #### Apr 25, 2007 1:15:58 PM

And this is the error OAS 10g EM reported when I copied the EAR file to the OC4J applications directory and attempted to use the OC4J's applications page to deploy the file:

Deployment failed: Nested exception
Resolution:

Base Exception:
java.rmi.RemoteException
deploy failed!: ; nested exception is:
oracle.oc4j.admin.internal.DeployerException: Unknown assembly root-tag attribute: xmlns:xsi. deploy failed!: ; nested exception is:
oracle.oc4j.admin.internal.DeployerException: Unknown assembly root-tag attribute: xmlns:xsi


As usual with Oracle, nothing is ever easy. Time to give the documenation a read.

Update: Googled the OTN Forums and found a post relating to the same error. Several posts down was a suggestion to read Chapter 22 of the ADF Developer's Guide - this discusses deploying applications developed with JDev 10.1.3 on OAS 10.1.2 platforms. Apparently they use different versions of the JDK. I browsed the guide for a moment, and then decided to see if there was something platform-specific in the deployment process. I followed the tutorial to create a new deployment profile, but found nothing platform-specific. But I went ahead and tried to deploy it to the 10.1.2 application server and - it worked! Maybe the deployment process writes a makefile or something platform- and version-specific. . .

Now I have to figure out the username and password the application is prompting me for. The one used for the OC4J standalone doesn't work and neither does the ias_admin password for the 10.1.2 OAS.

Another update: The username/password was a non-issue. Having two web servers on the same box is always confusing (my OHS uses port 7778. . .)

But now the control page for the OC4J says that although the application is present, it's status is "not loaded". I bet Google loves me (and every other self-taught Oracle wannabe).

One more update: I checked the deployment properties in JDeveloper and I forgot to select some options. Undeployed from app server, redeployed from JDev and got the original error again. Just another false trail.

Next: Build a JSP That Reads and Stores X.509 Certs

Now that my OAS 10g R2 10.1.2.0.2 App server is configured for client-side authentication, I am moving on to the next problem, which is figuring out how to register first-time users.

The Oracle Single Sign-On server requires a copy of the client certificate be stored in Oracle Internet Directory. That means each user must have an entry in OID to store the certificate in.

This is sequence of steps required to register a first-time user of our reduced sign-on enabled Forms application:

1. User opens JSP
2. JSP pulls user's X.509 certificate from the user's browser
3. JSP reads user's DN from certificate
4. JSP searches for user's DN in OID
5. If DN is found, cert is passed to SSO for authentication
6. If DN is NOT found, user is redirected to a registration page
7. User is prompted for their username (this step requires a personnel record containing the username be created for the user by an administrator in the backend database prior to registration)
8. Personnel records searched for username
9. If username not found, prompt user to re-enter username or contact administrator
   
10. If username found, create an entry in OID for user containing the following
1. DN
2. X.509 Cert
3. Resource Access Descriptor (database connect string for backend database)
11. User logged into account

I'm guessing the main page will be a JSP, the username prompt page either a JSP or a simple HTML form, and there will be a servlet that handles the OID and backend database queries and user entry creation on OID. At least that's the plan. . .

For experienced programmers, I'm sure this would be a trivial task. But because I've spent 98% of my time configuring and installing database and application servers, this is non-trivial for me. I have downloaded the latest version of JDeveloper, and am refreshing my scant knowledge by re-doing several of the beginning tutorials. Don't know how long this will take, but it at least its something new to work on.