doing battle with WSRP

Victory! I got a portletized ADF app to deploy to JDeveloper 10.1.3.4's preconfigured oc4j. Here is how I did it and some pitfalls you can avoid: technet's jdev forum thread

I need to add more to this post to document what I did and did not try (for many reasons). I did a basic ADFBC/JSF master-detail app. I just dragged a child collection from the Data Control pallet into a Panel page and dropped it as master detail. I also put a menu tab on top that went no-where. (If this seems a familiar demo, it is the same one used by Shay Shmeltzer in a recent blog about Trinidad.)

So, I used the WebCenter Developer Guide 10.1.3.2 to instruct me on portletizing my simple app. No problem there, I don't think.

Then I made a deployment profile (WAR) for the ViewController project. Then I deployed to an ear from that profile. That's where it starts to get interesting. During this deployment process, a dialog window comes up asking if your target Portal Container is 10.1.3.2 or above. Now maybe this number is a WebCenter version of some sort...not sure. Our Portal version is 10.1.4. It is on a 10.1.2.0.2 OAS installation. So I tried answering both yes and no alternately to this question. Both created an ear, but the deployment results are what varied.

No seemed to create a JSR 168 producer, but I am not sure how to tell Oracle Portal to find this consumer. It seemed all the documentation I found has WSRP associated with JSR 168.

When I tried to deploy the ear to various OC4J's the results were varied:

1. The "No" version of the ear file deployed everywhere, but I did not know how to consume it.
2. The "Yes" version failed to deploy on the Oracle Portal OC4J, 10.1.2.0.2/Portal 10.1.4, because the process of creating the "yes" ear file installed an orion-application.xml file, which had an element that the OAS 10.1.2.0.2 deployment process could not handle...something like or something like that. I had trouble finding documentation on this element, but I am guessing that J2EE 1.3 had no such element in its DTD for orion-application. I did try creating my own version of orion-application.xml with a version 2 orion-application.xml, instead of version 10 -- like the JDeveloper ear generator produced. Still 10.1.2.0.2 OAS did not like this...the element was still foreign to it. Also the ear generator renamed my orion-application.xml file and put is own back in there, so I would have had to edit the ear file to get it to accept mine, during the ear generator's "yes" path. But even on the "no" path, when I put a version 2 orion-application.xml in my META-INF directory, with the same "mystery" element, the OAS deployer still could not deal with that element.
3. The The "Yes" version of the ear failed to deploy on a 10.1.3.4 OC4J (stand-alone) version due to a Null Pointer exception I think.
4. The "yes" version succeeded when I deployed it to the pre-configured OC4J which is installed in the /jdev/extensions directory. Although as noted on the technet link above, I had to log in twice to get into EM. The first time gave a JAXB error. Also once in I did not have button images, so I had to go from memory.

So anyway...I am now asking our 10.1.2.0.2 OAS to find and consume this baby, now that it is WSRP-produced. But...my development computer is apparently on a different sub-net or something. So today I am going to change my development computer to be fixed IP, and try this stunt again. Wish me luck.