Author Archive

AngularJS: A checkbox with radio button behavior

Did you ever needed to have a group of option in which just one item could be selected, but the user did need to have the option to deselect any chosen option in HTML?

It can’t be done just by HTML checkboxes or radio buttons and the user experience of a select with options isn’t sufficient.

We did have to provide such a solution in a recent project.

Read more…

Mock liferay services in unit tests for 6.1.1

Using mock Liferay 6.1.1 services in a unit test.

When you are developing components, which interact with Liferay services, you will want / need to use mocks for those services.
In previous versions of Liferay the best strategy for this was to use the LocalServiceUtils in your production code and provide the mocks by setting that mockLocalService on an instance of the LocalServiceUtil.

For instance: To use a mocked GroupLocalService you needed to do the following in your test setup:

GroupLocalServiceUtil groupLocalServiceUtil = new GroupLocalServiceUtil();

Read more…

Categories: iPROFS, Liferay Tags: , ,

Bye bye XMLGregorianCalendar (part 2)

Change generated java classes with an XJC plugin.

In the previous post on ‘Bye bye XMLGregorianCalendar‘ I wrote about how you can influence the (un)marshalling of xml to java objects by adding an XmlAdapter to the classpath and an XmlJavaTypeAdapter annotation to a field in the java class. This technique works fine when you are actually writing the java classes your self, but: We don’t do that very often.  One of the main features of XML is that it can be validated against a schema, a contact which defines the valid options and structures with the XML. Most of the times, when we work with XML, there is a schema availabe, either as an standard defined for an industry / product or as part of the contract of a webservice. We can leverage the XSD (XML Schema Definition) to generate Java objects, which represent the elements in XML.

Read more…

Categories: Java Tags: , , , , ,

Patching open-source java software with Maven

16/04/2012 1 comment

As soon as you start using third party libraries in your project, you also introduce all the bugs in those libraries into your project.

There are various ways to handle these kinds of situations:

  • Sometimes you won’t even notice the bugs being present, when you don’t use that section of the library.
  • When you do notice a bug, you can upgrade to newer version of the library in which the bug was already fixed.
  • You might create a work-around in your code.
  • Or you could patch the third-party library.

Sometimes the patch already is present in the trunk of the project, but no newer release is made yet. Encouraging a release-early, release-ofter strategy sometimes work to get a stable release without the bug being present, but it’s good to have alternatives. Most likely you aren’t a committer on the project of the library, so you become dependend on other developers, which could create problems for your deadlines.

This procedure in this post will describe a way to create a stable patched released version of the third party library in your own software repository.

In this post I will use the recaptcha4j library as the example of the software to patch. The only available released version of that library is net.tanesha.recaptcha4j:recaptcha4j:0.0.7. The code in this library still references the server URL’s on instead of the newer Since the names in the SSL certificates won’t match various browsers will show warnings or won’t work at all on the old URL’s. So the task at hand is to create a patched version of the library, which will use the new URL’s.

One way of doing this is copying the entire project into your own source code management tool, make the changes and release software. I prefer to keep the original software as seperate as possible from my own changes. So my way of doing this is:

  1. Create a maven project for the patched version.
  2. Extracting the original classes out of the third party library during a maven build cycle.
  3. Replace the classes, which need to be patched by custom versions.
  4. Create a new jar-file containing the combination of original and patched classes.

Note: Of course I use some naming convention to prevent version conflict between the original software and the patched version.

Create a maven project for the patched version.

Of course you need a project location in your own source code management tool and create the default maven project structure with a pom.xml.

To identify the patched version of the library I use the groupId and artifactId of the original library, so everybody will still recognize dependency on the third party library. Within the version of I add an extra version-digit plus a describtion of the patched.
In our example it would become:


Within this pom I add a dependency to the original ‘broken’ version of the third party library. This will add all classes and dependencies to the classpath of my project enabling my IDE to use those classes during the build.


Extracting the original classes

During the build I use the maven-dependency-plugin to extract the classes from the original version to the target build location. This will ensure all classes will become part of the new patched jar-file. You need to exclude all broken classes from extraction, because your patched versions will not become part of the jar-file if the originals are already present in the target location.


Replace the classes, which need to be patched by custom versions.

Within my project I create the same package structure and classes for all classes, which need to be patched.
Extracting them from a source jar is a very good way to get started or copy them from the libraries version control system.
In my example it would be net.tanesha.recaptcha.ReCaptchaImpl.

Create the patched jar-file.

For this step you don’t need to do anything special. If you properly excluded the patched classes the maven build process will extract and compile all classes to the proper locations and the maven-jar-plugin will build your patched jar-file. Using your normal maven release process you are now able to create a patched stable release version and deploy it into your own software repository.

Tricky situations.

After using this procedure to create a patched version of the recaptha library and redeploying the software I still noticed that references to the old server URL’s were being used. The cause of this weird behaviour was a compiler optimalization called ‘Constant folding‘. ‘Constant folding’ is the proces of replacing all references to or calculations of constants values by the final constant value in the byte code of the compiled classes.

Within the recaptcha library the ReCaptchaFactory references the constants defined in the ReCaptchaImpl. In the original class file for the ReCapthcaFactory the values still were the server URL’s which we needed to patch in the first place. Therefor the exclusions in the dependency extraction does contain that Factory as well.


Contribute back to the original project.

If you went through all this trouble to fix a bug in an open source library, it is recommended that you create a patch of your changes and submit those to the open source project. Many project welcome such contributions and you get to make the world a better place for everybody.

