Nice WADL to HTML conversion

As a folloup to my previous post here is a blog posting about doing something similar for WADL.

Nice WSDL to HTML conversion

Whilst trying to help some one internally I can across this WSDL -> HTML converter (example with a google api). The cool thing is that you can download the XSLT file for use in your own build processes. Useful for automatically generating documentation. (Other tools are available; but many only work on the internal so no good for internal projects.)

I guess combined with the WSDL generation extension features in JAX-WS we could make things a bit prettier for ya basic JAX-WS services. Maybe if I get some time one day....

Some notes on why HATEOAS is good

Just a few notes on the experience of writing a RESTful API for the Sun Cloud component. A bit more commentary here on InfoQ.

Book Review: Processing XML documents with Oracle JDeveloper 11g

I don't normally review stuff on this blog but along with a bunch of other people in the oracle community I received a free copy of this book from Packt Publishing for review so I though why not as they asked nicely. You can find more on this book on the publishers website.

Now first of all will be the first to admit that I am probably not the accepted target audience for this book as it is targeted at beginner and intermediate developers so you have to take my personal perspective with a grain of salt. As a whole the parts of the book that focus on JDeveloper are fine and clear although there are some issues. The examples should use namespaces more as this is more relevant to the real world and in the xml diff chapter (10) totally ignores the functionality added to JDeveloper 11.

The book does given very brief introductions to various XML technologies although a beginner would be better served visiting XML Schools as there examples there provide a better introduction. I think these could have been trimmed from the book and more focus given to the code examples. I did think though that there should have been a section on XQuery if we are going to go down that route.

The main problem in this book are that many of the code samples unnecessarily make use of XDK classes directly. I can understand using the oracle implementation for performance reasons; but for the majority of the examples in this book this is just not necessary to use oracle classes to get this affect. As noted in the book the XML subsystems are plug-able and you only need to place the XDK on the class path for this to happen. For example in the XPath chapter the examples should be using javax.xml.xpath not casting to XMLDocument and using oracle specific APIs. In the XLST section rather than relying on the classloading mechanism to get the right transformer the author uses JXSAXTransformerFactory directly. And finally rather than using the oracle specific XMLPrintDriver to write out XML files the auther should be using the standard TranformerFactory.newTransformer().transform() identity transform to stream pattern. StAX also doesn't get a mention which is a shame in a modern XML Java book.

Even in chapters 7 and 8 which cover some interesting parts of the DOM 3.0 API for load / save and validation the author uses oracle specific classes rather the generic API that would achieve the same result. That being said these chapters did introduce some interesting ideas and concepts I had not come across.

Now there is some interesting stuff at the end about Apache-FO and Berkley XML DB which are worth a glance through. The JAXB section was disappointing as it contain no mention of mapping files, as someone with a fair bit of experience with web services I can tell you that you start to need them as soon as schemas become non-trivial. To be honest I was surprised there was so little mention of web services and SOA. The is a chapter on generating Excel spreadsheets from XML that was of some interest although it was more about writing lots of code to invoke a Excel generating library after parsing XML file than anything innovative.

So in summary if you want a good introduction to how to use the XML tooling in JDeveloper then this is a book to share; but not one you might life to read more than once. The main problem is that I couldn't in good faith give this book to a less experienced member of the team without a hefty health warning about the code issues, even then I would think twice. It is a shame really as I can see where this book was going and perhaps with some more directed editing it could be a valuable introduction.

Injecting Jersey Clients

I had to look this up for someone and it took me a little while so here is a link to a Paul Sandoz post about injecting Jersey API client. So this allow you to inject a client for a particular resource. Paul get bonus points for defaulting to the asynchronous form, in my opinion this should be the default for all web service clients....

TS-4993 Dealing with Asynchronicity in Java™ Technology-Based Web Services

Looks like we have a 10:50 slot on the thursday morning in room 134. This is the same location as last year with a capacity of around 1k people. Just need to finish writing the presentation and unpack my new laptop.

Going to be flying in at around 2pm Monday afternoon and taking the BART into town and my flight back out is on friday at 7pm. Staying at the Nikko which was nice if a bit pokey last year. Will take a look into making arrangement to meet up know my travel is schedule is being nailed down.

Generating the inferred deployment descriptors from annotations

The problem with annotation it that it is not possible to easily understand what is in a .jar/.war/.ear file. There is a little tool in weblogic appmerge that will generate the equivalent deployment descriptors. You simply use the -writeInferredDescriptors parameter.

java weblogic.appmerge -writeInferredDescriptors -output output.war input.war

Have to admit not played with it yet as I just picked this from an internal mailing list; but it seems like a good tip for corner cases.

Playing with Hudson for running UI tests

I have a whole bunch of UI automation tests that for one reason of another I never gotten around to running them automatically. I had planned to include them in our short regression tests sequence; but they are just not stable enough at the moment. The problem with testing UI in a complicated environment such as JDeveloper as it only take a minor change by someone else to derail your tests. So I wanted an environment I could run them locally in.

I decided to use Hudson to drive the tests after being impressed by it at a presentation at JavaOne last year. I don't have to worry about building the product, only testing the results of the build system. It is very easy to set up, just download the war and either deploy it to a container or just run it from the command line and its starts its own server.

Now while Hudson has lots of nice support for various source control systems it of course doesn't support Oracle's in-house ADE source control system. Also I was kinda worried that since as control our build with make that it would be hard to integrate. I shouldn't have worried as Hudson has some really nice scripting support which makes integration to any SCM system really quite easy. Perhaps I will write a proper integration one day; but not really necessary for what I need to do day to day.

Anyhow a job can be made up of multiple steps, be they script, ant or maven. Here is a fragment of a job I set up to work out what the latest labels are of each of our current development branches. This might seem like an odd thing to do; but you can trigger hudson jobs off changes in a given URL if you install the right plugin - strangely there isn't one that will trigger of a script.

There are loads of plugins and they are easily installed using the hudson plugin manager ("/pluginManager"), just make sure that you pass in the proxy options at the command line if they are not set up in your environment so it can contact the home server. The Xvnc, Emma and URL Change Trigger plugins are the most important as far I am concerned.

Hudson can run multiple jobs concurrently; but for the purposes of running tests in JDeveloper I only want one running at a time as it means I can rely on default ports on all of my tests. So I reduced the number of executors to 1 on the configuration page ("/configure"). It did have to restart the server to get this to take effect though.

As mentioned before I am using the URL trigger to cause new jobs to run, you can configure this on your job configuration page ("/job/%job_name%/configure").

At the bottom of this page you can also configure how the results of the build steps are processed. In this case capturing junit and emma results. I also want to archive the results of the automation tests, we take a screen grab at the end of each test failure and capture a log of all http traffic. This all gets collected up for each test.

For each job you get a nice overview of test results and coverage, not particular proud of the test coverage values here but it is something I am working on...

Obviously with UI tests you need a display per test run, now with only run executor this isn't so much of a problem; but if you wanted to run multiple tests on the same machine then you should make use of the Xvnc plugin and turn it on for the relevant tests. This create a new vncserver for each job and configure the DISPLAY environment variable correctly. One important thing to consider is to make sure you are running the tests in the same environment as your users. VNC default to running tvm; but for a higher level test tool such as Abbot to work properly you need to run a proper window manager. So I edit my ~/.vnc/xstartup as follows to run gnome, note the "--sm-disable" mean you can run multiple instances concurrently:

#!/bin/sh
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &

gnome-session --choose-session=VNC  --sm-disable &

The other thing to consider is that the default display dimensions for xvnc is too small to run big complex Swing application. You can control the command line options on the hudson top level configuration page. It would be nice to be able to configure this for each job.

I guess the reason why I like this system so much is that it was easy to set up and you got a lot for the time you have invested. This are load more features, particularly in the area of notification with everything from email to rss to teddy bear lamps. The ability of Hudson to bring a machine in to the build pool by just running a WebStart application is also intriguing and something I am going to look at as I pull a windows machine into the build pool when my desktop become avaliable.

Google AppEngine to support Java?

This is pretty cool, finding somewhere to host lightweight java applications can be a pain. I will be interesting to see if I can deploy to this directly from JDeveloper so signed up to see if I can get on the preview list. Looks like it will support Servlet so -WS and -RS services should work in theory.

Update: Google also have a Eclipse plugin out to make this all a bit easier.

Another way to write out an XML document in Java

This comes from the "you learn something everyday" department as I am currently reviewing a book on XML and JDeveloper. Now Java has some perfectly good APIs to load XML documents; but nothing standard to write them out again. Mostly you either end up casting to a particular implementation class or using the XLST with an identity transformer.

TransformerFactory tFactory =
    TransformerFactory.newInstance();
Transformer identityTransformer = tFactory.newTransformer();
identityTransformer.transform(
  new DOMSource(document),
  new StreamResult(...));

It turns out that in version 3.0 of DOM they added support for APIs to load and save XML documents. They do suffer from the non-Java weirdness of all the DOM apis; but you can use then to write out an XML document:

import java.io.FileWriter;

import java.io.IOException;

import org.w3c.dom.DOMImplementation;
import org.w3c.dom.Document;
import org.w3c.dom.bootstrap.DOMImplementationRegistry;
import org.w3c.dom.ls.DOMImplementationLS;
import org.w3c.dom.ls.LSOutput;
import org.w3c.dom.ls.LSSerializer;


DOMImplementation impl = DOMImplementationRegistry.newInstance()
    .getDOMImplementation("Core 3.0");
DOMImplementationLS feature = (DOMImplementationLS)impl.getFeature("LS", "3.0");

Document doc = impl.createDocument("http://www.example.com", "fred", null);

LSOutput output = feature.createLSOutput();
output.setCharacterStream(
    new FileWriter("/tmp/output.xml"));
LSSerializer serializer = feature.createLSSerializer();
serializer.write(
    doc, output);

Unfortunately I still think that the XLST code is more compact. You might consider the DOM version if you want to be more obvious in your intent.