doing battle with WSRP, Part II

Had a great session with Oracle technical support over the trouble I have been having with portletizing ADF Faces. The analyst mapped out an upgrade path for me which will solve all my problems; he demonstrated on his upgraded scenario using ias 10.1.2.3 (instead of my 10.1.2.0.2), and using Portal repository 10.1.4.2, plus the mandatory updates (instead of my 10.1.4.0), and also if I am going to deploy to OAS 10.1.3.4, that I make sure I have applied the web center jar file that WSRP-enables your particular OC4J instance that you have designated for exposing ADF apps via WSRP.

If I do all this, he demonstrated that the same ear I was having problems with, worked like a champ! YAY.

(The SR is 7381737.994 if you need it for reference. If you cannot access it, please leave a comment for this blog entry, and I will see if our situations are similar enough to warrent further action.)

What forum is best for answering Oracle Portal-JSF integration questions?

WebCenter Framework Oracle Technet forum

The above URL is the WebCenter Framework forum on the Technet forums. This is the place that Peter Moskovits and similar people review and comment, and the place where questions get answered of the kind I have been dealing with lately.

I read the overview of WebCenter and I guess I did not realize that portal-JSF integration was synonymous with "WebCenter", but I think it is for some reason...

I hope it helps you.

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.

JSF Portlet Bridge for dummys

Today I read an entry from the blog of Oracle Portal Principal Product Manager Peter Moskovits, dated from about 9 months ago. It talked about JSF Portlet Bridge, and showed him creating a video of his creating a an application which demonstrated JSF Portlet Bridge at work.

I am just starting to learn about Oracle Portal, unlike Peter, so I thought the world of people who are at my understanding level might like to hear my comments. All of the following are eithe quotes from Peter Moskovits, or they are my interpretations of Peter's words or actions, coupled with what I know and have read.

So in JDev 11g you can right-click on a reusable item called a Task Flow, or a jspx/jsp page and something comes up which says "Create Portlet Entry...". Doing this action will create a file called portlet.xml which is apparently the key file in portlet applications. I believe this is the equivalent of doing what is called "portletizing" an application.

In Peter's video, he is deploying his portletized JSF application to the embedded preconfigured OC4J which also had the portlet container in it. Even after this app was portletized, Peter could still run the jspx/jsp files individually. But also Peter demonstrated that you could access something called a "portlet producer". Apparently there is something called WSRP which is a portlet producer. I guess WSRP is a web service also because it has a WSDL, which you need to copy and save if you are ever going to use the portlet-ized JSF app you made.,..and also deployed.

WSDL URL's are also called "endpoint URL's".

Although it appears you get to the portletized JSF applications though the WSRP service, portlet parlance says that your application "consumes" a portlet...just like an app consumes a web service.

So when you create your application that consumes portlets (preferable, hopes oracle, a webcenter template application out of JDev 11g) it is called a portlet consumer application. In JDev 11g (and probably all IDE's) you need to register the portlet producer with your application. In 11g Jdev this is done by...

1. clicking ViewController project
2. New --> WebTier --> Portlets --> WSRP Producer Registration
3. Name the portlet producer you are registering
4. paste in that WSRP WSDL you have been saving (see above)

After a successful registration you see a WSRP producer node in the Application Resources section. This opens up to child nodes and you see your portletized JSF app.

Then in your app you can just create you JSF (or other technology that supports using WSRP), and drag and drop the portlet out from under the WSRP producer node and onto the page. This will add the portlet tag and portlet binding to the page (assuming you are using ADF, ;-). If you run it you will see your page in a portlet on the browser.

So where is the JSF Portlet Bridge coming into play here? I read that the JSF Portlet Bridge bridges JSF and Portlet technologies...but where do the implementing classes reside. I think they reside on the machine where you first deployed your portletized JSF application. I am beginning to think that this app server that you first deploy your portletized JSF app does not need to have a Portlet Container...like Oracle Portal. I think it just needs that portlet.xml in order for WSRP to talk to it. I suspect that WSRP needs to be implemented on both ends...probably the same version...but maybe not?

I know this though, because Peter said it: when you create your portlet consumer application, you can use your published portletized JSF app in any other 3rd party portal that supports WSRP (and the version of WSRP you are using).

Still trying to digest all of this. Tomorrow I have a conference call with Peter and the rest of my teammates.

Here is the video Peter made... video

Also the link for the JSR for JSF Portlet Bridge has a Spec with some great overview material in it. It helped me.