Friday, October 30, 2009

You probably have noticed, if there is a custom folder structure in Oracle ADF ViewController project, newly generated Page Definition file always is placed in default location no matter where JSF page resides. I have heard, in next releases Oracle will generate Page Definition files based on JSF page package structure. However, now instead refactoring manually, we can use JDeveloper 11g automatic refactoring for Page Definitions.

Its generated in default package location, while we want to have it specific package. We can move it manually, or we can use JDeveloper 11g refactoring functionality. Just select Page Definition file you want to move and from Refactor menu invoke Move command:

Page Definition file will be successfully moved to location you want and required changes will be done in DataBindings.cpx file as well:

While developing and deploying our Oracle ADF application on embedded JDeveloper 11g WLS (WebLogic Server), couple of times we have experienced strange WLS behavior. When developer was trying to run application from JDeveloper 11g IDE, after WLS server was starting up, application deployment was failing with following exception - java.lang.ClassNotFoundException: javax.faces.webapp.FacesServlet.

When we first encountered this exception, we didn't found any solution except just to do fresh check-out from SVN. After fresh check-out, application was running perfectly - strange things happen, there is always some magic ;-)

Later we found real cause for this deployment exception. We found solution as well, but still we didn't found exact scenario how to reproduce it in sample application, if you know scenario - feel free to post in comments. Now I will describe the reason and solution for this exception.

Exception happens, because for some unknown reasons, JDeveloper 11g IDE in very rare cases generates ViewController files in Model project:

This happens automatically, even when developer is not doing any work in Model. And then during deployment, WLS finds ViewController files in Model. And since Model don't have appropriate JAR libraries on class path (for absolutely logical reasons), it throws exception about javax.faces.webapp.FacesServlet not found:

In order to fix this exception, just go to file system and remove public_html folder from Model project:

Now go to your Model project, refresh it - not needed Web Content is gone:

When Web Content is removed from Model, you are ready to deploy and run your application again.

Download updated sample application - ADFIntegration4.zip. I have updated it with one more application - SharedApp, where I have extracted common Java classes I have used previously - JSFUtils and ADFUtils. Lets see how it works.

First, I have application where I'm using common Java classes - JSFUtils and ADF Utils:

There are more applications in my infrastructure, and all of them are using same classes. You can imagine, if we need to do change in those classes, we will need to replicate it across all infrastructure. In order to avoid this, we would prefer to keep those classes in unique physical location, so when there will be any change it will be propagated automatically - since all applications are pointing to the same location.

Lets refactor applications and extract common Java classes into separate project. I will delete local common files and will copy them to SharedApp application, Shared project:

When refactoring is completed, I can come back to original application and add project from SharedApp application, yes we can add project even from different application:

Shared project is added, I can see common Java classes are there:

When we have Shared project added, one thing we need to do, is to specify ViewController project dependency on external Shared project:

Dependency is set:

ADFUtils are now imported from shared location:

Its important to mention, when you will generate ADF Library JAR from your application, classes included through dependency will not be included into JAR package. This means, you will need to enable same dependency in your master application - in order for common Java classes to be loaded on runtime.

Friday, October 23, 2009

While I was on Oracle OpenWorld'09 last week, I heard lots of questions about how to split and integrate Oracle ADF applications. It seems quite hot topic now on the market, mainly because many people started Oracle ADF 11g projects recently, and now they are in a phase when applications are growing and becoming large. Naturally, when application growing, its harder to control it and keep performance on suitable level. In my project - Slides: Oracle ADF 11g Production Project Experience, we did application splitting into smaller applications and this helped us to keep development performance on solid level. Because splitting/integration topic is hot, I decided to continue a series of my posts and describe how you can reuse common files across splitted applications. Check my previous posts for the same topic:

I have developed sample application for today post - ADFIntegration3.zip. This application is based on applications from my previous posts mentioned above. It contains one new application called CommonApp, I have created there property file with internationalization support and simple Java class to get currently logged in user name:

Java class and labels will be reused in all three splitted applications. Main strength - common files will be included into different applications, however physically those files will reside on one location. This means, no matter from which application common files will be modified, other applications will be updated with this change automatically.

Common Java class - SecurityUtils.java and file with labels - ButtonsBundle.properties are included into LocalApp application structure:

Same files are included in RemoteApp application structure:

In order to include Java classes, its enough to put Java class files from separate application on your current project Source Path - point to src folder:

Regarding label bundles, additionally I would recommend to register reusable bundle in Bundle Search window, this will allow to use bundles available on Source Path directly through Set Text wizard when assigning labels:

With registered bundle, you can use labels from bundles available in separate applications and declared on project Source Path, same as they would exist in your current project - through Select Text Resource wizard:

You can use common Java classes, by declaring Managed Beans for example. In all three applications I have declared securityUtils bean, its based on common Java class from separate application:

I can use this bean as usual, through Expression language:

On runtime, when I'm running integrated application, I can see labels are assigned properly, current user name is returned correctly from securityUtils bean as well:

Same thing works well in integrated application, common labels are visible and Managed Bean logic is executed:

Tuesday, October 20, 2009

For those who missed Oracle OOW'09, you can watch my video recordings for Steve Muench session - Oracle ADF: Oracle Fusion Applications Teams' Best Practices. You can download slides from Steve Muench blog. Thanks to Justin Kestelyn and his approval to post those videos.

Sunday, October 18, 2009

Here is my video recordings of Clemens Utschig (Sr. Principal Product Manager, SOA Architect at Oracle Corporation) session on Oracle OpenWorld'09. I enjoyed his talk and demos, he gave great and clear overview for Oracle SOA 11g.

Tuesday, October 13, 2009

Yesterday I was on the 52nd floor of Bank of America building in San Francisco. They have Carnelian room there, with 360° views over the city. I saw Safra Catz and Charles Phillips there, Safra Catz was giving a brief talk.

Sunday, October 11, 2009

Yesterday, we had a day long trip outside San Francisco, with Oracle SOA Advisory Council people. We have tried barbeque oysters close to Point Reyes National Seashore (where Asia and America continents meet), it was tasty:

Here I'm in Oracle HQ, Redwood Shores. I took a picture while flying today, somewhere between Iceland and Canada:

Tomorrow (actually today - on October 9th) I'll have ACE Directors briefing in Oracle HQ and possible meet with Oracle executives organized for Oracle ACE Directors. I'll participate in Oracle SOA Advisory Council here. And after dinner we'll go to San Francisco for Open World.

Friday, October 2, 2009

There is one not well advertised, but great feature in Oracle ADF framework - Custom Declarative Components development for ADF Faces Rich Client. Its really powerful thing, because it allows to build your own components based on groups of standard ADF Faces Rich Client components. There is an article on OTN written by Frank Nimphius, where he describes how you can build, deploy and use this type of components - How-to bind Custom Declarative ADF Faces Components to ADF. In my post, I will give you an example of practical usage, and will describe how Custom Declarative Components can be applied.

Download sample application - AdvancedLOVComponent.zip. This archive contains two JDeveloper 11g R1 applications. One implements Custom Declarative Component, and second is using this component. Developed component represents LOV and description field as one element. Its very common requirement coming from Oracle Forms, to give LOV component and provide description text as well. In Oracle ADF, its usually developed with two ADF Faces Rich Client components - af:inputListOfValues and af:outputText. But, why not to put those two into one and create our own LOV tag. This component will join af:inpitListOfValues and af:outputText:

There is PartialTrigger dependency declared on af:outputText from af:inputListOfValues. And af:inputListOfValues is set as AutoSubmit component. This will allow to change LOV description text value, when LOV value itself is changed.

Main trick with those components is that we can set attribute values on runtime dynamically, from declared attributes. In my sample I'm providing five attributes, among them LOV value and model values, labels and LOV description text value:

This set of input attributes can be extended anytime, without affecting already created usages on your pages.

If we will look into component source code, we will see standard LOV and Output Text tags. Only one specific, those tags get attribute values from declared input attributes instead of bindings:

You need to deploy developed component to ADF Library in order to use it in your project:

Now we will switch to application, where we will use development component on JSPX page. Before using custom component, you need to declare custom tag library:

When custom tag library will be declared, components will be present in Component Palette window:

Drag and drop custom component to JSPX and you will see it in Structure window:

Let's see in source code - one custom tag andrejusb:ListOfValuesAdvanced implements two standard components - af:inputListOfValues and af:outputText. That's great, because it can save development time for LOV's at least twice. And it's not only about time, but about code quality and reusability:

Attribute values for custom tag are set in standard way - from bindings.

On runtime, custom tag is rendered as DepartmentId LOV and description text for specific LOV value (Control And Credit in this case):

LOV from custom tag works same as standard LOV. Let's open LOV popup and change current value:

When new value is selected in LOV, description text is updated as expected. And both elements are present on JSPX as single element: