Intro

WebSockets is a technology that enables bidirectional communication between web browsers and server side processes. It provides a persistent connection between client & Server, hence enabling ‘push’ abilities where you can push data/notification to browsers from the client. Other client communication options to compare it with would be Ajax
and Comet (basically Ajax with long polling).

Specifications

• WebSockets API – This focuses on the client side programming model.
• WebSockets protocol – Describes the client/server communication in more detail. More complicated and 51 pages long. The WebSockets protocol is still actively being changed.

Browser Support

• Google Chrome 4.0.249.0 and higher (v5 has WebSockets enabled by default)
• Safari 5.0
• FireFox 4.0 beta 1
• IE 9: TBD

There was a suggestion that Apple have decided to disable WebSockets in iOS4 but this is unconfirmed and the speaker suspects Apple will support WebSockets in the future.

Server side support

• Apache Server – not supported yet
• Py WebSocket – designed for use with Apache Server (actually implemented by Google Chromium team.)
• There is also a DJango solution: django-websocket
• Jetty WebSocket Server – Jetty has supported WebSockets since last September. This seems to be a good option.

However, note that there is no standard service side Java API. Each Java container has it’s own API. Therefore it will likely be difficult to write WebSockets for one app server and do a straight port to another app server.

Projects

Other Java Projects supporting WebSockets:

• GlassFish/Grizzly (see a DZone posting on it here)
• jWebSocket
• JBoss Netty (see patch here)
• Caucho Resin

Sean finished by showing the Google Quake demo (also reported here).

The conclusion of the talk was on how to gracefully handle browsers that don’t support WebSockets (e.g. IE8). The main option here seems to be “The Graceful WebSocket“. This resorts back to using AJAX long pulling if WebSockets isn’t supported in the browser.

My Thoughts

WebSockets looks like one of the most interesting technologies that fall under the HTML5 umbrella. If it gets wide browser support (e.g. IE9), and perhaps some standardization on the server side, it could really take off and even potentially over take Ajax. Definitely one to watch…

The talk was given by Chris Bedford, from Build Lackey Labs – “Automating the Monkey Work Out and the Quality In!”. Overall, I thought this was a great talk by Chris. He clearly has a huge amount of experience creating automated tests and integrating them with build tools and he gave a well structured, interesting, well delivered presentation. I have posted a copy of Chris’s slides and I think the video will be posted on the SF JUG site at some point, but I have also posted my notes from the presentation below…

Selenium Overview

Chris started off with an overview of Selenium – a tool for automating tests for web based applications. He then introduced us to the Selenium IDE – a Firefox add-on that allows you to set up tests by recording clicks on a web page, or by manually entering commands. The tests can then be played back as part of your automated test suite.

Creating Selenium Tests

Chris showed us the process by both executing an existing test he had already setup, and by walking us through the creation of a new test, which loaded a page, waited for text to be present, clicked on a link, and confirmed that text was present. The test was a html file, but he showed how to export it as TestNG and JUnit tests (although both exports resulted in kind of ugly java code!)

Possible hiccups with Selenium

One of the things I thought Chris did well was, in addition to pointing out all the many great things about Selenium, he also pointed out some of the slight issues with Selenium that he has encountered during his time using it, such as

• Difficulties getting the initial Open page to work
• Issues with where the test files get saved
• Making sure you have the tests run slow to start with (to avoid timing/loading issues)
• The Selenium IDE may be difficult to get working with IE (Firefox is fine)

Selenium Components

The main Selenium section then finished up with a quick over of the various Selenium Components:

• Selenium IDE
• Selenese Commands
• Selenium RC (Remote Control)

Chris also had a section on the ‘same origin‘ JavaScript policy that Selenium manages to circumvent by using the Selenium RC Server. He managed to explain the issue in simple terms.

Other functional test alternatives

Chris discussed other functional test alternatives by comparing Canoo to Selenium (Canoo is also an automated web app testing framework).

