One size doesn't fit all

JDev 11gR1: the most obscure new IDE feature

noreply@blogger.com (Chris Muir) — Tue, 14 Jul 2009 00:00:00 +0000

Each new release of JDeveloper brings an explosion of blog posts from the excited JDeveloper advocates and Oracle staff. Within a week or so all the major new features are identified and explained, leaving slow typers like me wondering what to cover to get readers excited.

So for the latest JDeveloper 11gR1 release, I've taken the opportunity to explore for the most obscure feature, the feature hardly anybody is likely to see, or possibly even care about until they discover it.

And today I think I found it. Small celebratory "woohoo!" on my part.

Take a look at this screenshot of the source code of a standard ADF Faces RC page in all its XML glory:

In the next picture I've deleted the af:inputText tag. Besides the removal of the tag, can you see the subtle change in the source code editor? Believe me you'll have to look really hard:

Spotted it? Let me point it out:

Can you see the little pastel pink colour in the new thin left margin that runs down the page? If you float the mouse over the colour you get:

...a little popup that shows the code you deleted. The new margin feature shows visually the addition and removal of code as tied to the IDE's undo history. If you right click on the small colour segment you get a context menu that lets you work with the change:

As promised, I believe this to be the most obscure new feature in JDev11gR1. I set a friendly challenge to readers to find an even smaller obscure new feature in the latest release.

Increasing/decreasing JDev 11g ADF Faces RC page font size at runtime

noreply@blogger.com (Chris Muir) — Tue, 07 Jul 2009 04:08:00 +0000

A feature seen on some web sites is buttons to increase and decrease the text font size. While most browsers supply this functionality by default (eg. In Firefox you can press Ctrl plus or minus), giving web page buttons to do this can assist less computer literate users who may not now about the browser's inbuilt functions.

The solution requires a javascript routine. A quick Google on "javascript increase fontsize" returns a number of useful hits including this one by White Hat Web Design.

White Hat's code is a fairly common example available on the internet for doing just this in a standard web page.

Providing this functionality in JDeveloper 11g's ADF Faces RC requires a bit of tweaking. The following describes the bits of code you'll need.

Javascript

The following code takes the White Hat javascript and tweaks it:


var fontMin=10;
var fontMax=36;
function increaseFontSize(event) {
   event.cancel();
   var p = document.getElementsByTagName('span'); // here
   for(i=0; i < p.length; i++) {
      if(p[i].style.fontSize) {
         var s = parseInt(p[i].style.fontSize.replace('px',''));
      } else {
         var s = 14;
      }
      if(s!=fontMax) {
         s += 2;
      }
      p[i].style.fontSize = s+'px';
   }
}

function decreaseFontSize(event) {
   event.cancel();
   var p = document.getElementsByTagName('span'); // and here
   for(i=0; i < p.length;i++) {
      if(p[i].style.fontSize) {
         var s = parseInt(p[i].style.fontSize.replace('px',''));
      } else {
         var s = 12;
      }
      if(s!=fontMin) {
         s -= 2;
      }
      p[i].style.fontSize = s+'px';
   }   
}

First tweaks to the original code, note that each method now takes an event object, and then cancels the event on executing the javascript. While I'm not entirely over the need for this, my understanding is it hooks into the ADF Faces RC javascript engine and we'll see a bit further down in this post the usage of the clientListener tags to invoke this javascript. (Some more documentation on the ADF javascript engine would be appreciated Oracle – hint hint).

Secondly note the two commented lines. The original code searched for <p> tags, while in ADF Faces RC pages we need to search for <span> tags, as this is where ADF Faces RC places raw text.

Load the javascript into JSF

In the page we wish to include the javascript we include the following code:

...assuming you stored the above javascript in the ViewController public_html/js subdirectory as fonts.js.

(Alternatively this tag could go into your JSF template so you only need to include it once)

Note that this is in fact a Apache Trinidad component, not ADF Faces RC. As such you also need to change your JSF page's <jsp:root> tag to include the Trinidad HTML tag library as follows:


  xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1" 
  xmlns:f="http://java.sun.com/jsf/core"
  xmlns:h="http://java.sun.com/jsf/html"   
  xmlns:af="http://xmlns.oracle.com/adf/faces/rich"
  xmlns:trh="http://myfaces.apache.org/trinidad/html">

Buttons

Next in order to provide buttons to call the javascript we include the following command controls on our page:

Note the use of the clientListener tag to invoke the javascript functions we defined above.

Near success

At this point if you run your page you should see the fonts scale up and down when you press the relevant commandLink button.

One thing you may notice is that if you have other text based command and go components on the page (eg. <af:commandLink> <goLink>), the text fails to grow or shrink on pressing your new buttons. This occurs because the command and go components are rendered in a HTML < href> tag rather than the <span> tag we coded in our javascript. An easy solution to this is to modify your components as follows:

Original

Fix

As the command control now uses a normal outputText component to render the text, this in turn is rendered as a HTML <span> tag in the end HTML page and will be subject to our javascript routines results.

One other thing you might notice, is in Firefox the font fails to shrink at all. Remember that Firefox has a user preference that stops this from occurring under Tools -> Options -> Content -> Fonts & Colours -> Advanced -> Minimum Font Size, a particularly useful feature on my laptop that runs at 1 sqwillion by 1 sqwillion resolution, where I can't see a d@mned thing.

Oracle ACE Director of the Year

noreply@blogger.com (Chris Muir) — Tue, 30 Jun 2009 21:50:00 +0000

I had the very pleasent surprise at the end of the ODTUG conference this year to be told that I've won Oracle Magazine's Oracle ACE Director of the Year award for 2009. With out a doubt this is an honour and I'm very appreciative to Oracle Corporation and its staff for this award, and especially to those who were kind enough to nominate me.

I was joking with Grant Ronald a few months back that I received my original ACE Director nomination when my first daughter was born, so was looking forward to becoming the grand-poo-bar when my second arrived. Apparently such flippant remarks become reality.

Thanks to everyone who has sent on their congratz via the other media channels including Twitter, LinkedIn, email and more.

I must also give a very special thanks to my "partner" in crime Jenny who gives her generous support and incredible patience in letting me pursue my Oracle activities. Mind you I've kept my side of the bargain and neither of my children yet know what an Oracle database is.

Making JDev just that little faster on WLS

noreply@blogger.com (Chris Muir) — Sun, 28 Jun 2009 22:03:00 +0000

During the ODTUG conference this year Lucas Jellema and myself discovered a little WebLogic Server feature (thanks to a presentation by Chris Bucchere) known as "fast-swap" that may have significant benefits in making the code-deploy-run cycle much shorter with JDeveloper. As usual Lucas is the quickest to the blog punch, and has blogged it here.

Take time to check it out.

If anybody finds any limitations beyond those mentioned in Lucas's post, in particular those relating to JDev and ADF *please*let*us*know* as it will assist the entire JDev community.

Stress & load testing web applications (even ADF & Apex) using Apache JMeter

noreply@blogger.com (Chris Muir) — Tue, 23 Jun 2009 03:00:00 +0000

A couple of years ago I presented Take a load off! Load testing your Oracle Apex or JDeveloper web applications at OOW and AUSOUG. I can't recommend enough the importance of stress testing your web applications, it's saved my bacon a number of times. Frequently as developers, we develop under a single user (developer) model where concurrency issues are easily avoided. When our programs hit production, with just 1 more user, suddenly our programs grind to a halt or fall over in bizarre places. Result, pie on developers' faces, users' faith in new technologies destroyed, and general gnashing of teeth all round. Some simple stress and load tests can head off problems way before they hit production.

