Friday, February 27, 2009

MyFaces Orchestra conversation-scope

I have experienced some issues with ADF Faces (out of JDev 10.1.3) which (I was told) were probably related to inadequate garbage collection (probably on session-scoped managed beans and variables). So I have been looking for something that would help this application's robustness.

I saw a product which may help with some of this. It is called MyFaces Orchestra, and it might be worth looking into. It would allow custom bean scopes called conversation-scope. This framework uses Spring. If there is a problem with accumulating garbage, this would surely help keep such things under control. Apparently improving things like this could be an iterative process; conversations are by default of session duration. But later you can group beans and garbage collect whenever you decide the need arises. But even the act of putting all session-scoped beans into this framework might be a great first step to helping this situation.

Wednesday, February 25, 2009

Deploy ADF Rich Faces Client app to OAS 10.1.2

My team lead asked me to investigate the idea of moving ADF Rich Faces applications (deploy, that is) into OAS 10.1.2...or at least 10.1.3.

Shay Shmeltzer said the following:

ADF Faces Rich Client require JSF 1.2 (part of Java EE 5).
OAS 10.1.2 came with a Java EE 1.3 server - you can install an OC4J 10.1.3 on it and that will bring you to Java EE 1.4 - but you still won't get the needed JSF 1.2 support.

On top of it the ADF 11g libraries were compiled with JDK 1.6 - OAS 10.1.2 uses JDK 1.4 (or maybe even older version).
Let us assume that ADF Rich Faces components uses new features of JDK 1.5 at least, even though it is compiled with JDK 1.6 (this may not be a valid assumption...if they use features that are only in 1.6...which is possible I guess). Is JSF 1.2 certified with J2EE 4 or 3? Let's assume not. So we would either have to find some weird JSF implementation that tries to implement JSF 1.2 features, while being compatible with JDK 1.4. That might be possible, but would it be profitable or interesting for anybody to do such a thing? I do not know.

What about somehow installing what is necessary into a J2EE 1.3 server to be able to process Java EE 5.0 stuff? I think it would be easier to simply use a different container...

But what if it is not. Would it be less work to extend a web server so that its core includes multiple j2ee version capabilities...than it would be to simply install a new webserver and reference that? What about manhour costs?

But what if I developed my own brand of rich faces that looked and smelled pretty much like Oracle ADF Rich Faces, but worked with OAS 10.1.2, or 10. 1.3? The end users would not have to break down and pay for licensing from Oracle (which, by the way, may be covered under their license anyway since there is some transferrance of licensing from OAS 10g to Oracle Fusion Middleware 11g...but they have not got around to checking yet...)

Given what I know this last option seems the best. Even though it would take eons for me, alone, to get the full suite of Oracle Rich Faces look-alike components implemented and debugged. But it would be fun to try...

Tuesday, February 17, 2009

Migrating ADF app from JDev 10.1.3.x to JDev 11g

I guess I had not thought this all the way through before. Now that I have, perhaps others can benefit.

Let's say you have an ADF application and you want to migrate the application to JDeveloper 11g.

From reading the forum I gather it matters (perhaps it does not any mattered in October 2008)

First, know that today I created an application in ADF in using ADF/BC and JSF. I used order and order_items tables to create the simplest possible default, read-only drag and drop page. Then I copied that Application folder over the analogous mywork folder on the JDev 11g side, pasted it in, and opened it in JDev A migration wizard opens up and tells me that not only is it converting my J2EE technologies to Java EE 5.0 (i.e., JSTL 1.0/1.1 to 1.2, and JSF 1.1 to 1.2), but also is migrating me to the Apache Trinidad JSF libraries automatically. (Also the migration wizard told me it is migrating me to Webapp 2.5...not sure what that entails...I thought it was the same as going from J2EE to Java EE 5.0...but maybe not). So when I click Finish, the migration successfully migrated this simple app. I then ran my one view/screen in this app.

Failure. Damn...but the failure exception trace showed a problem finding the class UIXPanelTag. So I searched for UIXPanel in all the files in my converted Application using the Search Files menu command. The only references it found were in a jar file located in WEB-INF/lib. So I looked in my project properties... Basically I had gotten accustomed to including ADF Libraries, ADF Portlet library, and Custom Components library in my JDev instance. So when I created this quick little ADF app, those files got included as well...which makes sense for the ADF libraries, but the wizard did not know what to do with the portlet or the custom component libraries, so it just made like they existed...unfortunately...apparently they do least not by the same name... So a compile error happened when I tried to build/run the application.