Chris also mentionted Umangite, Chris Richardson’s open source testing framework that makes Selenium tests easier to write. I have used this before, and agree it is worth checking out…

Using Selenium with Build Tools

He then discussed using Maven with Selenium, including using Cargo (e.g. using the cargo maven2 plugin). Cargo is a set of APIs that assists in

• installing web containers, such as Tomcat, JBoss
• booting and shutting them down
• deploying web apps (.wars, .ears)

Chris finished the Selenium & build tools section with a quick run through of using Selenium with Ant.

Continuous Integration

The final section of the presentation was a talk on Continuous Integration (CI). Chris described CI as:

• A dedicated box (see my follow up question below!) that runs regular full builds (including tests) of your software
• Build triggers when any developer checks into SCM
• Team is notified of any issues

And talked about how Selenium can be used with Hudson – a very cool CI tool from Sun. This leads well into next month’s SF JUG talk!

Q&A

Q: Do you have any info on WebDriver merging with Selenium?
A: No, but sounds interesting!

Q: How closely do test writers work with marketing people?
A: Chris suggested checking out the easyb framework, a behavior driven development framework that allows you to write conditions in a very abstract level, using a DSL that marketers can use and understand. He also suggested looking at the fitnesse framework.

Q: I asked Chris via email after the talk what he meant by needing ‘dedicated’ box/server for Continuous Integration.
A: He clarified that by ‘dedicated’, he just meant that the build box should not be a box that you are doing development on, and that there isn’t anything wrong with having a mix of services on one machine. e.g. having a qa box that has the CI server and maybe hosts the bug tracking system as well…

In a future article I would like to discuss validation including the use of custom error messages.

Note that these notes relate to version 2.5.6 of Spring, the latest production code at time of writing, and depend heavily on the corresponding Spring reference docs.

Data Binding

Spring MVC allows the use of command objects (aka form backing objects, model attributes, domain model objects – basically the objects used to transport data between your view and your controller) using just about any type. However, the Servlet API deals with form parameters as Strings. Spring uses a technique called data binding to covert between the String representation and the real underlying type. This enables user input to be bound to the objects you use to process user input. In other words, the values entered by a user in a form can be used to set the property values on a chosen object.
As well as binding the values, Spring includes support for validation and binding result analysis.

The binding functionality is provided by Spring’s org.springframework.validation.DataBinder class.
And when converting a String to some arbitrary type, DataBinders make use of ProperEditors. PropertyEditors are not Spring specific, but rather part of the JavaBeans API.

Using PropertyEditors

Spring heavily uses the concept of PropertyEditors to effect the conversion between an Object and a String.
Spring has a number of built-in PropertyEditors to make life easy (for a complete list, see here).
If you are using a custom type that Spring is unable to convert to and from a String, you will likely receive a lovely error such as this:

org.springframework.web.bind.ServletRequestBindingException: Errors binding onto object ‘dependsOnExoticType’; nested exception is org.springframework.validation.BindException: org.springframework.validation.BeanPropertyBindingResult: 1 errors
Field error in object ‘dependsOnExoticType’ on field ‘type’: rejected value [test]; codes [typeMismatch.dependsOnExoticType.type,typeMismatch.type,typeMismatch.example.ExoticType,typeMismatch]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [dependsOnExoticType.type,type]; arguments []; default message [type]]; default message [Failed to convert property value of type [java.lang.String] to required type [example.ExoticType] for property ‘type’; nested exception is java.lang.IllegalArgumentException: Cannot convert value of type [java.lang.String] to required type [example.ExoticType] for property ‘type’: no matching editors or conversion strategy found]

The solution is to create your own custom editor.

Creating a custom property editor

A custom property editor should be of type java.beans.PropertyEditor. It tells Spring how to convert to a String and back again. As an example, see the ExoticTypeEditor in the Spring reference docs here.

The question is then how to register the custom editor.

Registering your custom editor

There are several ways to ensure you custom editor gets registered.

1) Put Editor in same package

The simplest way (by far!) is to put the Editor in the same package as the class it handles. This is because the standard JavaBeans infrastructure will automatically discover PropertyEditor classes (without you having to register them explicitly) if they are in the same package as the class they handle, and have the same name as that class, with’Editor’ appended;

However, if putting the Editor in the same package as the class it handlers is not possible (If for example, you are using a custom type from a 3rd party library and hence you don’t have access to the source code), try one of the other options below…

2) CustomEditorConfigurer

Another approach to registering a custom PropertyEditor is to use a special bean factory post-processor called CustomEditorConfigurer.
This is the approach used in the spring reference manual for the ‘ExoticType’ example. Again, see
section 5.4.2.1. Registering additional custom PropertyEditors, here.

The CustomEditorConfigurer is used to register the new PropertyEditor with the ApplicationContext, which will then be able to use it as needed.

Gotchas

i) Won’t work with BeanFactory – only ApplicationContext
The PropertyEditors defined in the ‘customEditorConfigurer’ bean will only be automatically used if you are using an ApplicationContext implementation (i.e. will not work for BeanFactory). This is discussed here.
ii) Only works for ApplicationContext created beans – not data binding beans such as form objects
This approach only works for beans created by the ApplicationContext. The PropertyEditors that are registered via CustomEditorConfigurer are NOT available for use in the data binding infrastructure (this is discussed here and here).
I think this should be made more clear in the spring framework ref docs (although, in fairness, it is covered in the CustomEditorConfigure javadocs).

So, if you are using Spring MVC and dealing with form submission, the next option may be better…

3) Explicitly register your editor in initBinder

So, a better approach, as far as form data binding is concerned, is to explicitly register your editor within initBinder() in the relevant Controller. e.g.

@Controller
@RequestMapping("/exoticView.htm")
public class TestController {

	//post and get handling methods etc...

	@InitBinder
	protected void initBinder(HttpServletRequest request, ServletRequestDataBinder binder) {
		binder.registerCustomEditor(ExoticType.class, new ExoticTypeEditor());
	}

}

4) Use a WebBindingInitializer

If you find yourself using the above approach (registering your customer editor in initBinder) in many controllers, and you use a annotation based controller (Spring 2.5+), then you can use a WebBindingInitializer to register global property editors.

To do this, create a class that implements the WebBindingInitializer interface, for example

public class GlobalBindingInitializer implements WebBindingInitializer {

    public void initBinder(WebDataBinder binder, WebRequest request) {
        binder.registerCustomEditor(ExoticType.class, new ExoticTypeEditor());
    }

}

Then update your web application context file to contain:

<bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter">
    <property name="webBindingInitializer">
        <bean class="GlobalBindingInitializer"/>
    </property>
</bean>

I discovered this approach in a posting on StackOverflow about hidden features of Spring . It means you can register an editor once and use it anywhere. This is now my preferred way to register custom property editors.

5) Use PropertyEditorRegistrar

Another mechanism for registering property editors with the Spring container, and the final one in the Spring reference docs, is to create and use a PropertyEditorRegistrar. See section 5.4.2.1.1 here. The docs say that this is a good approach “when you need to use the same set of property editors in several different situations”. I have used this approach successfully in the past, but to be honest, I don’t quite see the benefits beyond the GlobalBindingInitializer approach above and it seems to require a few more steps. (I also saw some confusing debate on exactly what steps are mandatory here)

6) BeanInfo

There is also a BeanInfo mechanism mentioned in the Spring docs which I admit I have never tried – or fully understood.

The demo for our BlipWiki project (which I blogged about here) unfortunately had technical difficulties so our presentation didn’t go so well. One of our 2 browsers couldn’t seem to connect so we didn’t get to show our Wiki updating in real time in the way we would have liked. Still, I think we had a great application at the end of the weekend, and I certainly learned a lot, met a lot of great people, and got to know Google Wave much better. A great weekend…

There are photos and videos from the weekend posted here and a write up in the San Jose Mercury News.

I joined the Blip Wiki team. A Blip is simply a single message within a ‘Wave’ conversation. A Wiki, of course, is a software tool that allows users to easily create, link and collaborate on documents. So, our goal with the ‘Blip Wiki’ project was to bring the incredible collaboration capabilities of Google Wave (real time updates, autocorrect context sensitive spelling etc) to the easy document setup and linkability of a Wiki.
Although Wave can certainly be used to collaboratively create documents as it is, Wave is inherently conversation focused. We wanted Blip Wiki to be inherently Document focused.

To do this however, we needed to use our own instance of a Wave server i.e. use the Google Wave Federation Prototype Server rather than the regular Wave server hosted by Google. We also needed to come up with a new client (something like tiddlywiki) and, most importantly, ensure our client can communicate with the server. Our project won the award for the most ambitious pitch at the start of the weekend!

Federation Prototype Server and example client

We got off to a good start by getting the Wave Prototype Server downloaded, building and running (it runs on top of OpenFire, a real time collaboration server that uses XMPP/Jabber). We then got the demo wave client running and talking to our server. We managed this by late Friday evening.

Client/Server protocol

Next, we created our own demo client and tried to get it interacting with our Wave server. That is when we started running into problems. First, the client/server protocol has not yet been formalized, and there don’t seem to be any definite plans to do that yet either. For example, although this Client Server Protocol White paper describes a protocol and data model, it does not give any details on the format that should be used, or suggestions on how to use it. There is a lengthy discussion in the Wave Protocol Google Group about this. For example, someone suggests that the client server protocol is just protocol buffers ‘over the wire’. But a protobuf is really just a simple data format, and while I assume ‘over the wire’ means RPC, it is all a bit vague.

Submitting changes

The client/server protocol used in the example client (a “toy’ text client) is for “illustrative purposes only”, according to this doc. We couldn’t seem to find much documentation for it, perhaps because it is not supposed to serve as a standardized example. As a result, we found it difficult to reverse engineer. So, we ended up resorting to using the Client example code to marshal our data to and from the server. The example client code in effect became a sort of interface to the server for us. A client side stub, if you will. (We had this running in the web tier servlet layer).

Receiving updates

So, after we had used the Client example code to submit changes (blip updates) to the server, our next hurdle was understanding the data that gets returned. Ideally, we would like a ‘delta’ of the data. That is, after the server has done it Operational Transformation magic, we would just like the latest and greatest version of the data to display on the client. However, this proved difficult to get from the server. Instead all I could seem to get was a non-delimited complete history of the blip. I admit that this was done using pretty hacky code. I am sure there must be another, better way!

So, we ended up taking a similar approach to the example client, and just displaying the latest submissions.

Demo ready – almost…

Right now, we have a working client and server with updates made on one user’s WikiBlip automatically showing up in another users.

It would have been really nice to be able to deploy our local Wave Server to app engine, but apparently this isn’t possible since the OpenFire jars required aren’t on the whitelist of allowed jars.
It also would have been nice to experiment with our local Wave server talking to the real Google Wave server (e.g. to have a regular wave client user be able to interact with a blip wiki), but apparently this is not possible due to authentication issues.

So, we chose a very difficult task for the weekend! But, we have a working version ready to demo and it has been a great weekend all in all.

Thank you’s

A big thank you to

• Sriram and Sreejith, my BlipWiki teammates
• Kevin and Van from the GTUG
• Stephanie, Brian, Fred and all the all Googlers who made the weekend possible and great!

I will post again later with the results of the demo…

I am not too familiar with Wave yet, so this should be a great opportunity to get to know it better, meet a bunch of fellow techs, and hopefully produce something cool by the end of the weekend. Looking forward to it…

Registration is free, so if you are interested you can sign up at here.

The presentation slides can be found here.

I thought Romain was an excellent presenter and did a top job of talking on his area of expertise: Android UI development. He covered the issues you need to be aware of when developing Android UIs if you want them to be performant, best practices and work-arounds for the gotchas, as well as useful tools that can be used for development. Personally, I would have benefited from more of a broad overview and introduction to Android, but that is more a reflection of my own lack of knowledge on Android! Maybe the newly created Android User Group will provide an ‘Intro To’ type talk at some point…

First, Romain covered the Andriod UI terminology (like Canvas, Drawable, Surfaces and Views) before covering the architecture.

The bulk of his talk covered how to make sure you UI runs fast, including:

• Avoiding runtime scaling of background images
• Avoiding invalidating (i.e. redrawing) the entire screen and instead only invalidate the small part of the screen that has actually changed.
• Minimizing the number of views you use (ideally have <100, which seems pretty reasonable for a tiny phone screen!) and talked about some techniques to help with this including using ViewStubs and recycling views
• Avoid allocating memory (apparently the Garbage Collector is slow and pretty much stops the world when it is running)
• Use SoftReferences (objects that only have soft references to them will be kicked out of memory if the Garbage Collector needs more memory) and WeakReferences (which can help to avoid memory leaks) when possible

He also talked about some neat dev and debug tools including Allocation Tracker (which monitors objects being created, memory being allocated etc) and Hierarchy Viewer (which shows you all the devices/windows/views you have how long things are taking to render).
He also mentioned the Android emulator that can be used for testing your apps.

Some of the questions from the Q&A session included:

Q: Will Android support languages other than Java?
A: Romain mentioned that there is a version of Scala and python that work on Android, but currently all APIs are in Java.

Q: Does Flash work on Android?
A: Development is on-going and the Android team is working with Adobe.
(I found more on the web about this topic here: http://gizmodo.com/5300800/flash-for-android-webos-landing-in-october)

Q: Can JavaFX be used on Android?
A: Code might be hard to run on the phone and may not be performant.

Q: Apparently, Sony Ericsson are also building an Android phone. How do you plan to avoid fragmentation as other companies start shipping Android phones?
A: CTS – Compatibility Test Suite
You cant ship a phone as ‘Android’ if it doesn’t pass the CTS.

Other links:
http://d.andriod.com
source.android.com
android.git.kernel.org
code.google.com/p/apps-for-andriod
http://android-developers.blogspot.com/
http://forum.xda-developers.com/

Reza is the author of EJB3 in Action and an accomplished speaker whom I had the chance to meet at The Server Side Symposium earlier this year, so I was particularly interested in his talk.

Reza gave some background on EJBs and how they have been completely reinvented as part of the latest (EJB3) release, including using 100% annotations (no xml) and making heavy use intelligent defaulting. He also talked about how Spring became popular as an alternative to the heavyweigth approach of the older EJB releases and has thrived through its focus on integration with standards like JPA, JMS, JDBC and JAX-WS.

He then went on to his main point, which was that EJB3 and Spring can now be viewed as complimentary, rather than competing, technologies and he went on to back this up by discussing the integration strategies that can be used, including

• Embedding Spring inside a Java EE app server
• Embedding an EJB3 embeddable container withing Tomcat with Spring
• Enabling Spring @Autowired annotation in EJBs via Interceptors
• Using EJB3 natively inside Spring using Spring Pitchfork

Reza finished by reiterating the benefits of using Spring and EJBs together to increase ease of coding and vendor neutrality.

Overall, I thought it was an insightful presentation from Reza. I had studied EJBs back in the v2 release as part of the my SCEA certification, and have used Spring in several projects, but this was the first time I had a chance to hear how they can be used together.

I have made Reza’s presentation notes available here, as well as his demo source code available here. You can also follow him on his web site and blog at: www.rahmannet.net.

The highlights of the second day at TSSJS2009 were a couple of interesting talks from Rod Johnson (Mr Spring) and a talk on Groovy from Scott Davis (Groovy.com).

I have included links to some of my (limited) notes below, which includes links to the actual presentation slides (PDFs) where available.

Keynote: How Spring Fits into the Java Landscape – Rod Johnson

Spring for the advanced developer – Rod Johnson

The Amazing Grrovy Weight Loss Plan – Scott Davis