Setting a timeout on an Apache CXF webservice call

In this short post, I'll provide the code for setting a timeout on a webservice call. The client has been generated by Apache CXF 2.6.1, and the webservice is accessed by an HTTP call.

Client client = ClientProxy.getClient(yourPortType);

HTTPConduit httpConduit = (HTTPConduit) client.getConduit();

HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setConnectionTimeout(5000);
httpClientPolicy.setReceiveTimeout(5000);

httpConduit.setClient(httpClientPolicy);

You should add this chunk of code before you call the method on yourPortType. The connectionTimeout is how long it may take to connect to the service, the receiveTimeout is how long it may take for the webservice to respond.

Web Accessibility Course

Attention fellow web developers! Google is giving a free online course to improve the accessibility of your website/application. While this might not seem like a big issue, the World Health Organization estimates the number of people with visual impairments to be 285 million. You can save them from a lot of frustration, and offer a far better user experience by following a few guidelines.

Making your site more user friendly to blind or low vision people doesn't have to be 'a pain in the ass'. It should come naturally, with a minimum of extra effort. Google will provide techniques and tools, as well as expert guidance to make the world wide web a slightly better place, one site at a time.

Summer of Technology @Contribute

Just like last year, Contribute organizes a 'Summer of Technology'. The concept is as simple as it is nice: free one-day workshops for everyone interested. If you're a developer, architect, ... or just a technology enthusiast, take a look at the sessions we're organizing, and register for the ones that you're interest in.

You'll find the full overview at the Contribute website: http://www.contribute.be/sot

Topics range from Oracle Forms over BigData/NoQSL to version control. Every tuesday, this summer!

Eclipse cannot run program javaw.exe

Yesterday, I checked out a project from SVN, I ran mvn eclipse:eclipse and imported it into my IDE. So far so good, everything compiled, Maven could run all the tests, all was well.

But then I tried to run a JUnit test in Eclipse. I kept getting a strange error about Eclipse not being able to run javaw.exe in my project-folder. After some Googling, I found that the underlying error that causes this problem, was of an entirely different nature: Windows has a character limit to command line statements. And since Eclipse assembles the classpath itself to pass it on as a launch parameter, the command line character limit got violated.

I now knew what was causing the error, but fixing it didn't seem that simple. I tried to remove all unnecessary libraries (there weren't a lot), but the problem persisted. So I changed to drastic measures: I moved my Maven repository to a folder directly at my C:\ disk. The path was about 30 characters shorter than before, but since Eclipse was adding a whole lot of Maven libraries to my classpath, it made a huge difference.

After that, I could run my JUnit test without any problems. I suppose I'm safe for now, but what will happen when we add even more libraries to the project? It's possible that at a given point, the classpath will be too long for even the shortest possible repo-path you can get. And then what? Switching to Linux could be an option, but during my quest to solve this problem, I also read that IntelliJ has better support for this. So going there could be an option too. Or I could just write/wait for an Eclipse plugin that deals with this problem...

Belgium Liferay User Group

Since the Liferay community is ever growing, there are user groups being developed. One of them, is BeLiUG (Belgium Liferay User Group). If you're a Liferay enthusiast, and are based in Belgium, request your membership today!

Of course, if you're not based in Belgium and want to join a Liferay User Group, search for the one in your country and apply. The idea of User Groups is to get together on a regular basis to talk about certain aspects of the product. It's a great way to meet new people, and to learn a few things about a technology you like.

Custom internationalized error messages in Spring MVC + JSR303

A very common thing to do when building an application, is using JSR303 validation annotations on your domain classes. In a Spring MVC controller, those annotated fields will get validated when calling a ResuestMapping method with an @Valid parameter. You can then easily show the generated errors in your Spring MVC form.

So far so good. Only drawback is that Spring has some default messages. Which are clear, but usually not what you want in your frontend pages. Luckily, there's an easy way to override the defaults with custom messages!

NOTE: This small guide assumes you're using Spring MVC's Internationalization in a correct way, as described here. 

Ok, so overriding the messages. Actually, it's fairly easy. If you want to override each and every message for @NotEmpty, you add 1 entry to your messages.properties file:

NotEmpty = This is the new default message for all NotEmpty annotations

Easy huh? Now if you want to be more specific, you can override the message for (for example) every firstname that is @NotEmpty:

NotEmpty.firstname = This is the new default message for NotEmpty annotations on firstname-fields

This will override the default message for every field named firstname. But you can even be more specific! You can define an error message for a specific field in a specific class. If you have an Employee class, with a firstname field that is annotated with @NotEmpty, you can specify a default message like this:

NotEmpty.employee.firstname = This is the new default message for the NotEmpty annotation on the firstname-field in our Employee class

There's one huge point of attention, though. The pattern of your message has to resemble the SPeL-pattern you'd use to access the field. Usually, the @Valid annotation will be on a command object. That means that in this case, our command object has to be named "employee" on the Model. If, however, you have named your command "command", you'll have to change the message key to this:

NotEmpty.command.firstname = This is the new default.

It's a pitfall, and one you can lose a lot of time with!