Monitor releases for the original project.

Subscribe to the release mailing list of the original project and monitor their future releases. As soon as the provided a release, which incorporated your patch, switch to using the normal orginal library again.

Categories: iPROFS

Preventing mixed content warnings in your webapplication

Probably we have all run into to problem while browsing the web or using a webapplication: A warning of your browser, which tell you that a secure pages uses non-secure content, script or elements. Sometimes these kind of problems only show up in production, simply because the development and test-environments are running on plain HTTP. It does required some additional setup and configuration to enable HTTPS, but I think you should take the effort to have your local and test server mirror the general configuration of the production environment.

This article describes how can setup your local environment to serve the webapp unsing HTTPS and provides tips to prevent your application having the same problem. Read more…

Categories: Frontend, Infrastructure

Bye bye XMLGregorianCalendar (part 1)

13/02/2012 3 comments


We all know that working with dates in the Java language isn’t perfect, at least when you just look at the standard JDK. Not only is more then half of them methods in java.util.Date deprecated, but in order to get the Date of a java.util.Calendar you have to use the getTime() method. So when the base object aren’t that well to start with, things can only get worse when you start to mix in more technologies like XML.

When you are getting started with marshalling and unmarshalling java objects to XML you’re bound to run into the javax.xml.datatype.XMLGregorianCalendar. Did you ever try to get the Date value for a field unmarshalled from XML and wrote the following code:

Date date = xmlGregorianCalendar.toGregorianCalendar.getTime();

Why isn’t an XMLGregorianCalendar a GregorianCalendar just like a ArrayList is a List or a HashMap is a Map?

Oke, some smart people discovered these problems as well and started to specify a new Date and Time API (JSR 310).
Their idea are great although an anwser in the original JSR does give me some worries:

2.11 Are there any internationalization or localization issues?
No issues are expected.

In my opinion internationalization and localization are the major issues when working with dates and times, but hey, that’s propably just me.

So the expert group started on 13 februari 2007 and finished the early review on 28 march 2010.
I’m really wondering in which version of the JDK this well be included.
And of course once this has been introducted into the JDK: How long will it take to get it supported as the default datatype for  XML dates?


Fortunately there is already a solution available: Joda-Time.
With it’s DateTime, Period, Interval and Duration objects it provided a mature, easy to use and comprehensive feature set.

There is only one slight problem: JAXB doesn’t know anything about Joda-Time and it’s DateTime object.
By default fields in an XML-file with a xsd:datetime type will be unmarshalled to an XMLGregorianCalendar.

In various projects I have seen DateConverter utility classes for conversion from and to the Joda-Time DateTime object.
Wouldn’t it be nice if you just could use the DateTime field and have the conversion be done as some form of ‘custom marshalling‘?
But wait: you can! The JAXB API specifies an XMLAdapter, which “Adapts a Java type for custom marshaling

What we need is an XMLAdapter, which allows us marshal and unmashal between a ValueType and the BoundType.
The ValueType is some class, which JAXB knows how to handle out of the box (Strings, Lists or an Calendar and the BoundType is some type that JAXB doesn’t know how to handle. The Adapter will specify how transform from one type to the other.

So I’ve written a DateTimeAdapter, which unmashals from a Calender to DateTime and marshals a DateTime to a Calendar.

public class DateTimeAdapter extends XmlAdapter {

	public DateTime unmarshal(Calendar calendar) throws Exception {
		return new DateTime(
			// Correct for the difference between Joda DateTime
			// and JDK Calendar.
			calendar.get(Calendar.MONTH) + 1,

	public Calendar marshal(DateTime v) throws Exception {
		Calendar calendar = Calendar.getInstance(v.getZone().toTimeZone());
		return calendar;


Now the tricky part: You have to tell the XML (un)marshaller that it should use the custom adapter for mashalling certain fields in your objects.
But as you propably could have guessed: the JAXB-API provides a solution for that as well:
Just add an XmlJavaTypeAdapter annotation to the field in your object and the Marshaller and Unmarshaller will invoke the Adapter during the process.

@XmlType(name = "book", propOrder = {
public class Book {

    @XmlElement(required = true)
    protected String author;
    @XmlElement(required = true)
    protected String title;
    @XmlElement(required = true)
    @XmlSchemaType(name = "date")
    private DateTime publicationDate;

    // Getters and Setters


Part 2: WsImport, Maven and XJC.

In the next blog about this topic I’ll dig into the topic of WsImport with Maven and XJC (XML to Java Compiler) which is being using in generating classes for webservices based upon a WSDL and Schema. If some generator is going to generate the java classes for the SOAP service, I want it to generate fields as DateTime objects and annotate them with my XMLAdapter.
Sound easy, but of course it isn’t just that.

Update on how we do testing


Just like everything in the software industry: You need to make sure that your knowledge and your tools stay up to date.
New developments and new additional framework could make your life easier.

I previously wrote about ‘How we do unit testing with junit and mockito‘.
Recently I started using the Matchers from Hamcrest for writing my test expressions.
That library allows us to specify the requirements in a syntax which almost read like normal english. I just really like things like this:

String message = messageBuilder.getMessage();
assertThat(message, is(equalTo("This message will self destruct in T-10")));

Or this:

List allLetters = AlphabetGenerator.getAllLowerCaseLetters();
assertThat(allLetters, hasItems('a', 'e', 'i', 'o', 'u'));

Read more…

Categories: Java Tags: , , ,

Get every new post delivered to your Inbox.

Join 275 other followers