JDev 11gR1: the most obscure new IDE feature

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

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

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

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

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.