(For the remainder of this post I'll infer "stress testing" and "load testing" as the same thing, though strictly speaking one tests for your application falling over, and the other how fast it responds under load)

So how to go about stress testing a web application?

There are numerous tools available to stress test web applications, paid and free. This post will look at the setup and use of Apache's JMeter, my tool of choice, mainly because it is free! ... to undertake a very simple stress test. Apache JMeter is available here, version 2.3.3 at time of writing.

On starting JMeter (<jmeter-home>/bin/jmeter.bat on Windows) you'll see the following:

Creating a Thread Group

From here what we want to do is set up a Thread Group that simulates a number of users (concurrent sessions), done by right clicking the Test Plan node -> Thread Group option. This results in:

As you can see the Thread Group allows us to set a number of threads to simulate concurrent users/sessions, loop through tests and more.

Creating HTTP Requests

From here we can create a number of HTTP requests (Test Plan node right click -> Add -> Sampler -> HTTP Requests) to simulate each HTTP request operation (Get, Post etc), HTTP headers, payloads and more. However in a standard user session between server and browser there can be a huge array of these requests and configuring these HTTP requests within JMeter would be a major pain.

Configuring the HTTP Proxy Server

However there's an easier way. Apache JMeter can work as a proxy between your browser and server and record a user's HTTP session, namely the individual HTTP requests, that can be re-played in a JMeter Thread Group later.

To set this up instead right click the Workbench node, Add -> Non-Test Elements -> HTTP Proxy Server:

To configure the HTTP Proxy Server do the following:

* Port – set to a number that wont clash with an existing HTTP server on your PC (say 8085)
* Target Controller – set to "Test Plan > Thread Group". When the proxy server records the HTTP session between your browser and server, this setting implies the HTTP requests will be recorded against the Thread Group you created earlier, so we can reuse them later
* URL Patterns to include – a regular expression based string that tells the proxy server which URLs to record, and those to ignore. To capture everything set it to .* (dot star). Be warned that during recording however, if you use your browser for anything else but accessing the server you wish to stress test, JMeter will also capture that traffic. This includes periodic refreshes by web applications such as Gmail or Google Docs that you don't even initiate; I'm pretty sure when replaying your stress test, Google would prefer you not to stress test their infrastructure for them; stick to your own for now ;-)

The end HTTP Proxy Server setting will look something like this:

You'll note the HTTP Proxy Server has a Start button. We can't use this just yet.

Configuring your Browser

In order for the JMeter HTTP Proxy Server to capture the traffic between your server and browser, you need to make some changes to your browser's configuration. I'm assuming you're using Firefox 3 in the following example, but same approximate steps are needed for Internet Explorer.

Under Firefox open the Tools -> Options menu, then Advanced icon, Network tab, Settings button which will open the Connection Settings dialog.

In the Connection Settings dialog set the following:

* Select the Manual proxy configuration radio button
* HTTP Proxy – localhost
* Port – 8085 as per the JMeter HTTP Proxy Server option we set earlier
* No Proxy for – ensure that localhost and 127.0.0.1 aren't in the exclusion list

The above setup makes an assumption that the server you want to access is accessibly without a further external proxy required.

Recording your HTTP session

Once the browser's proxy is setup, to record a session between the browser and server do the following:

1) In Apache JMeter hit the Start button on the HTTP Proxy Server page
2) In your browser enter the URL of the first page in the application you want to stress test

Thereafter as you navigate your web application, enter data and so on, JMeter will faithfully record each HTTP request between the browser in server against your Thread Group. This may not be immediately obvious, but expand the Thread Group and you'll see each HTTP request made from the browser to server:

As can be seen, even visiting 1 web page can generate a huge amount of traffic. Ensure to stop recording the HTTP session by selecting the Stop button in the JMeter HTTP Proxy Server page.

Configuring the Thread Group for replay

Once you've recorded the session in the Thread Group there are a couple of extra things we need to achieve.

For web application's that use Cookies and session IDs (JDeveloper's ADF uses a JSessionID for tracking sessions) to track each unique user session, we cannot replay the exact HTTP request sequence with the server through JMeter, as the session ID is pegged to the recorded session, not the upcoming stress test sessions.

To solve this in JMeter right click the Thread Group -> Add -> Config Element -> HTTP Cookie Manager. This will be added as the last element to the Thread Group. I usually move it to the top of the tree:

Next we need to configure the Thread Group to show us the results of the stress test. There are a number of different ways to do this, from graphing the responses, to showing the raw HTTP responses. In this post we'll take the later option.

Right click the Thread Group -> Add -> Listener -> View Results in Tree, which will add a View Results in Tree node to the end of the Thread Group:

Finally save the Thread Group by selecting it in the node tree, then File -> Save.

Running the Thread Group

To commence your first stress test run, it's best to leave the number of spawned sessions to 1, just to see the overall test will work in it's most basic form. The default Thread Group number of threads is set to 1, so there is no need to make a change to do this.

To run the test, simply select the Run menu -> Start. On running the Thread Group, you'll see the top right of JMeter has a little box that tells if it's still running, and the number of tests to go vs total number of tests:

Once the tests are complete, this indicator will grey out.

We can now visit the View Results Tree:

This shows the HTTP requests that were sent out and on selecting an individual request, you see the raw HTTP request and the actual response. You'll note the small green triangles showing a successful HTTP 200 result. If different HTTP errors occur the triangles show different colours. Also remember that sometimes application errors don't perculate up to the HTTP layer in your web application, so you should check your application's logs too (in the case of a JEE application, this will be your container's internal logs).

Running a Stress Test

The obvious step from here is to change the Thread Group number of threads to a higher number.

From here take time out to explore the other features in JMeter. It includes a wide range of features that in particular make it useful for regression testing.

Caveats

Firstly remember when doing this you're not only stress testing your application, your stress testing a server, potentially stress testing databases, stress testing your networks and so on. Therefore you can have an affect on anybody sharing those resources. "Hard core" stress tests should be on separate infrastructure, after hours, aiming for as little impact on those around you!

Also keep in mind, besides seeing your application fall over at 2 users, 10 users, 100 users, which is an important test, try to be realistic about your stress tests. Stress testing you're brand-new-application to a 1 million concurrent users is probably not being realistic. How many concurrent user requests do you really expect and what response times do you need? Normally when I ask managers this question they'll answer with, "oh we have 1000 concurrent users, the application must support that many at any one time". However what they really mean is the application has 1000 users, potentially all logged into the application (ie. sessions) at the same time, but not necessarily hitting the server with HTTP requests at any onetime.

WLS 10.3 WSDL external policy attachment error

noreply@blogger.com (Chris Muir) — Tue, 16 Jun 2009 12:45:00 +0000

We recently encountered an issue with deploying JAX-WS web services to Oracle WebLogic Server 10.3 where the web service WSDL included a <wsp:policyReference> external policy attachment.

The error:


javax.xml.ws.WebServiceException: weblogic.wsee.ws.init.WsDeploymentException: Unable to to retrieve policy from URI 'externalpolicy.xml'
 at weblogic.wsee.jaxws.framework.jaxrpc.TubelineDeploymentListener.createServer(TubelineDeploymentListener.java:85)
 at weblogic.wsee.jaxws.WLSTubelineAssemblerFactory$TubelineAssemblerImpl.createServer(WLSTubelineAssemblerFactory.java:74)
 at com.sun.xml.ws.server.WSEndpointImpl.(WSEndpointImpl.java:152)
 at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:217)
 at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:467)
 Truncated. see log file for complete stacktrace

Note the name of the policy file in the error: externalpolicy.xml

Our WSDL included the following binding options referring to the external policy file:

Note the use of the <wsp:PolicyReference> tag with the URI attribute referring to the externalpolicy.xml file located in the same src directory as the WSDL.

The externalpolicy.xml included an MTOM policy, ultimately nothing special:



          xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
          xmlns:wsoma="http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization"
          xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512">

The deployment problem is caused because by default WLS isn't configured to search for external policy files on the CLASSPATH of the application.

The fix is however simple (and somewhat obscurely documented here)

Locate your WLS %domain_home%/bin/startWebLogic.cmd file and replace the following line:

set JAVA_OPTIONS=%SAVE_JAVA_OPTIONS%

