The project I’m currently working on uses a lot of selenium tests to verify the behaviour of the web front end and, I must say, I’ve been quite impressed with it.

Yesterday however after updating my local machine with the latest copy of the project from Clearcase I noticed a lot of failing tests; the worrying (interesting?) thing though was that the failures appeared to be “random”. Tests were passing one run and failing the next, with no changes having being made in the source code and no changes in the initial starting conditions. I was starting to pull my hair out. Curiously the tests ran fine on my colleagues’ and the build machine. My workmate had a look (remember the tests ran fine for him) but he too was getting the random failures on my machine – we were both stumped.

He did unknowingly hit on the problem when he said “Your machine is a lot zippier than mine”. After another hour or so the problem and solution became obvious.

Cause

The Selenium remote control was executing the steps of the test faster than my local app server and Firefox could keep up. In other words it was trying to verify elements on the page before they had rendered.

Solution

To quickly check my hypothesis I ran the Selenium Tests in “slow mode” – all the tests passed!

Now, going forward, I will need to check the test source for all snippets like

browser.click("someButton"); // causes page to load
verifyTrue(browser.isTextPresent("someText"));

and change them to

browser.click("someButton");
browser.waitForPageToLoad("30000");
verifyTrue(browser.isTextPresent("someText"));

Profit!

I was recently working on a JAXB centric app which was required to capture “arbitary” xml. e.g.

<a>
   <b></b>
   <c></c>
   <d>
       <!-- "Unknown" XML here -->
       <maybeE></maybeE>
       <maybeF></maybeF>
       <!-- etc etc -->
   <d/>
</a>

How could I ever capture the contents of if they could be “anything”?

The solution

@XmlRootElement(name="a")
public class A { 

   @XmlElement
   private String b; 

   @XmlElement
   private String c; 

   @XmlAnyElement
   private List<Element> content;
}

What’s going on?

The @XmlAnyElement annotation instructs JAXB to hoover up any elements which aren’t already annotated/associated with a field and store their DOM representation in:

private List content;

You could then do something like:

public String getContentAsString() throws Exception{
    StringBuilder builder = new StringBuilder();
    for (Node node: operations) {
        StringWriter writer = new StringWriter();
        Transformer transformer = TransformerFactory.newInstance().newTransformer();
        transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes");
        transformer.transform(new DOMSource(node), new StreamResult(writer));
        builder.append(writer.toString());
    }
    return builder.toString();
}

To get the nested XML as String.

PROCEDURE clobToXMLType(myClob IN CLOB)

IS
    l_xmlType XMLTYPE;
    -- do something
BEGIN
    l_xmltype := XMLTYPE.createXML(myClob);

EXCEPTION

    WHEN OTHERS THEN
    	RAISE;

END clobToXMLType;

I could of course have used the gui’s to undo all the changes I made but why bother? This is Linux after all!

# cd
# [sudo] rm -rf .gnome .gnome2 .gconf .gconfd .metacity

dpkg --get-selections

To filter the list

dpkg --get-selections | grep XXX

The symptoms were that Eclipse would start but only in “vanilla” mode: only three basic perspectives showing. If like me you installed the Eclipse binary as root into some directory then that’s your problem right there. In order for the other perspectives to become available, when running Eclipse as a non-root user, you need to ensure that the user you are trying to run Eclipse as has read/write/exe permission on the Eclipse directory. I’m sure they don’t need all permissions on all the sub-directories but I wasn’t about to start messing around to find out exactly what was required.

In short – check the permissions on the Eclipse directory!

javascript:void(prompt('',gApplication.getMap().getCenter()));