So my solution was to open the view project properties, remove the portlet and cust comp tag libraries, then also removed the place holder entries for all the libraries JDev 11 could not find, but were referenced since this was a converted app.

Then the app ran fine!!! Whee!

Also (for more complex good ol' SRDemo application) basic migration process is explained here (thanks again to Shay Shmeltzer for calling to Steve Muench article!!!!!):

Thanks also to Shay for also noting that, "if your migration process get stuck - try invoking JDeveloper using the jdev.exe and look for any specific exception in the console window."

Oracle Portal? Oracle WebCenter? Oracle WebLogic Portal? huh?

I have reviewed these documents. I have some thoughts about them...

Oracle Portal, Oracle WebLogic Portal, and Oracle WebCenter Suite are all sepparate offerings/product suites. Portal products are extensions of their respective app servers (OAS, and Oracle WebLogic), which are geared toward developing portals -- sites and pages which display and allow interaction with other sites and pages -- portlets.

WebCenter Suite includes the following items:
WebCenter Framework -- a JDev extension to help you do more Web 2.0, BI, and SOA stuff.
WebCenter Services -- I am guessing these are either the enabling libraries the the above JDev extension, or maybe they are sepparate program, or perhaps even web services.
WebCenter Interaction -- a development team collaboration suite (formerly BEA Aqualogic User Interaction)
WebCenter Anywhere -- wireless services (hardware? local or remote/hosted?) that let you get alerted to events generated by your webcenter apps, or interact with them, using various portable devices (blackberries, etc.)

I am also reading another document to round out my understanding of web center:

So we ask the questions: What about all of our Portal work? Is it integratable? Are they planning on merging/phasing out/replacing Portal?

After reading the WebLogic Portal and Oracle Portal statements of direction above, I am under the impression that Oracle is doing what Oracle does best: obtaining/promoting competing products, and letting them fight to the death. It looks to me that the Oracle Portal longevity is being promoted a bit more than the Oracle WebLogic Portal product (suite)...but the documents seem to like both products and highlight aspects of both that are being highly praised and integrated, and also other parts that are being sifted out. I think both documents point to a future time when the portal products will be part of a larger product suite...perhaps WebCenter.

After reading these, I come away feeling assured that there is probably going to be continuing support for these products, and that any integration or communication between the portal world and the WebCenter/ADF/application world is going to be supported -- we will probably have to end up choosing which integration method makes the most sense.

Also I feel that Oracle sees Web 2.0 as an evolution of Portal-type thinking. Vedy interestink...hmmmm....

Monday, February 16, 2009

put 11g ADF app on 10.1.2?

I was asked if we could possibly put an 11g ADF app (rich faces) on an AS 10.1.2 server instance. My instant response was, no...but I needed well defined reasons and my knowledge was failing me. So after a question to Technet here is what Shay Shmeltzer said to me on this subject:

Here is the thread:

Here was his answer in the thread above:

It's very simple: ADF Faces Rich Client require JSF 1.2 (part of Java EE 5).OAS 10.1.2 came with a Java EE 1.3 server - you can install an OC4J 10.1.3 on it and that will bring you to Java EE 1.4 - but you still won't get the needed JSF 1.2 support.On top of it the ADF 11g libraries were compiled with JDK 1.6 - OAS 10.1.2 uses JDK 1.4 (or maybe even older version).

So: here is my take what he said was this:

  1. I have studied the differences between JSF 1.1 and JSF 1.2. These two technologies are implemented by different “implementations” or different sets of Java Libraries. I believe the new libraries are compiled with JDK 1.5 or 1.6. Whereas 1.1 is compile with pre-1.5 JDK versions.
  2. JSF 1.2 components use some Java EE XML formats for the implementations of their components/tags.
  3. The JSF Java libraries main differences are the substitution of “expressions” for “binding” which simplifies and clarifies the purpose of the use of these items in many ways, especially when building custom components. For example a property which is designated as being able to accept a method expression can also take a literal as well as an EL method designation, just by virtue of being an expression. The older method binding would require additional work to deal with a property being able to take a literal or an EL expression. (Please, note that not only are there other differences between 1.2 and 1.1 that I do not yet know about because I am still learning things about JSF 1.2.)
  4. JSF 1.2 is expected to be used with JSP 2.1, JSTL 1.2 and Java EE 5.0, which are usually a factor of which app server/servlet container you are using (i.e., OC4J version, or whatever servlet container you are wanting to use). Whereas JSF 1.1 is designed to use JSP 2.0, JSTL 1.1 and J2EE 1.4.

Note: there are new features in JSF 1.2 that did not exist in 1.1.

Thursday, February 12, 2009

11g rich table

More thoughts about JDev 11g rich table. It is very important if you are having trouble controlling the width of the table that you check the width property. The wysiwyg editor for Jdeveloper for this component will allow resizing on the screen by clicking and dragging. But once you do, it codes a width in there which disables default sizing behavior, and was causing me some major head-scratching.

Also, it does not appear that you can turn off the table component's outline. We shall see.

Also, it appears when adjusting column widths in such a table, that it is best to stay away from using the wysiwyg editor to drag things around. It seems the result of resizing columns is unpreditable to me at this point in my learning; what I mean is this: I tried to resize one column and all columns resize. I can kind of control column resizing, however, by manually changing the columns' width property...because those I can multi-select and change all their properties at once to something smaller (or larger).

Also (a lot of also's) I wanted to avoid the horizontal scrollbar for the table component. But if you use any of the column stretching capabilities it seems to enact the horizontal scrollbar, even the size of the inner content only exceeds the width of the div by a few pixels. I think I could control this if I used some javascript to somehow identify this div's id, the used overflow-x css command somehow. But I cannot control this on the skin level.

In many cases, of course, things render much better in these regards in firefox than in IE...

Wednesday, February 11, 2009

JDev 11g Rich Components

My favorite rich component is the RichMenuBar component because it sounds like you could EAT IT!! :-)

Nevertheless, I am having fun exploring all the new and interesting developments in JDev 11g ADF Faces...the rich sequel. Here are some things I have noticed:
  1. af:tables might handle paging through records it a scroll now??? I do not readily see an option to designate how many rows go on a page...of course maybe that was never an option.
  2. Adjusting af:table columns in the ide is possible but tricky. But you can tell it to create a blank column at the end to take up any remaining white space.
  3. af:breadCrumbs are new. Very nice.
  4. If you do custom skinning you will be delighted to know that you can now EXTEND blaf or any other skin family!! No longer do you have to invent your own. This is really great!!
  5. af:menuBar can contain af:menu or a command item. And menus can contain menus or command items....that means you can now do real menus...that look really, um, menu-like!! yay! out of the stone age and into the light...
  6. one of my favorite things here is their tool which is an application which allows demoing of each component with respect to functionality, usage and skinning experimentation. I mentioned this a subject or two ago.
  7. There are other things, but it is getting late and I am tired. I will try to elaborate more tomorrow.

Friday, February 6, 2009

JDev 11g Cue Card impressions

To begin to get a feel for how things have changed between JDev 10g and 11g, I decided to follow the cue cards to create a new Fusion Application and also the cue cards for the ADF Faces features.

For the Fusion App here are my impressions:
  1. The same basic features are still there, only with a new look and feel.
  2. I think there were only a couple of mis-matches between what I experienced and what was expected by the cue-cards. They were that in one case an OrderId1 field on the editOrder screen needed a numeric converter added, and in another case there was a default value that needed to be added (0) for a field/column in the orders entity (order version id or something like that).
  3. The page flow diagram has been enhanced. Running an app now needs to be done with respect to this page flow diagram.
  4. There are several more WEB-INF xml files that are created as part of the development process.
  5. View Accessors are used a lot to do LOV/Menu/Drop-down list functionality. These are connected at the entity level also. I am pretty sure such work would have had to have been done programmatically if at all in JDev 10g ADF.
  6. View Criteria functionality also would have been done programmatically in 10g; now much is declarative...i.e., done through wizards and dialogs. View Criteria seem to be intimately connected to Search sections of a form. In 10g there were several ways to make these search forms happen. With the help of the ADF Developer Guide these different methods were not so bad, but there with View Criteria, now you can drag and drop such a Search Form region onto your page. Also you apparently do not have to redefine a new query for each search form you want to create...just a new search criteria. Also I notice there is a new ADF Faces component called af:query.

I will post some more thoughts as I finish up these cue cards. I think these will be a great warm up to actually working with 11g on a daily basis.

Wednesday, February 4, 2009

Very cool demo app!

News flash: there is a really cool app that Oracle put out to showcase their new components and features and skins with ADF Faces Rich Client suite. I thought you had to install it to look at it. But Moskovits's blog says it's online also at the following link!!

My goodness: if you don't study this site you are really missing out. What a lot of work those Oracle guys and gals have done!!!!!

This demo app shows all the rich client components and what they do. You can also view the usage of each of them. Incredible.

Also if you want to download this app to study it you can do that as well...
Just click on

In there is a war file you can download. Take that war file and import it into a Generic application as a project. In the new project dialog there is an option to create a new project from a war file.