The GroundBlog By Duncan Mills
Duncan Mills's WebLog from GroundSide

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!

If you are, then you need to view and respond to this announcement which I've posted on the OTN discussion forum...

We are now mere days away from shipping the new JDeveloper 11g Handbook - A guide to Fusion web development".
Copies will be physically available next Monday just in time for Oracle Openworld. All of us authors will be there at OOW and we'll be more than willing to sign copies - if you can find us. I guess we could make it a kind of competition!
Hopefully the Oracle Bookstore in Moscone West will have a few copies to sell and you'll be able to flick though (and win!) a copy in the OTN Lounge

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.