Tuesday, March 10, 2009

doing battle with WSRP

Victory! I got a portletized ADF app to deploy to JDeveloper'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 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 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 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.4, because the process of creating the "yes" ear file installed an orion-application.xml file, which had an element that the OAS 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 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 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 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.

No comments: