"Wait, Don't Delay" or how to test complex async Java GUIs

I have been working with abbot and costello for some time now and people tend to have one of two problems getting there scripts to run reliably: the first is not being able to find a component again; and the second is the real time nature of most complex swing UIs.

The first issue can usually be solved by ensuring the that program is accessible and that use of the "name" property where required. Things do get more complicated with nested component; but they can generally be solved with a little bit of common sense.

The second issue is the real topic of this post and it sometimes takes quite a while to change around the mindset required to create tests that will run reliably on a range of platforms and systems.

Take for example an wizard that needs to query a database between pages. This means that the required components might not be enabled instantly after the user action. Now a naive user might try to include a "delay" step because they know how long the action might take; but they will find that eventually the test will fail on one platform or another. They might also try to use the waitForIdle action which is a better guess; but unfortunately not reliable and it might never return in the case of a dialog with an ongoing animation.

In all cases where delays and waits have been used in our tests we have seen then resulting in unstable test suites. The only thing I can think that delay should be used for in day to day tests is using it to ensure a piece of functionality doesn't take too long to run. Even then it will be hard to pick a value that will work on all platforms being tested upon.

Lets look at a few ideas on how you can detect whether the task has completed.

The first and most important thing you can look at is obvious UI changes that signal that the asynchronous task as finished. This might be as simple as waiting for a component to be showing using "Insert"->"Wait For"->"Component Showing". Or in the case where the UI component is always displayed you can use an assert step to ensure that a given component is enabled. In Costello this is done by selecting the "References" tab, then go to the "Properties" tab and find the "enabled" property, hold down Control and use the button that appears to insert a "Wait For" step.

The one exception to this are progress dialogs which are generally not a reliably way of tracking a task. If a progress dialog is implemented properly they might never show if the task is really quite quick.

You can also monitor lists and trees for the addition of new nodes. In costello you only need to add a selectRow step for a tree and code being the scenes will wait until that node path becomes available. (I did some of the work for this). You do find that when you have some experience with costello that you instinctively select elements in list and tree because they provide you will a cheap way to test the current state of the model.

If you are working in a product such as an IDE then you will find that many asynchronous tasks write to a log window of some kind. The example of this in JDeveloper is when we try to start and embedded oc4j instance and we have to monitor the log window to know when it has finished starting. To deal with this we use the "Call" step to invoke a static java method that does the work for us. We might also have achieved the same results with an "Expression" step; but they can be harder debug.

If the worst comes to the worst then you do end up having to provide some kind of behind the scenes API. In the work I have been doing on JDeveloper it proved to be easier to invoke the build system programatically using an Expression step rather than the UI directly. You can also use "Call" or "Expression" steps to query the state of UI components that you don't have tester for, although in the long term you are much better or writing the testers in the first place. An example I currently have on my queue waiting is a custom tester for the "gutter" in the code editor in JDeveloper. Without that it is very hard to work out when "Audit" has finished applying its rules in order to invoke a "Quick Fix". Currently a test is this area is using a very long delay which I am less than pleased with; but I hope to remove this soon.

Finally we have implemented a kind of "internal" log window using Logger for those cases where we can't think of something more creative. This provide a way for actions to say "I am finished" and for abbot to be able to pick this up. In general this is only for use as a sticking plaster until we can put the right tester in place.

Configuring the HTTP Analyzer to record HTTPS traffic

One of the cool new feature we added to the HTTP Analyzer in 11 is the ability to monitor https traffic. This gives you the ability to see all of the crossing traffic in plain text. The configuration for this though is a mite complicated and didn't make it into the documentation for the Technology Preview so I thought that I should write it up here. To make things simple I am just going to look at try to sniff my password from amazon.co.uk; but the same principles apply when working with other HTTP traffic such as SOAP messages.

The first thing you need to do is to use the keytool command to create a server side key. For various security and legal reasons we can't ship a default keystore with the product; but it is fairly easily to create one yourself:

keytool -genkey -alias oracle-server -dname "CN=Gerard Davison, OU=HTTPAnalyzer O=Oracle L=Reading, S=Berkshire, C=UK" -keyalg RSA -keypass welcome -storepass welcome -keystore server.keystore

You then need to configure the HTTP Analyzer, bring up the preferences dialog and set this keystore for both the client and the server. You can of course use two separate keystores if you wish. This is more likely to be useful when working with web services rather than standard web traffic.

In this example I am going to look at using the HTTP Analyzer to look at traffic going to amazon.co.uk. To do this I need to configure my web browser to use the analyzer as its proxy. This by default will be localhost with port 8099.

For the moment, although this is something I am working on, you also need to manually import any certificates for website you are going to visit. Some ideas on how your might go about this are in my previous blog entry on this topic. The snippet of java code appears to be the most reliable option. Update: Or you can use the root certificate keystore that comes with java with a workaround. He have made this much easier in more recent internal builds of JDeveloper.

Now start the HTTP Analyzer and try to log into www.amazon.co.uk using this proxy configuration. You will see a bunch of paranoid messages complaining about how the certificate is not right. This is normal and your should just accept the certificate for the session. (But it is a reminder of why you should never ignore these dialogs in the real world)

If you continue to log in the you should see that there is a bunch of requests, one of these will contain your username and password in plain text. (I am not going to show you a screen grab of this). You will also notice a whole bunch of error that relate to fetching images. This is because you need to import a certificate for each server you are talking to. In the case of amazon.co.uk images are served from "https://images-eu.ssl-images-amazon.com".

Being able to watch traffic in this way is very valuable tool when debugging interactions. AJAX services are really quite interesting to watch in this way. You can also record, replay and mock requests as you would un-encrypted traffic.

Have-A-Job Junior Test Engineer. Reading, UK

We have an opening for a junior test engineer working on Oracle JDeveloper in the Reading, UK who has an interest in Java and a desire to learn new things. The successful candidate will gain experience in testing a range of JDeveloper components both manually and using automated testing tools. They will also have the benefit of being co-located with the development team and be able to work closely with them on a day to day basis.

We have a lovely office overlooking the Thames which is currently in the process of flooding. Thankfully the lovely riverside and nature reserve provide a great flood plain so the office stays dry. We have a great benefits package including the ability to buy up to 35 days leave a year, not including bank holidays.

If you are interested, drop me a comment and I will put you in touch with the right people.

Setting a watchpoint to monitor the access of a field

Some times you really need to track how a field on a class is used and many a time I am working with somebody else's code and find there are not handy accessors to breakpoint. This might be down to poor code encapsulation, or in the case I came across today I just wanted to know who was using the value in given constant. Find usages would give me the static view; but I wanted to find out when this instance was being used at run-time to narrow my search even more.

Now by JDeveloper lets you set a "watchpoint" on a field that will by default break each and every time that the field is modified. I didn't occur to me until today that it would also allow me to monitor the access of a given field, at least until I was debugging a complex case and thought wouldn't it be nice if..... well it turns out that you simply have to open the breakpoints tab edit the breakpoint:

This will not of course work for scalar or String static final types where the compiler is free to copy the actual value between classes. In that case the debugger will not be able to detect a "read". But in this afternoons debugging session it was a real life saver.

Refurbishing your RoboMow Powerpack

So I made the foolish mistake of leaving my already old and decrepit battery pack in the shed over winter and a few very cold nights appear to have done for its ability to hold any charge. I decided that it was time to replace the battery pack and get myself an external charger so the little thing doesn't need to sit in the kitchen to feed. (I have no power outside the house)

A quick look at the uk distributor suggested that perhaps UKP140 for the battery pack and UKP99 for the quick charger was a mite expensive. Time for a little bit of DIY I think. A bit of applied pressure later and I had the top off the battery pack.

It turns out my pack was made up of two Yacel Y17-12 lead gel batteries. These are no longer made but the nice chaps at Yuasa suggested the replacement model NP17-12. In the end I went with NPC17-12 which is designed for cyclic applications such as the lawn mowers and golf buggies. (Notice the extra C) In the end I picked up a pair from BatteryMasters for UKP 68. You need two 12v cells rather then one fat 24v otherwise they wont fit in the packaging unless you are willing to do some more serious modifications to the holder. Depending on how your battery pack in configured you might also need to pick up some crimps as I need to convert from spades to bolts.

Finally while I was at the shop I picked up a charger; but in retrospect I should have gone with the 4amp version which is now 1 UKP less. Still it charges the entire battery overnight which is much better that the standard 22 hours charge time for the standard power adapter. You don't need any special connector, just use the supplied bulldog clips on the big bits of brass on the back. The red one should go to the slider nearest to the fuse. If you get it wrong the LEDs on the charger should flash. No more mower in the kitchen.

I would think that doing the battery upgrade should be doable by anybody who can wire a plug or do simple car maintenance. Just make sure you keep track of polarities when you take the old batteries out and put in the new. As with anything you read on the web though you do this at your own risk etc. etc. results might vary, you might well cause your robomow to burst into flames.

140UKP saving for a little bit of web searching, well worth it. Battery now lasts far longer than it takes to mow the lawn which is better than when I bought the thing refurbished to begin with. Oh and don't leave your battery out in the frosts!

Paper Accepted for UKOUG'07

Looks like I will be presenting at UKOUG this year, my paper titled "Testing and Debugging SOA and Web Service Applications" has been accepted for the afternoon of the 5th of December. Better get my thinking cap on then.

Q: How do I get a remote server's SSL Cert?

A: Not 100% securely over the internet, but there are a few options

So you have to work with a web service over SSL? In order to get this to work you are going to need a certificate to import into your local key store using the keytool command.

The problem is that communication over the internet can be very easily intercepted so ideally you would receive the certificate in person from the provider preferably with the providers parents and partner there to verify the authenticity of the certificate.

Having said that if you are not entirely paranoid you can normally rely on a certificate that is signed by a root authority. Your web browser will do a reasonable job of checking this and just accepting the certificate that the server gives out is likely to be secure enough for most low key operations. You would probably want to be more paranoid if you are exchanging millions of pounds.

The question comes as to how do I get hold of this in a handy format that I can then pass into the keytool? Well the first and easiest way is to ask your web browser although sadly this trick only works for IE7. So connect to the endpoint you are going to work with or just request the WSDL over SSL. Then click on the padlock icon in the url status bar and view the certificate. Then travel to the "Details" page and voila there is a "Copy To File..." button which invokes a wizard to generate a .CER file that keytool with understand.

So how do you do the same trick from Java? Well it is easy enough to get a list of server side certificates using java and write the first one directly into the key store:

 public static void main(String[] args)
    throws Exception
  {
    assert args.length == 3 : "Should have three parameters keystore, password, site";
    File keystoreFile = new File(args[0]);
    assert keystoreFile.exists();
    char[] password = args[1].toCharArray();
    URL url = new URL(args[2]);

    // Load the keystore
    //
    
    KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
    keyStore.load(
      new BufferedInputStream(new FileInputStream(keystoreFile)),
      password);    
  
    // Create a connection
    //

    HttpsURLConnection con = (HttpsURLConnection) url.openConnection();
    con.connect();
    Certificate certs[] = con.getServerCertificates();
    
    // Get the first certificate
    //
    
    Certificate firstCert = certs[0];
    
    
    keyStore.setCertificateEntry(
      url.getHost(), firstCert);
      
    // Store the keystore
    //
      
    keyStore.store(
      new BufferedOutputStream(
        new FileOutputStream(keystoreFile)), password);
    
  }

Again this is a way of getting a certificate is not 100% secure; but might well do for a bit of development. Also it is probably the only choice when dealing with entities such as google or amazon.

