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

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.

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.

The new OTN Sample code site (see the entry "New Service for OTN Members: Public Sample Code Repository" in the OTN homepage) has been recently been introduced and like many folks I've been itching to start using as a great place to store all of those samples that people keep asking me about.
For my first project, however, I decided that this would be a great place to put the sample application code that accompanies the upcoming JDeveloper 11g Handbook. My main interest here was to see how simple it was to work directly with the Subversion source control repository associated with a project. i.e. Could I work directly from within JDeveloper on a samplecode.oracle.com project.
Well the answer is yes, and it's pretty easy, certainly much easier than working with sites like SourceForge in the past which has been a whole mess of private / public key stuff and Plink.
Having requested my new project and once the basic site was created from the template all the information I actually needed was available on the Subversion link of the project homepage:

Then on that page you have information about how to checkout from SVN from the command line. The key part here is to take the relevant URL:

and then use that in your JDeveloper version navigator to create the connection:

And you're done. I can now check out and check in to the project directly from JDeveloper in the normal way. Notice I did get a warning about the site certificates not being trusted but JDeveloper allows you to ignore that on a temporary or permanent basis. I'll look into that one, it's no big deal.