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

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>

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.

At the moment there seem to be a few glitches in ORDIMAGE support with JDeveloper 11 and some traffic on the forum. Just as a hint here's a snippet using af:media to display a image stored in an OrdImage attribute. note that I've had to expand the servlet reference out (that's the W/A for the current bug. Also if you've used this in 10.1.3, note that the expression for the Mime type is slightly different (excuse the wrapping in the source value):

<af:media source="/ordDeliverMedia?appModID=TuhraServiceDataControl&
                viewObjectName=TuhraService.AllImages1&
                contentCol=Image&
                rowKey=#{bindings.AllImages1Iterator.currentRowKeyString}"
           player="windows"
           autostart="true"
           contentType="#{bindings.Image.inputValue.mimeType}"/>


So, it's funny how the simplest of things can lead you off on an interesting road of discovery, particularly at 5:25pm when you just wanted to add that little feature into a screen before heading home. So last night I was adding some validation onto a form. I had a email field and decided to use the regular expression validator provided by ADF BC to manage the validation. The expression for validating email format (you know someone@somewhere.com/org/net) just happens to be one of the supplied expressions in the tool - Great Zero effort! Woops - slight problem my screen is failing, ah on closer inspection, this pre-canned expression expects the email address to contain only uppercase characters - OK I have three choices here.

1. Change the expression to support mixed case - Yes trivial to do but....
2. Log a bug for someone else to do the above and wait for the fix - naaa
3. Convert the contents of the field to uppercase - That's the one!

So after a little work in Google I was surprised to see that we could actually achieve this in no less than 5 ways with the combination of ADF Faces Rich Client (R11) and ADF Business Components. Here they are:

1. If you're using JHeadstart then that has a property on the defintion to enforce this kind of thing, and then under the covers they use JavaScript (see option 4) to do it
2. In ADF BC using a bit of code in the setter for the field to .toUppercase() the string as it comes in - you could see how this could be made generic using a custom property in the UI Hints for that attribute and a generic Superclass. So that would be a very workable solution and would apply with any client. However, no instant feedback on the client, the uppercase version would only appear after the field had been submitted up to the model
3. Using Styles - Ah sounds simple enough - sure enough setting contentStyle="text-transform:uppercase;" as an attribute on the <af:inputText> works just fine in terms of showing the data in upper, but it's eye candy only, the value of the field is still in mixed case when saved to the model - no good for this purpose then
4. Using a JavaScript call and a ClientListener. This approach is detailed by Lucas Jellema over on the AMIS Blog - good stuff as usual, but it seems a messy approach to me from the re-use perspective
5. Use a Custom Converter. This is something that Matthias Wessendorf blogged about in relation to building converters which have client side capabilities. This turned out to be just the ticket - You get instant conversion to uppercase as you tab out of the field, plus the way to enable uppercase on a field is simply to add a converter tag where needed with no need for script in the page: <f:converter converterId="StringAsUppercase"/>

There you go, I need to clean up the converter code and make it more useful to turn it into a more generic case converter supporting initcap and lower case as well, at that point I'll publish the code jar (and make the source available) so it can just be dropped into your projects.

So what did I learn today? This is always a good question to ask yourself and it's funny how sometimes the most fulfilling learning experiences can be totally random and unexpected. I was browsing for some information on ADF contextual events, which lead to me noticing a typo in the JDeveloper help file which in turn lead me to read a bit more of the name help topic and suddenly I learn something new. I love it!
In this case it was a code sample reference which mentioned <af:setPropertyListener>. Although I'd undoubtedly seen this mentioned before, it had just never registered as significant, but such was my mood this evening that I segued into the topic and started to drill down. So it turns out that this component is a sort of super version of our old friend <af:setActionListener>, but it adds much more control to the job of setting managed values. Unlike <af:setActionListener> which is restricted to operating in response to an action in the sense of commandButton or commandLink clicks, it seems that <af:setPropertyListener> is a much more promiscuous beast and can be configured to react to many different types of events and presumably nested within many more types of components as well. Unlike setActionListener which only sports a FROM and TO, setPropertyListener has an additional TYPE attribute which can be set to "action" but also many other event types. The legal values are: action, dialog, disclosure, focus, launch, launchPopup, poll, popupFetch, query, queryOperation, rangeChange, regionNavigation, return, returnPopupData, returnPopup, rowDisclosure, selection, sort, and valueChange.
At this stage I've not been able to drill down further into the possibilities of this as yet, but I can already conceive of a whole bunch of use cases where it might come in handy. Documentation is a little thin on the ground for this component right now but it all looks fairly self explanatory..