For more fun and games with HTTPS check out Tug's Blog on the topic of configuring HTTPS in oc4j and on the client side.

Q: Why won't my JDeveloper JAX-WS web service deploy to glassfish?

A: Not so standard standards

We have a few reports of customers building JAX-WS web services in JDeveloper 11 Technology Preview; but finding that they get some strange errors when trying to deploy these services to glassfish. (Also Tomcat which I haven't had time to play with; but I suspect that they both have the same root cause)

To investigate this I downloaded the latest beta of glassfish version 2 to try to work out what is going on. This prove to be really quite easy to do using the quick start guide. As detailed in the guide I dropped my simple example web service in the auto deploy directory and was rewarded with a pleasing _deployed response file.

Right I thought, lets use the web service. So I went to the management console to see if they have a tester like OC4J. Indeed they did with a handy page listing all deployed web services; but this is where things started to fall apart. Any attempt to test the service or view the WSDL would be met with a 404 response.

It turns out that if I had looked in the server.log file I would have found the following message:

[#|2007-07-06T11:07:03.891-0400|SEVERE|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=19;_ThreadName=httpWorkerThread-4848-1;_RequestID=e309ad42-9897-4fcd-97cf-e1352c5766df;|WebModule[/WebServices]PWC1396:
Servlet /WebServices threw load() exception
java.lang.ClassCastException: org.kingsfleet.MathService cannot be cast to
javax.servlet.Servlet
       at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1132)
       at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1007)
       at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4800)
       at org.apache.catalina.core.StandardContext.start(StandardContext.java:5188)
       at com.sun.enterprise.web.WebModule.start(WebModule.java:324)

This relates to the servlet-class element in the web.xml that we, JDeveloper, generates when we create the service for the first time. This is a quick way to specify how the endpoint maps to a URL. Here is a simple example:

<?xml version = '1.0' encoding = 'US-ASCII'?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://
java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5" 
xmlns="http://java.sun.com/xml/ns/javaee">
    <description>Empty web.xml file for Web Application</description>
    <servlet>
        <servlet-name>MathServicePort</servlet-name>
        <servlet-class>org.kingsfleet.MathService</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>MathServicePort</servlet-name>
        <url-pattern>/mathserviceport</url-pattern>
    </servlet-mapping>
    <session-config>
        <session-timeout>35</session-timeout>
    </session-config>
    <mime-mapping>
        <extension>html</extension>
        <mime-type>text/html</mime-type>
    </mime-mapping>
    <mime-mapping>
        <extension>txt</extension>
        <mime-type>text/plain</mime-type>
    </mime-mapping>
</web-app>

Now it may not make sense to put a class that doesn't implement servlet in this place; but that is how the people who wrote JSR 109 decided it should work. I have to say that it is a nice clean and apparently platform non-specific way of working.

If you remove the servlet mappings or indeed the web.xml from the war file (Okay hands up; you can't create a war file without a web.xml in the technology preview logged as bug 6195725) then this web service will deploy, but at a slightly different URL to the one you actually wanted. To take control over the endpoint url then you will need to create sun-jaws.xml and modify web example as in this tutorial. This is less than optimal because it contains platform-specific implementation classes that might not be portable across different app servers.

I have raised a bug to track this issue but the glassfish people don't appear to be fussed about fixing this problem even though it appears to break the CTS compliance tests. They do seem to be fixing the admin console so that it won't show a web service that has failed to deploy which at least will reduce the level of confusion just a little bit.

Hopefully one day we will get WORA for web services; but it looks like we are not quite there yet.

Understanding Rules in the HTTP Monitor in JDeveloper 11

One of the problems with releasing technology early is that sometimes the documentation has trouble keeping up. This appears to have been a particular issue with the new HTTP Analyzer which as I have talked about previously has introduced the concept of Rules. Unfortunately the on-line help we shipped with the technology preview was not updated to describe the new rules. So I am going to give a quick little summary of the different types here:

Rule Name	Description
Tape	This rules allows you to intercept one or more URLs and response with pre-canned messages taken from a WSI-Log file. This is used to create effect in my mock paypal demo I showed before. Of course this can be useful for any HTTP traffic.
Forward	This rule will intercept all URL matched by the filter and forward the request on to a single URL. Useful for testing or perhaps for replacing your iPhone OS.
URL Substitution	This rule was envisioned to allow the user to re-host services by replacing parts of URL ranges. For example replacing the machine name is particularly useful when moving between the embedded and external oc4js.
Pass Through	This is the default rule and for the given range of URL process the request normally through the normal proxy settings. This is generally going to be the last rule in the list with a blank filter catch all that remaining messages.

One important thing to remember with rules is that they are processed from top to bottom and that a blank URL filter will match anything. Unfortunately the controls for adding Rules in the technology preview will tend to add the rules at the end of the list. This will put them after the default pass through rule which by default has a blank filter and therefore will match everything.

We have received some user feedback that the rules are hard to get right, So to that end in the nightly builds we have been playing with an inline filter tester which may or may not make it to production. I would be interested to get feedback on this:

This will also show you when the filter is invalid. Also, unlike the developer preview, we now correctly validate the rule panel and wont let you leave the dialog until they make some kind of sense.

Right hopefully that is enough to be going on with. We are quite proud of the HTTP Analyzer in JDeveloper and it compares very well with the functionality of other products. (For example the equivalent tool in Eclipse WTP or NetBeans) It can be applied to anything that makes use of the HTTP protocol so can be used to debug anything from

Using "Object Preferences" in JDeveloper 11's debugger to shed light on complex types

If you have programmed in Java for a long time you will probably have ended up in a debugger session with an exception class that either some other person has failed to log or just never get traced out before and another exception is thrown. Now you could just modify the code to put in a printStackTrace; but these can be forgotten which is a real pain when they end up in the production code. I ended up wondering if it was possible to get JDeveloper's debugger to display a little bit more information. Turns out you can.

What you need to do is to set up the "Object Preferences..." for the given type. The easiest way of doing this is to right click on a field in the debugger's data window. By default the combo box will display the settings for the "current" exception; but we want to make this change work for all exceptions so drop this down and then select "Throwable".

Now in the "What to show..." section select the expression check box and add the string "getStackTrace()". Note it has to use the method and not the field as this information is fetched lazily. When you have finished the dialog should look something like this:

Right so you should now see all the stack trace elements appearing under the exception node, the thing is that this doesn't really give you any useful information. To do this you need to make sure that the preferences for StackTraceElement are correct. If you take a look at the next screen grab you will see that I have set the "What to display..." section to use toString(): You should now see something like the following the debugger data window This was kind of promising so I decided to take a look at whether I could improve the debugger information displayed when working with DOM elements. You might find, that specially when working with Oracle's XDK, that the information provided to you in the debugger is less than usefull. You cannot easily for example examine a list of child nodes. This proved to be a little bit harder to display in the debugger as you have to get the debugger to understand the class "org.w3c.dom.NodeList". Turns out that you can happily call static method on other classes. I happened to have a method that converts a NodeList into an array of Node instance that looked like this:

 public static Node[] convert (NodeList list)
 {
   Node nodes[] = new Node[list.getLength()];
   for (int counter = 0; counter < list.getLength(); counter++)     
   {      
      nodes[counter] = list.item(counter);    
   }         
   return nodes;  
 } 

And it turned out to be a simple matter to plug this into the debugger: And here are the results shown in the data window: You could of course take this further an change the convert method so that it returns a structure with more information in it, such as what is the parent of the current element. Or indeed add methods to your objects to provide this information at debug time.

So this all sounds like fun, so what is the downside? Well it does make the debugger run a little bit slowly; but otherwise it does seem to be a win for programmer productivity.

Note this is a retread of a previous blog posting; but I think it makes sense to republish it as there is a now a public release to try this with.