All GroundSide Blogs
Blogs hosted on GroundSide.com

In conjunction with the ADF Methodology Group I'm conducting a survey into the use of internal APIs within within ADF applications (for example
oracle.adfinternal.view.faces.model.binding.FacesCtrlHierBinding).
We are going to be introducing some audit rules into the product to help catch these, however, I do need help in tracking down the wild and wacky usages to which these internal APIs have been put, that way we can work out:

1. If we need to create a public API to fulfil this programming requirement
2. Suggestions for re-writing the code so that it uses existing public APIs
3. Examples of just plain dangerous stuff to do.

If you are willing to help please let me know at devtools-feedback_ww at oracle.com . I'm aiming to share the results at either a session or an unconference session at OOW, plus of course we'll push more smarts into JDeveloper.
I have published a list of the "bad" packages in the following document, http://groups.google.com/group/adf-methodology/web/adf-internal-api-usage.
Please join in and help!

This is just one of those things that takes a while to Google for the correct answer to, so I figure, the more instances and examples the better.
The scenario is where you have a standard install of Oracle Fusion Middleware. Good old Oracle HTTP Server / Apache is on port 80 and your Java EE app is out there on a managed WebLogic server, maybe on port 7002 or some such.
The basic question is how can I make my app appear to be running on port 80. Trivial once you've done it.
I'm using a fairly out of the box FMW 11g R1 install here on Linux so you'll hopefully be able to reverse engineer the paths and translate that for your system:

1. Navigate to product/11.1.1/as_1/instances/instance1/config/OHS/ohs1/moduleconf
2. For the application, create a new .conf file (any .conf files in this directory will be automatically merged with the main httpd.conf on startup)
3. So in this case I might create a file called sf311.conf
4. Now add the following, assuming that the j2ee app is called "sf311" and your managed WebLogic server is on port 7002


<IfModule proxy_module>
  RewriteEngine on
  ProxyPass /sf311/ http://[yourhostname]:7002/sf311
  ProxyPassReverse /sf311/ http://[yourhostname]:7002/sf311
  RewriteRule ^/sf311$ /sf311/ [R]
</IfModule>

A question came up recently about how you could re-run parts of the migration that occurs when you migrate from the JDeveloper 11g 11.1.1.0 (Boxer) release to the newer 11.1.1.1.0 (Bulldog) release. Specifically this concerned the automatic creation of unique IDs for all of your ADF Faces components that the migration performs.
It turns out that you don't really need to re-run the migration facility to do this as the in-built audit rules currently have a warning rule that checks for an ID and will fix it for you if you don't have one. You see this rule in action as it puts orange squiggles under components that don't have an ID in the source view of the page editor.
Anyway, what if you want to automate this process because you skipped the migration when you first opened the project in the newer version? here are the steps:

1. First you need to set up an audit profile that just does the things you care about. In this case just the ID detection. So off you go to Tools > Preferences in the menu.
2. In the tree, expand Audit and select Profiles
3. Use the Save As button to create a copy of any of the existing profiles. Call it something like AutoId
4. Uncehck all of the existing rules and then select the ones you want to use in this command line based run of the rules. e.g. ADF Faces > Component ID Rules > Check for ID when ADF Faces is Present
5. Save the new profile
6. Test the profile against something that breaks the rule. For example, in this case a JSF page containing a component with no ID. Just choose Audit from the Build menu and select your custom profile (AutoId)
7. Now you're all set. Just open a command window and navigate to the /jdeveloper/jdev/bin directory and issue the following command:


ojaudit -profile AutoId -f C:\temp\MyIDAudit\MyIDAudit.jws

The -f option here tells the audit framework to apply the default fix, which in this case is to generate a unique ID for the component. The final argument is the workspace I'm auditing. For more about the ojaudit capability just search for it in the online help or run it without any arguments in a shell.

I've just posed a new sample up onto samplecode.oracle.com which shows how a page that consumes a template can interact with components in that template to do things like collapse splitters and so forth. Importantly this is achieved without polluting the template with knowledge of the consuming pages. The sample shows how to perform the interaction both for full page and more importantly partial page refreshes.
The sample code project includes a full JDeveloper workspace and has no external dependencies. 11g is of course required.

If you have a little sample like this why not publish it to samplecode as well? - use the JDeveloper and ADF category.

Working on my of our internal systems this afternoon I hit one of those requirements that you push to the end of the to-do list and never quite get around to doing until they turn around and bite you.
In my case it was a matter of default values. This particular system needs to know about which Quarter something happens in, and I'd sort of temporarily hard coded FY09Q1 into the system until I go around to doing it properly. You guessed it I then totally forgot to do that and deployed the system live with the hardcoded value.
Sure enough everything was fine for a month or so until FY09Q1 was no longer the right answer anymore and weird stuff started to happen.
Ok we've all done it, fix it and move on.

So let's consider the use case...
Here the quarters are actually being read from a table which maps the start and end of each of Oracle's quarters for the next 10 years or so. Therefore the requirement here is really to set up the default value for the Quarter attribute to equal the Quarter name from the correct row in the Quarters table that matches today's date. Essentially a dynamic default value being read from a table based on some other calculation or factor, rather than being just a simple hardcoded value which we usually use in the default.
The question is can you do this in a declarative way? The answer is yes, thanks to the power of Groovy!

1. The first step is to create a new View Object that gives me access to the row I needed that contains the correct Quarter for today's date. Simple enough to do with a Where startdate < = :TODAY and endate >= :TODAY, where :TODAY is a bind variable which has a default value which is set to the Groovy expression adf.currentdate
   
2. VO does not need to be exposed through the AM as I only use it internally within the model. To get to it using Groovy I needed to open up the entity that contains the Quarter attribute that I wanted to default and create a View Accessor to this VO. This allows me to programmatically walk from the entity to the rows returned by the VO and if I needed to, pass values to the bind variable used by that VO. In this case, the default value of today's date will be just fine though. I called the accessor DefaultQuarterAccessor
3. Finally onto the default value itself. Change the value type to Expression and set the expression to DefaultQuarterAccessor.first().Quarter, where first() indicates that I want the first (and only) row in the Accessor rowset and from that I want the Quarter Attribute from within that row.

This same technique can be used to do all sorts of useful dynamic things with validators, error messages and default values without having to code up Impl files in Java. For example I use the same approach to look up friendly values for error messages. So rather than a basic message like "salary is too high for department 40" we can walk the related rows and come up with a much more meaningful messages such as: "Salary in Sales Administration is capped at 20,000" where I'm looking up both the proper name of the department and it's actual maximum value using Groovy expressions.

One note of caution though, it's easy to get confused between Groovy usage notation like this and the expression language you use in your view pages. They are different.

Note: This code refers to the production release of JDeveloper 11.1.1.0 (and patches) AKA "Boxer".