..to..

set JAVA_OPTIONS=-Dweblogic.wsee.policy.LoadFromClassPathEnabled=true %SAVE_JAVA_OPTIONS%

ADF Faces RC: turning off the browser's autocomplete functionality

noreply@blogger.com (Chris Muir) — Thu, 11 Jun 2009 04:10:00 +0000

Modern browsers include an autocomplete function, effectively a poplist that shows the user's most recent entries for a set field in a list, for the user to choose from.

There are times when this functionality isn't desirable, such as credit card numbers, password fields and similar.

As detailed in the following Mozilla Developer Center page, both IE and FF support an autocomplete="off" attribute on form and input controls to suppress the browser's autocomplete functionality. Unfortunately this feature is not part of the HTML standards, and in turn is not a property of the equivalent tags in ADF Faces RC for JDeveloper 11g build 5188 (ER with Oracle Support pending).

There is a JavaScript solution that readers may be interested to see, and I thought this a good post because it shows the mechanism for calling JavaScript through the ADF Faces RC tags, something that I seem to be doing more and more.

The following example shows how to turn the autocomplete off at the form level:



  
  
  
  ...so on...

Points to note:

* The use of the "load" clientListener at document level to call the disableAutoComplete. This is the equivalent of the HTML body tags onLoad attribute.

* The use of the clientComponent="true" attribute in the form tag. This forces ADF Faces RC to generate a HTML form component with the same id in the resulting HTML page to be rendered. This is essential as the disableAutoComplete method requires the form id in the DOM in order to find the form via it's call to getElementById and turn off the autocomplete function.

Q&A With Grant Ronald

noreply@blogger.com (Chris Muir) — Mon, 08 Jun 2009 12:47:00 +0000

(This is a reprint of an article published in the UKOUG's Select magazine early this year)

When talking about Oracle Forms and JDeveloper, one Oracle personality stands out among others - long time blogger Grant Ronald from Oracle Corporation UK. Grant has for a long time “pimped” Oracle Forms and its big brother JDeveloper at Oracle events and user groups events around the world. His popularity is shown by his blog receiving on average 2000 hits per day. Lately, to reassure Oracle customers that Oracle intends to keep on supporting Oracle Forms and show that Forms has a future inline with JDeveloper, Grant has been responsible for the Oracle’s Forms Modernization message.

Chris Muir from SAGE Computing Services Australia conducted the following Q&A session with Grant to get the low down and latest on Forms and JDeveloper, as well as a little about Grant himself.

CM: What role do you currently play at Oracle and what does your day job entail?

Grant Ronald: Well, my title says “Group Product Manager” and the products I cover are Oracle Forms and Oracle JDeveloper. As a Product Manager you are responsible for the success of the products in your area. That encompasses everything from working with developers on features, the marketing department on campaigns or delivering presentations at events like Oracle World. In the morning you can be rolling your sleeves up and getting into code with a developer, and in the afternoon you can be meeting with the CTO. It’s that varied.

CM: How did you get into this Oracle gig anyhow? What’s your background at Oracle and computing in general?

Grant Ronald: Back in the early ’80s, home computing was slowly starting to take off with computers like the Sinclair Spectrum, Vic20 and BBC home computers, and it seemed like a new an innovative field to get involved in when I left school. So I got my degree in Computing Science then joined a small IT outfit in the UK that eventually got consumed by EDS. It was a pretty typical development role for about seven years, mainly focused on military applications, and my last job was designing, developing and leading the team for the development of the user interface for a military email system.

This took me up to 1996 when I fancied a change, and Oracle was looking for people with development experience on Unix and Motif in their support organization. So I joined Oracle Support where I eventually headed up the group who supported the local EMEA (Europe, Middle East, Africa) teams in Forms, Reports and Discoverer. Given that I was working closely with the Oracle Product Management team in this role, I was eventually persuaded to make the jump into Oracle Development!

CM: Ok, now for some tough questions worthy of any Q&A: You’re currently known via your blog for discussions on Oracle development including Forms and SOA, and presentations in Oracle Developer Days around the world. Previously you were also known for you work on JDeveloper. Why the change? Has Oracle internally panicked about the impression (my emphasis) customers are getting that Oracle has killed Forms, and now the need for Forms advocates?

Grant Ronald: There has not really been a change. The thing is, we’ve never stopped talking about Forms. I’ve got the air miles and passport stamps to show that we were still presenting Forms at Oracle World, ODTUG (Oracle Development Tools User Group), UKOUG (UK Oracle User Group), DOAG (German Oracle User Group) and dozens of other events covering EMEA, APAC and the Americas.

The Forms OTN page is still a hive of activity: news, events, whitepapers and how-to’s. Maybe people thought we had stopped talking about Forms because we were also talking about other technologies as well. Ten years ago if you developed on an Oracle database then you pretty much used Forms, simple as that. But the world has changed and there are other things to talk about now. Which makes sense, if you think about it; there is more need and more demand to be talking about the “new” stuff, especially when it is evolving at such a rate.

CM: On discussing Forms and considering that some Oracle customers are confused on the future of Forms, can you outline Oracle’s commitment to Forms in terms of existing versions and Oracle Support?

Grant Ronald: I think the strongest statement we have is the fact that we published a statement of direction five years ago and that statement remains true today. We’ve always said that we are committed to Forms and that there have been no plans to desupport it. That line has never changed. Regarding support, we’ve recently just extended the support date for 10.1.2 (the latest release of Oracle Forms) and Forms 11g is in development, having already had positive reviews from our beta testers. So we are lengthening the support dates, we are working on the next release and we are also discussing enhancements and features for post 11g. I think that’s all good news.

CM: Could the problem with Oracle Forms just be an image problem? It’s never been known for sexy development (a’la grey screens of boredom), and especially now that the web world, web rich clients, AJAX etc have taken off.

Grant Ronald: The sweet spot for Oracle Forms has always been the ability to rapidly develop rich, transactional business applications. So you see Oracle Forms applications in your government offices, airlines and bank back-offices etc. The need for visual “bells and whistles” is less at the fore than, for example, an online shopping application where a user makes a snap decision, often based on visual aesthetics, as to whether they will use the site.

But there is nothing to stop you pushing the boundaries of the visual aspects of Oracle Forms. We have customers who are using some of the features of Oracle Forms, like PJCs and Java beans, to really push the boundaries of the Forms UI. Like this story. So there is nothing to stop you modernizing your Forms application, starting with an update of the user interface.

CM: So what plans do Oracle have in addressing Forms customers?

Grant Ronald: We are continuing to present at all the major events and user groups. In addition, we’ve launched a focus page. This includes recorded webcasts on Forms strategy, calling web services from Forms and Forms new features. There are also white papers and customer stories as well. This is also being backed up by a roadshow which to date has hit nearly 20 countries.

For those Forms customers who are taking a step into the Java world, we have a dedicated site on OTN as well as dedicated developers guides, books and Oracle University courses.

CM: Consider an Oracle shop with a large legacy Oracle Forms application that is running well but in a desupported version of Forms. Should they have any intentions of upgrading their Forms installs and what are the risks if they don’t?

Grant Ronald: Our roadmap for Forms customers is “upgrade and integrate”. So the first point to consider is upgrade. There are, of course, benefits of upgrading but you also have to consider the risk of not upgrading: running your business applications on desupported software that is neither security nor bug patched, or being certified on newer OS or database versions. Are you managing the risk that some piece of this stack may change and destabilise your applications (e.g. a forced O/S upgrade), or are you just hoping that this software tower will hold up with no means of support. It’s your call.

Which takes us to the next point: integration. By web deploying your Forms on the application server, you are positioning yourself on a platform on which you can integrate both your legacy applications, and new services and applications.

By following the “upgrade and integrate” roadmap, you can limit the risk to your business applications while still positioning yourself for your long-term strategic goals.

CM: Consider an Oracle shop with a large amount of SQL and PL/SQL programmers who are cognisant in Forms. Which Oracle development technology should they pick for maintenance and extension of the existing system: Forms, Apex or JDeveloper/ADF?

Grant Ronald: The simplest answer is really to pick the technology/tool that suits you best. If you are extending your existing Forms application it may be that you build new business logic in the database that could be shared between Forms, Java and Apex applications. Or you might decide that you really want to exploit the power of Java and so JDeveloper and ADF would be a natural choice. Many customers are closely aligned with Oracle’s business applications and so the Oracle Fusion technology stack may drive the choice of development tool. I try to discourage customers to think in binary terms when choosing tools. The reality is that you will probably have a mix.

CM: You mention that JDeveloper and ADF would be the natural choice for an Oracle developer. Why?

Grant Ronald: As I mentioned earlier, I look after Oracle Forms and Oracle JDeveloper. One reason for this split in roles is to bring my 4GL Forms experiences into JDeveloper and Oracle ADF. When I first joined the JDeveloper team I was amazed how developers were willing to write lines of code for common actions that I set with the click of a checkbox in Forms. Part of my job is to ensure that the kind of rich features a Forms developer takes for granted are implemented in JDeveloper and Oracle ADF.

JDeveloper and Oracle ADF is also a natural choice because it’s the route our own Applications Division is taking. Our next generation Fusion applications are being built using JDeveloper and ADF. So, as the technology choice for Oracle’s own Fusion Applications, the technology is built with the Forms/Database and PL/SQL developers in mind. No other tool or framework can make this claim.

CM: What skills do you see a Forms developer needing in moving to ADF, and what approach do you suggest to a development team in minimising this learning curve?

Grant Ronald: There is a learning curve in moving to any new technology but with JDeveloper and ADF we are really smoothing out that learning curve and lowering the barrier at which you can start to become productive.

Of course, the bottom line is that you will need some Java knowledge, but how much depends on how far you want to get below the covers and customize the behaviour of the framework.

With an overview of ADF and some basic Java language skills, you can go a long way: building business services, validation, page flow, rich UI interaction, LOVs, graphs – stuff that you couldn’t even consider if you weren’t using ADF.

But if you have made a strategic choice to develop on the Java platform, I’d expect you to still have some members of your team who have a more advanced knowledge of the platform so they can make architectural decisions and set up best practices. We are also working on giving you the learning aids to get up to speed. We have developed a number of Oracle University courses specifically targeted at the Forms audience moving to Java. There are a number of books already published and more in the pipeline that are aimed at opening up the platform. And of course, we have a dedicated focus page on OTN and the essential ADF developer guides for 4GL developers.

CM: Recently you’ve been focusing on SOA technology integration with Forms. Why advantages do you see this combination providing? What challenges do Forms programmers face with integration?

Grant Ronald: The benefits of a service based approach are already well documented: loosely coupled, reusable implementations of business processes gives a more flexible, agile architecture that is better aligned to the business.

Much of the work we are doing with Oracle Forms now is to allow your existing Forms application to hook into the SOA world. The ability to call out to web services and for those services to call back asynchronously is one example.

CM: Grabbing your crystal ball, given your long-term experience in development, where do you see Oracle development in 10 years time?

Grant Ronald: I think the clearest view of the future can be seen in Oracle’s own business applications. Oracle’s Applications Division have upgraded to the most recent version of Forms, while looking to exploit the benefits of a services oriented architecture and a standards based platform. Using JDeveloper and Oracle ADF, they are taking developers from a background including Forms, PL/SQL and Peopletools, and making them productive on the Java platform.

I think this gives the clearest indication of where Oracle development is heading and I think there is a great comfort in knowing that the technology choices you are making are the ones Oracle is betting its business applications on as well.

CM: Finally, moving out of the Oracle arena, what keeps you kicking out of work? I know you play in a band.

Grant Ronald: I play a bit of keys in a band, and that mixed with a few weekends out biking helps balance out all the fun I have at Oracle!

Book review - Processing XML Documents with JDeveloper 11g

noreply@blogger.com (Chris Muir) — Tue, 02 Jun 2009 13:40:00 +0000

I was recently asked to write a book review on Processing XML Documents with JDeveloper 11g by Deepak Vohra, among several other bloggers here, here, here and here.

The thing about book reviews, like movie reviews, is the interpretation by the reviewer is subjective. The trick is for you the review reader to work out does the reviewer have the same tastes and likes as you. If yes that should mean that the book review will be relevant to you potentially giving a recommendation that suits your needs. If no you might miss a really good book or waste a couple of those hard earned squid.

So where do I come from to help you assess if I'm "your" type of reviewer? I'm a both a consultant *and* a trainer. I'm interested in how the story is told as much as what is told. I'm looking for clear examples, a logical A-B-C progression path, and like everyone else something to keep me interested, especially important in the often dreary world of computing. In addition I use XML and JDeveloper in my day to day job, so I should be a prime candidate for this book.

In considering the book's title and what I'd expect to find between the book's covers, I'd want to see a discussion around the XML facilities in JDev 11g vs earlier versions, a comparison of JDev's XML facilities against the other IDEs, then a road-show through the XML features vs the common XML tasks in Java of creating/parsing XML, XML schemas & validation etc. Let's see how the book fairs.

Firstly the Who-is-this-book-for section somewhat incorrectly states readers need to know just XML basics: "what an XML document is, what XSLT is, what XPath is, and what an XML schema is." In the very first chapter it introduces the DOM and SAX parsing methods without any explanation of how they work or the differences, so it actually assumes more knowledge than stated. Anybody with a limited knowledge of XML should definitely look at a book tailor fitted to explaining XML alone before reaching for this book.

The book does receive bonus points for including the latest version of JDeveloper 11g. On average, computing books have short half-lives because the technology they're based on is updated or replaced regularly. As a book purchaser you want your investment to last long as possible without becoming instantly redundant. The fact this book is written against the latest JDev 11g release should help extend that investment, until Oracle does another rewrite of the IDE.

Yet on considering my expectations for the book, it doesn't take the opportunity to discuss JDeveloper in general, nor its XML feature support. This is a shame as it doesn't help to "sell" JDeveloper and its benefits in any direct manner.

But in addressing my expectations again the book takes you through typical stuff you want to do with XML via Java, such as creating and parsing XML, working with XML schemas, XML validation, XPath and so on very much in a cookbook like fashion – here's a recipe now you follow it. I somewhat don't understand the inclusion of chapters on XML to PDF, XML to Excel, and XML Publisher, as the book's title is about processing XML in JDeveloper, those chapters relate to specific XML use cases not a generalised XML requirement. Their exclusion could have made this a concise JDev-XML guide.

If I consider the writing style used, personally from reading around a zillion technical books I tend to lump technical books into 3 styles:

a) the "Head First" series which takes an extreme narrative style
b) the other end which is just reams of code and specifications which isn't a book but rather a printed manual, it typically gives no narrative, just cold hard "this is how you do it" facts
c) and the books that lie in between

For me a good book is one that lies in that nice gray area "c". I want the writer to keep me interested with a narrative style while reading the boring technical bits, information about the pros and cons, some background information, but not bury me in opinions and jokes (and crosswords and word puzzles for that matter).

For me this book falls closer to "b", you can tell it's written by a programmer by its dry clinical dry style. For instance chapter 1 introduces the fact that Oracle XDK 11g provides an API that extends JAXP, but then doesn't discuss what the Oracle XDK 11g is, why Oracle chose to override JAXP, and what benefits you'll get over using the non-standard libraries. So you get a "this is how you do it" style rather than any discussion on the "why", which I think is important for learning. Some readers might be smart enough (I know I'm not ;-) to conclude the "why" without any explicit description, so this book might suit you directly.

If we take the fact the book includes a large amount of code, in particular XML, care by the author and the publisher needs to be taken to present code in a concise way, well laid out code that is documented clearly, because code is central to the book's value. There are numerous examples in the book where code stretches across several pages without explanation, code layout is messy in areas, and given the quantity of code at times it's hard to work out which bit I should be focusing on (a problem that is often magnified by the "over-wordiness" of XML). I've no doubt given the amount of code in the book achieving this consistency is a very hard task, but again it detracts from the quality of the book.

Finally I mentioned that it's important for technical books to present a logical A-B-C progression path in assisting the reader to learn. Given this book's clinical style, where in each chapter it discusses the JDev environment setup, then a bullet point section walk through of the code, and how to run and see the results in the end, it does achieve this goal. Again the "why" is often missing in this book, but you do see the A-B-C progression path which is important.

In summary would I recommend this book? If you're simply looking for a cookbook like style technical book the answer is yes, but (and there is always a but).... for myself I miss the "why" in this book, the part that helps me learn the peripheral issues, so the answer is no.

OTN Article - Taking an Oracle ADF Application from Design to Reality

noreply@blogger.com (Chris Muir) — Thu, 28 May 2009 13:58:00 +0000

I'm happy to announce that a 5 part article Taking an Oracle ADF Application from Design to Reality authored by Penny Cookson and myself has been published on Oracle's Technology Network.

I'd like to thank Penny for her assistance in writing the article, Steve Muench and John Stegeman for their ideas (supplied directly and indirectly), Grant Ronald for his review and Justin Kestelyn's OTN team for their hard work.

Java Developer Journal - JDeveloper - an IDE that moves with the times

noreply@blogger.com (Chris Muir) — Wed, 27 May 2009 04:47:00 +0000

I'm happy to announce that an article of mine has recently been published in the Java Developer Journal, titled "JDeveloper - an IDE that moves with the times". You can pick up the full JDJ magazine here or the online article here.

Thanks to Teri Whitaker and Shay Shmeltzer for their assistance with this article.

JDeveloper next version - new features sneak preview

noreply@blogger.com (Chris Muir) — Tue, 26 May 2009 07:47:00 +0000

Jakub Pawlowski has spotted the beta documentation for the next release of JDev, great work Jakub. Best to check it out now, as the URL indicates this is a beta release and the URL may not be there for long.

As Jakub has pointed out, there's a great new calendar component arriving. I remember asking for something like this a year or so ago, and the Oracle Gods have delivered. Great work :-)

Some other things I spotted from a quick scan:

1) Dashboard component

2) Hierarchy Viewer

3) ADF BC - Integrating Service-Enabled Application Modules

4) Whole new manual Desktop Integration Developer's Guide

5) Manual for potentially a new product Oracle Help (at least I hadn't heard of it before)

...and so on... it's worth a stroll through the documentation to check out new features. I'd appreciate if you find any more, to post them as a comment on this blog post please.

I'm happy to announce...

noreply@blogger.com (Chris Muir) — Sun, 10 May 2009 12:49:00 +0000

I'm happy to announce the arrival of Jessica Muir, a calm and collected little 3.5 kilo girl. Mum and Jessica are doing just fine, while Dad is running a quick "education" campaign with Jessica's 2yr old sister about the merits of little sisters.

Our new arrival spells a few weeks break from blogging, normal services will resume shortly.

JAX-WS: Throwing generic SOAPFaults under WLS 10.3

noreply@blogger.com (Chris Muir) — Wed, 06 May 2009 12:59:00 +0000

(With apologies I accidentally deleted this post. This is a repost).

Typically thanks to the WSDL operations including a <soap:fault> element, when generating JAX-WS 2.1.x endpoints from the WSDL, the JAX-WS engine will also create @WebFault classes to mirror the <soap:fault>. As such the programmer can throw the @WebFault class to cause a SOAP fault to be returned to the caller.

However what if the WSDL operation doesn't include an explicitly defined fault for the operation? How does the programmer throw a fault without a @WebFault class? The simple answer is add it to the WSDL and regenerate, but some of us don't have that luxury, the WSDLs are given to us.

If you're using SOAP 1.1 the following code will allow you throw a generic SOAP fault from your JAX-WS endpoint:


SOAPFactory fac = SOAPFactory.newInstance();
SOAPFault sf = fac.createFault("Your error message", new QName("http://schemas.xmlsoap.org/soap/envelope/", "Client"));
throw new SOAPFaultException(sf);

Note the QName uses the SOAP 1.1 namespace and "Client" fault code.

The SOAP 1.2 equivalent code:

 
SOAPFactory fac = SOAPFactory.newInstance();
SOAPFault sf = fac.createFault("Your error message", new QName("http://www.w3.org/2003/05/soap-envelope", " Receiver"));
throw new SOAPFaultException(sf);

In this example the QName uses the SOAP 1.2 namespace and "Receiver" fault code.

(Later edit – for the record both these mechanisms can also be used in a custom JAX-WS protocol (SOAP handler) or logical handler).

In the SOAP 1.2 case you'll see something like the following SOAP fault returned from the web service call:

 
  
     
        
           
            S:Receiver  
           
           
            Your error message  
           
           
              
               javax.xml.ws.soap.SOAPFaultException: Your error message

Specifically for Oracle's WebLogic Server (WLS) v10.3, we need to make a slight change to the SOAP 1.2 code by supplying the specific SOAP protocol to the SOAPFactory.newInstance call:


SOAPFactory fac = SOAPFactory.newInstance(SOAPConstants.SOAP_1_2_PROTOCOL);
SOAPFault sf = fac.createFault("Your error message", new QName("http://www.w3.org/2003/05/soap-envelope", " Receiver"));
throw new SOAPFaultException(sf);

If you don't do this the web service will return an empty HTTP body (though the HTTP header will include a "500 internal server error"), and you'll see the following Java Stack Trace:


java.lang.RuntimeException: javax.xml.ws.soap.SOAPFaultException: Your error message

6/05/2009 10:18:23 com.sun.xml.internal.messaging.saaj.soap.ver1_1.Fault1_1Impl getFaultSubcodes
SEVERE: SAAJ0303: Operation getFaultSubcodes not supported by SOAP 1.1 
6/05/2009 10:18:23 com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit handle
SEVERE: Not supported in SOAP 1.1
java.lang.UnsupportedOperationException: Not supported in SOAP 1.1
 at com.sun.xml.internal.messaging.saaj.soap.ver1_1.Fault1_1Impl.getFaultSubcodes(Fault1_1Impl.java:220)
 at com.sun.xml.ws.fault.SOAPFaultBuilder.createSOAP12Fault(SOAPFaultBuilder.java:404)
 at com.sun.xml.ws.fault.SOAPFaultBuilder.createSOAPFaultMessage(SOAPFaultBuilder.java:172)
 at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:249)
 at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
 at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
 at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:134)
 at weblogic.wsee.jaxws.HttpServletAdapter$AuthorizedInvoke.run(HttpServletAdapter.java:272)
 at weblogic.wsee.jaxws.HttpServletAdapter.post(HttpServletAdapter.java:185)
 at weblogic.wsee.jaxws.JAXWSServlet.doPost(JAXWSServlet.java:180)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
 at weblogic.wsee.jaxws.JAXWSServlet.service(JAXWSServlet.java:64)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
 at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
 at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
 at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292)
 at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
 at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3498)
 at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
 at weblogic.security.service.SecurityManager.runAs(Unknown Source)
 at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2180)
 at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2086)
 at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1406)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

(I don't usually include the complete stack trace in a blog post, but in this case the error is so obscure, it'll help others with Google searches)

I'm currently unclear on why this occurs under WLS. Having tested the original code on Netbeans 6.5 & Glassfish 2, it doesn't have the same issue. I note WLS 10.3 uses JAX-WS 2.1.3 and Glassfish 2 uses JAX-WS 2.1.4, so it may be a simple fix in the later JAX-WS release.

Thanks very much to Gerard Davison from Oracle UK for his assistance on resolving this one.

JAX-WS: A @SchemaValidation custom handler to alter framework SOAP faults

noreply@blogger.com (Chris Muir) — Tue, 05 May 2009 00:56:00 +0000

A few days ago I blogged about suppressing the SOAP fault detail Java stack trace on WebLogic Server when using the JAX-WS @SchemaValidation annotation for your web services.

One of the problems with the @SchemaValidation annotation is dependent on the error in your incoming SOAP payload, you may get all sorts of potential errors returned in a SOAP fault. In some cases it might be useful or a requirement that a generic SOAP fault message be sent back in this case. How to do this?

As usual I'm documenting my research and solution here for my own purposes, but hopefully helpful to others. Your mileage may vary.

Consider the following JAX-WS endpoint:


@WebService
@SchemaValidation
public class WebServiceClass {

  @WebMethod
  public MyResponse lodgeReport(@WebParam MyRequest request)
    throws GenericSoapFault {
    // do some stuff
  }
}

(I've clipped a lot of the detail from above to focus on the specifics)

Notice the @SchemaValidation annotation. By default this will enforce that the incoming SOAP payload conforms to the XML schema for the operation. For instance an invalid payload may throw the following error:



   
      
         
            S:Receiver
         
         
            org.xml.sax.SAXParseException: cvc-datatype-valid.1.2.1: '?' is not a valid value for 'dateTime'.

Note the reason/text part of the SOAP fault may be virtually any SAXParseException error message depending on the error discovered in the incoming SOAP payload.

We can however override the @SchemaValidation annotation to specify the actual error handler. We change the endpoint code as such:


@WebService
@SchemaValidation(handler = SchemaValidationErrorHandler.class)
public class WebServiceClass {

  @WebMethod
  public MyResponse lodgeReport(@WebParam MyRequest request)
    throws GenericSoapFault {
    // do some stuff
  }
}

Note the handler attribute specifying the SchemaValidationErrorHandler class for the @SchemaValidation annotation. In turn the SchemaValidationErrorHandler is implemented as follows:


import com.sun.xml.ws.developer.ValidationErrorHandler;
import org.xml.sax.SAXParseException;

public class SchemaValidationErrorHandler extends ValidationErrorHandler {

  public void warning(SAXParseException exception) { }

  public void error(SAXParseException exception) {  }

  public void fatalError(SAXParseException exception) { }
}

Any warning, error or fatal error for the @SchemaValidation will now be passed through to the methods above. Remembering our goal to supplement a custom error message for any of the errors above (well, maybe not warning, we'll ignore warnings), we'd like to return our own SOAP fault. Unfortunately we can't do that from the handler, we need to pass the error back to the endpoint method. This is done by using the com.sun.xml.ws.api.message.Packet that is available from the ValidationErrorHandler super class. In essence we can change our handler class as follows:


public class SchemaValidationErrorHandler extends ValidationErrorHandler {

  public static final String WARNING = "SchemaValidationWarning";
  public static final String ERROR = "SchemaValidationError";
  public static final String FATAL_ERROR = "SchemaValidationFatalError";

  public void warning(SAXParseException exception) {
    packet.invocationProperties.put(WARNING, exception);
  }

  public void error(SAXParseException exception) {
    packet.invocationProperties.put(ERROR, exception);
  }

  public void fatalError(SAXParseException exception) {
    packet.invocationProperties.put(FATAL_ERROR, exception);
  }
}

I can't for the life of me find the JavaDoc for the Packet class, but what I believe it does is wrap the overall web service message context, and we can drop properties into the packet to be retrieved elsewhere by our JAX-WS solution , specifically our end point.

Returning to the JAX-WS endpoint we need to inject the web service message context, and then we can retrieve each of the individual errors from the SchemaValidationErrorHandler above:


@WebService
@SchemaValidation(handler = SchemaValidationErrorHandler.class)
public class WebServiceClass {

  @Resource
  WebServiceContext wsContext;

  @WebMethod
  public MyResponse lodgeReport(@WebParam MyRequest request)
    throws GenericSoapFault {
    
    MessageContext messageContext = wsContext.getMessageContext();
    // We'll ignore warnings
    // SAXParseException warningException = (SAXParseException)messageContext.get(SchemaValidationErrorHandler.WARNING);
    SAXParseException errorException = (SAXParseException)messageContext.get(SchemaValidationErrorHandler.ERROR);
    SAXParseException fatalErrorException =       (SAXParseException)messageContext.get(SchemaValidationErrorHandler.FATAL_ERROR);

    String errorMessage = null;

    if (errorException != null)
      errorMessage = errorException.getMessage();
    else if (fatalErrorException != null)
      errorMessage = fatalErrorException.getMessage();


     if (errorMessage != null)
       throw new GenericSoapFault(errorMessage);

     // Otherwise process the request
  }
}

Note the @Resource annotation in the class injecting the web service context, then within our endpoint method fetching the MessageContext from the wsContext, which gives us the ability to retrieve the properties we inserted in the SchemaValidationErrorHandler class.

As per the solution above, instead of just checking if the errorMessage is null and passing that to the GenericSoapFault, you could instead replace the SAXParseException with a more generic error message.

Standalone WLS ADF deployment – Be careful which URL you use

noreply@blogger.com (Chris Muir) — Tue, 28 Apr 2009 02:24:00 +0000

We hit a problem with JDeveloper 11g ADF applications deployed to WebLogic Server 10.3 that's worth sharing.

Under JDev 10.1.3 we could access our remotely deployed ADF applications on OAS through a URL similar to:

http://host:port/context-root/faces/page.jspx

...this is in fact how JDev 10.1.3 ran apps on the integrated OAS/OC4J container.

However on attempting to run a new ADF 11g application on a standalone WebLogic Server, if we used a similar URL as above, then attempted to navigate to any other page via a JSF navigation rule and command control, the original page would show, no navigation would occur, no errors in the logs would be reported.

It's very hard to debug without an error at least somewhere. This left us scratching our heads, and a SR to Oracle Support followed.

Turns out under JDev 11g you cannot include the page file extension in the URL any longer when accessing an ADF application (regardless if it's on an integrated or standalone WLS). You must use:

http://host:port/context-root/faces/page

If I'd carefully looked at how JDev 11g deploys and runs the ADF applications on the integrated WLS I would have realised this because that's what appears in the log window, but I hadn't noticed the subtle change in the URL. It's possibly something that wouldn't catch somebody new to JDev/ADF, but more likely to catch us old hands out with prior 10.1.3 knowledge. You're more likely to hit this problem on a standalone WLS as when running applications within JDev it forms the URL for you for the integrated WLS, but on the standalone WLS you need to work it out for yourself.

Note that the JDev 11g Fusion Guide under section 32.9 notes the URL syntax as:

"http://<host>:port/<context root>/faces/<page>"

....but what it doesn't bother to note is <page> should be the page name without the file extension.

Thanks to the Oracle Support staff and the Oracle JDev development team behind the scenes who discovered my error.

JAX-WS @SchemaValidation: suppressing the SOAP fault detail Java stack trace on WLS

noreply@blogger.com (Chris Muir) — Thu, 23 Apr 2009 03:10:00 +0000

This post gives a solution that has been given in numerous other locations and the solution is even fairly obvious, but I needed a location to record it, so here it is.

Recently Gerard Davison at Oracle UK detailed the JAX-WS @SchemaValidation tag.

The default behaviour of Oracle's WebLogic Server 10.3 on receiving a SOAP payload that doesn't conform to the WSDL/XSDs in a JAX-WS endpoint method with the @SchemaValidation annotation is to throw a SOAP fault.

Under SOAP 1.1 the SOAP fault payload returned to the client includes a faultcode, faultstring, faultactor (optional) and detail (optional) component.

Under SOAP 1.2 the SOAP fault includes a Code, Reason, Node (optional), Role (optional) and Detail (optional) component.

Assuming SOAP v1.2, given the @SchemaValidation annotation and invalid SOAP payload, we may see the following SOAP result from our JAX-WS web service:

(Click the picture to expand it)

As you can see the SOAP 1.2 fault includes the Code, Reason and Detail components. As can also been seen the Detail component includes the full Java stack trace(I've snipped the stack trace for brevity).

It may be undesirable to return the complete Java stack trace in the SOAP fault and you may wish to turn this off. If you look closely at the error message the answer in how to do this is revealed. Effectively we need to configure the WLS server to include the following option on startup:

-Dcom.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace=false

For WLS 10.3 this entry should be included in your startWebLogic.cmd file.

For a standalone WLS this file is found under:

<WLS_HOME>/user_projects/domains/<YOUR_DOMAIN>/bin

For the integrated WLS within JDeveloper 11g it's found under:

<JDEV_HOME>\system\system11.1.1.0.31.51.88\DefaultDomain\bin

Locate the following entry in the startWebLogic.cmd file:

set JAVA_OPTIONS=%SAVE_JAVA_OPTIONS%

..and change it to:

set JAVA_OPTIONS=-Dcom.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace=false %SAVE_JAVA_OPTIONS%

On restarting the WLS server, and reinvoking the web service with an invalid SOAP payload, the SOAP fault will now look like:

ADF Faces RC – displaying user help

noreply@blogger.com (Chris Muir) — Wed, 15 Apr 2009 04:57:00 +0000

ADF Faces RC under JDeveloper 11g supports different mechanisms for displaying runtime help to users linked with an on-screen component. I had a chance to play with this today and (once again) thought I'd document my findings here as I found the Oracle documentation somewhat confusing (or maybe it's just me).

The Oracle documentation that describes how to get this working can be found in section 16.5 Displaying Help for Components of the Oracle JDev 11g Fusion Web Developer's Guide. It's worth noting you should read the entire section 16 Displaying Tips, Messages, and Help as there are a few assumptions in section 16.5 that you've read the earlier parts.

Help types

A subset of the ADF Faces RC components include support for displaying help, through the inclusion of the helpTopicId attribute on the component's tag.

ADF Faces RC provides for 3 different help types for the components that support help:

· Definition – places a question mark icon near the component which when the user hovers the mouse over the component, help text is displayed. The exact location of the question mark icon relative to the component depends on the type of component. Section 16.5 of the Oracle documentation dictates this.

· Instructions – typically displays a note window (that looks like a speech bubble) over the component when the user clicks in the field, where the note window shows the help text. For panel headers and query object components the help text appears inline with the component rather than as a note window.

· External URL – displays a similar question mark icon to the "Definition" help type above, except when the user clicks on the icon (rather than hovers over the icon with the mouse pointer), launches a separate browser window opening an external URL.

Providing Definition or Instructions based help

The setup for providing either Definition or Instructions based help is as follows:

1. Within your ViewController project create a Java class that extends oracle.adf.view.rich.help.ResourceBundleHelpProvider. In the following example I've created the class MyHelpProvider under the package view.help

2. We next need to create the file adf-settings.xml to configure the custom ResoureBundleHelpProvider. This file is meant to go under the ADF META-INF node in the Application Resources options within the Application Navigator:

Unfortunately I can't find an easy way to create this file under this node. The easiest way seems to be to locate the <app_dir>\.adf\META-INF directory under Windows explorer or similar, and manually create the XML file in there. Once done return to JDeveloper and restart it. On JDeveloper reopening you should see the file added as per above.

(The Oracle documentation is incorrect in instructing you to create the adf-settings.xml file under the ViewController's META-INF directory. It should be the <app_dir>\.adf\META-INF directory as specified above).

The contents of the adf-settings.xml file are as follows:

Note the help-provider-class mapping that points to the package.name of our Java class, namely view.help.MyHelpProvider.

The <property>'s tags define the resource properties file that contain our help text to display for each help-enabled component. In this example I've created a file helpFile.properties (the extension is dropped in the adf-settings.xml file) in the view.resources package. We'll look at this next. The property-name as far as I can tell can be anything you want and has no effect elsewher. I'm not entirely sure why it's included; presumably it's possible to have multiple resource files?

3. The contents of helpFile.properties file are as follows:

As you can see in the properties file we have key-value pairs, specifically the help ID and the associated text. Of special note, see that each key is either completed with the word DEFINITION or INSTRUCTIONS. It is this that determines the help type for the component. (Somewhat confusingly INSTRUCTIONS is a plural, and DEFINTION is singular)

4. Finally we need to bind the help key from the properties file to the actual ADF Faces RC component on a web page:

Note for the 2 input text controls above the helpTopicId parameter. Note how these map back to what I had in the properties file minus the DEFINITION or INSTRUCTIONS suffix. Those suffixes are only included in the properties file. As such the properties file determines the behaviour of the help and components in this case.

Providing External URL based help

To configure the external URL help type we return to our custom MyHelpProvider class and override the super getExternalUrl method as follows:

In the 2nd if statement we've added the ability to capture the helpTopicId and return an alternative URL which will be used for the new browser window. As you add more components that require help, you simply add more if statements with associated URLs.

Further functionality

If you wish to configure multiple helper classes the adf-settings.xml file allows you to include a filter via the prefix attribute on the help-provider tag as follows:

In this case only helpTopicIds with the prefix MYHELP_ will be passed to the MyHelpProvider class.

In addition the Oracle documentation specifies how to use a managed bean help file, which is relatively simple, or XLIFF based help files. I don't have any experience with XLIFF files so I'll leave readers to read the Oracle documentation.

Credit

Thanks to user518058 and Frank Nimphius on the JDev OTN Forums for posting about a couple of the implementation issues with the user-help.

JNDI failure for WLS deployed ADF applications

noreply@blogger.com (Chris Muir) — Tue, 31 Mar 2009 08:34:00 +0000

One runtime error I've hit a few times now when setting up an ADF application to use a JNDI Data Source via WebLogic Server (WLS) is the following:

(I'll document this issue here to save myself grief later on and hopefully help a few other people out)

The specific error text:

JNDI failure. Unable to lookup Data Source at context jdbc/appDS
Unable to resolve 'jdbc.appDS'. Resolved 'jdbc'.

Note that the text "jdbc/appDS" or "jdbc.appDS" may differ in your specific case dependent on what you did in the following steps.

The error comes about as I've:

1) Modified my ADF BC Application Module AppModuleLocal configuration to use a JDBC DataSource connection type, specifying a datasource name of jdbc/appDS.

Accessed via Model project -> Application Module right click -> Configurations -> select AppModuleLocal then Edit button -> Application Module tab.

2) On the WebLogic Server I've created a data source as following:

This is accessed via opening your WLS console + logging in -> Domain Structure -> Services -> JDBC -> Data Sources.

First note the AppDataSource that I've created, then the JNDI Name that maps back to that specified in the previous step.

Then note that the Targets entry is empty for my configured data source. Effectively I've created the data source in WLS but forgotten to assign it to any WLS server and in this case is what's causing my problem.

To rectify this I click on the data source name -> Targets tab then assign the data source to each server I'm interested in (in this case just the JDev 11g integrated WLS DefaultServer):

On saving the changes and returning to the Data Sources page you should see:

And the problem should now be resolved.

ADF BC: Using Groovy to fetch sequence numbers Part II

noreply@blogger.com (Chris Muir) — Fri, 20 Mar 2009 02:11:00 +0000

I recently posted ADF BC: Using Groovy to fetch sequence numbers for EO/VO attribute default values. This post showed the power of what you can get away with in the new Groovy expressions of ADF Business Components in JDeveloper 11g.

Though power is good (muhahaha!, um, cough), simple is better.

Steve Muench suggested the following to make retrieving sequence numbers a breeze via the Groovy expression facilities.

Readers will be familiar with the common recommendation for ADF Business Components to create a layer of framework extensions, as per Section 33.2 of the JDeveloper 11g Fusion Guide.

With this in mind we can create the following helper method seqNextVal() to fetch the next value for a named sequence in our custom EntityImpl:

...which we can then make use of in our Groovy expression in the Entity Object attribute's default value field:

Remember to set the Value Type = Expression.

Thanks to Steve for his suggestion.

Advert: AUSOUG-Western Australia: Why You can No Longer Avoid JDeveloper

noreply@blogger.com (Chris Muir) — Tue, 17 Mar 2009 10:58:00 +0000

Oracle are building their Fusion Application suite using JDeveloper and the ADF framework. If we think about how long Oracle Forms has been a core development product for Oracle it seems obvious that this new platform will have similar relevance.

A confirmed JDeveloper cynic, Penny Cookson has finally been bitten by the JDeveloper bug, and like any Oracle geek can be found playing with the new features in her office in the small hours of the morning (CM - really, it's true ;-)

If you're interested in learning why Penny, a long time Apex advocate is now preaching about JDeveloper, and you're located in Perth Western Australia, join us on April 2nd to hear Penny's AUSOUG-WA presentation about JDeveloper 11g. Penny will discuss why you should look at JDeveloper and demonstrate some of the smart and cute new features in JDeveloper 11g.

More details about the event can be found here.

AUSOUG-Western Australia is also looking for more presenters at their monthly meetings. If you're interested in presenting please drop me an email. Email me at chrisSTOPmuirATsagecomputingSTOPcomSTOPau.

ADF BC: Using Groovy to fetch sequence numbers for EO/VO attribute default values

noreply@blogger.com (Chris Muir) — Tue, 10 Mar 2009 04:07:00 +0000

I've recently been fooling around with the new ADF Business Component support for Groovy expressions in JDeveloper 11g, and thought I'd share the following discovery.

(Usual caveat this hasn't yet been tested in a production system, so your mileage may vary)

JDeveloper's ADF BC supports a number of different mechanisms to fetch database sequence numbers for Entity Object & View Object primary key attributes when a new record is created.

One such method is to override the create(AttributeList) method in the Entity Object and include the following Java code:

@Override
public void create(AttributeList attributeList) {
super.create(attributeList);
SequenceImpl seq = new SequenceImpl("LOG_SEQ", getDBTransaction());
Number seqNextval = seq.getSequenceNumber();
setId(seqNextval);
}

This example retrieves the next value from the database's LOG_SEQ sequence and writes it to the local Entity Object's ID attribute via a call to setId().

This minor piece of code can now be replaced with a Groovy expression in JDeveloper 11g's ADF Business Components.

If we open the Entity Object editor, then double click the primary key attribute we're interested in populating with the sequence number, we can now enter the following Groovy expression for the Value field with the Expression radio button selected:

(new oracle.jbo.server.SequenceImpl("LOG_SEQ", (cont)
object.getDBTransaction())). (cont)
getSequenceNumber()

The following picture shows the entry in context of the Edit Attribute dialog:

Note in the expression how we must explicitely name the package + Java class for the SequenceImpl as we don't have a mechanism for importing classes in the simple Groovy expression. In addition for the getDBTransaction() call we need to make reference to the Groovy "object" expression (or is that class? Whatever). "object" passes a copy of the Entity Object class to the Groovy expression evaluator allowing it to call methods of the Entity Object, in this example getDBTransaction(). More information on Groovy expressions can be found in Steve Muench's following blog post.

The advantage of this Groovy approach is one less reason to code in Java in JDeveloper if you feel the desire (though the Java code example from above isn't exactly difficult). The disadvantage of this approach, I can imagine it would be difficult to debug if something went wrong.

In conclusion we can see the power of the new Groovy expressions supported through JDeveloper 11g and ADF Business Components.

Join 180 members of the ADF Enterprise Methodology Group (+ minor name change)

noreply@blogger.com (Chris Muir) — Thu, 05 Mar 2009 07:05:00 +0000

Just a small note for the millions of my readers (hi Mum!) who care about such, that the ADF Methodology group (that's group with a lower g) has been renamed the ADF Enterprise Methodology Group (that's group with an upper G) to better reflect, um, well if you're really interested it's documented here.

(It would be appreciated if Oracle employee's in charge of websites and similar that link to the original group could update any link names please)

For those who'd like to know more about the group, following is a little marketing spin to drag you in:

You can easily tell when a tool has matured to being a productive environment. Software developers move from playing and learning features, to supporting production systems and discussing best practices and development methodologies to ensure the success of their next project.

The ADF Enterprise Methodology Group is such a place for community discussions based around JDeveloper best practices and methodologies for ADF Enterprise development. On a day by day bases ADF "experts" (that's anyone that knows what ADF stands for ;-) chat about high level ADF concepts, beyond the how-do-I-get-it-to-work posts on the OTN JDeveloper Forums.

If you'd like to discuss best practices, steps and processes for a successful ADF project, please join us at:

http://groups.google.com/group/adf-methodology

We look forward to talking to you on the group soon.

JDev IDE: defaulting to the source code editor for web pages

noreply@blogger.com (Chris Muir) — Tue, 03 Mar 2009 01:35:00 +0000

Recently Vivek Kumar posted about Improving Performance in JDeveloper 11g. Among other suggestions his second one caught my eye: "Configure JDeveloper to open jsp/jsff's in source view". This particular suggestion applies not only to JDev 11g, but also JDev 10g (and possibly earlier versions too, none of which I have installed to check). Unfortunately Vivek didn't give details of how to configure this so I thought I'd do it here.

On opening a web page in the IDE, there is a noticable delay while JDev initializes the WYSIWYG design editor. This becomes painful if you want to only make a small code change in the web page's source code. It becomes doubly painful as there is an infrequent bug in JDev 11g build 5188 where the design editor refuses to show the page's contents unless you flick between the source code and design editor views.

As such Vivek's suggestion took my eye and reminded me we can easily change the default behaviour of JDev to open web pages in the source code editor instead, to avoid these minor annoyances.

The option to do this is under the Preferences dialog invoked via the Tools menu, then selecting the File Types node:

As can be seen from the above picture, selecting the Default Editors tab displays all the different file types JDeveloper works with. For standard JSF pages with an extension of .jsp or .jspx, we can select the JSP Source option and switch its Default Editor option from Design to Source as I've done in this example.

One minor caveat to note is JDeveloper does remember for each file what editor type you were last using, so this change only applies to new files.

Advert: JDeveloper 11g training course

noreply@blogger.com (Chris Muir) — Wed, 18 Feb 2009 06:54:00 +0000

I'm very happy to announce the arrival of our 5 day JDeveloper 11g training course in Australia.

At SAGE Computing Services we've updated our JDeveloper 10.1.3 course to include the latest ADF Business Component and ADF Faces Rich Client technologies bundled with JDeveloper 11g, the core technology set behind Oracle's upcoming Fusion Applications.

This training course has been updated in conjunction with Netherland's Fusion Middleware and Oracle specialists AMIS, drawing upon Fusion expertise from both sides of the globe. We're very excited by this relationship, formed by Oracle ACE Directors Lucas Jellema and myself Chris Muir, and much hard work behind the scenes by both AMIS and SAGE staff (my extensive thanks to all involved).

If my Google searches prove correct, we may be the first organisations in the world to provide comprehensive ADF BC/ADF Faces RC JDeveloper 11g training besides Oracle itself, a great achievement in my honest opinion.

Interested in checking out our course?

View the complete course agenda in our course catalogue or visit our training web page for more information.

Also check out SAGE's other latest Oracle 11g training courses in Australia including:

11g New Features for Developers (1 day)
SQL 11g (4 days)
PL/SQL 11g (3 days)
Application Tuning 11g (3 days)
Database Administration 11g (5 days)

... plus all your favourite previous versions and other Oracle products, we have most of them, even Oracle Browser would you believe?!

For further enquiries hit our web site and follow the contact us details. We look forward to hearing from you soon.