Life’s not about frameworks

Last week I came across a post on Java Code Geeks about how “ORM haters don’t get it”. The author rambles on about how the arguments of the so-called haters are wrong, and he explains his understanding of ORM and how he claims that without using ORM from the start, every project eventually ends up with a home-grown ORM-like framework.

I don’t place myself in a group of ORM haters, and frankly I have to agree with the author that a lot of bashing against ORM is going on lately. Partly this is because other, more simple, techniques became available to interact with the database, such as the Active Record. Another reason is the trend of using NoSQL over relational databases. Read more…

Categories: iPROFS, Java 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.

As a part of JAXB, the Java SDK provides ‘xjc’, a Binding Compiler also known as an Xml-to-Java-Compiler. When running the xjc command you need to specify the location of the schema and it will generate a set of appropriate java classes for you. By default, the XJC binding compiler strictly enforces the rules outlined in the Compatibility chapter of the JAXB Specification, which will result in you having fields of the type javax.xml.datatype.XMLGregorianCalendar in your classes. :-(

We don’t want that: We want to use DateTime of JodaTime as the type for our date fields.

By using the “-extension” switch of the xjc command, you are able to influence the process of java generation by activating custom JAXB Vendor Extensions. There are common extensions publically available, but none of those helps with replacing the XMLGregorianCalendar by properly annotated DateTime fields. Therefor you should write your own extension as an xjc plugin.

Writing a custom XJC Plugin.

So we are going to implement our own JodatimeJaxbPlugin, which will change the type of all date fields to DateTime and add the proper XmlJavaTypeAdapter-annotation to those fields. Implementing such an plugin is quite easy, since you just have to extend the com.sun.tools.xjc.Plugin and implement 3 abstract methods.

  1. String getOptionName(), which specifies by which command line argument value this plugin will be triggered. The default conventions is to start your option name with a capital ‘X’ to mark it as custom. For the JodatimeJaxbPlugin we use: ‘XuseJodatime’
  2. String getUsage(), which should return a description of this add-on.
  3. boolean run(Outline outline, Options opt, ErrorHandler errorHandler). The XJC compiler will do it’s internal stuff and then invoke this method to allow the plugin to tweak some of the generated code. The generated code is provided as the ‘outline’ of the generated classes.

The generated code by the XJC compiler is being represented in a com.sun.codemodel.JCodeModel, which allows access to the outlines of generated classes and fields. Our implementation of the plugin iterates over all generated classes, finds the fields within those classes of the type XMLGregorianCalendar and replaces those fields by an appropriate DateTime variant. The JCodeModel API doesn’t allow us to change the type of a generated fields, so we need to remove the old fields and add them again with the proper type. In that process we do want to preserve all metadata (Annotations) of the original fields and of course the getters and setters for those fields should be replaced as well, since the return type and parameter type will changes.

In order make the plugin available to the xjc compiler it has to be on the classpath and it needs to use the ServiceLoader API to register the plugin. Adding a simple text file in META-INF/service-directory with the name ‘com.sun.tools.xjc.Plugin’ and writing the fully qualified class name in that file is sufficient to register the plugin.

Running xjb from maven with the plugin

In order to trigger the custom plugin when the XJC compiler is being run from maven, you need to pass along the options to enable the extension and add the plugin to the classpath. The following sample snippet shows how to configure the maven-jabx-plugin for a custom plugin.

<plugin>
  <groupId>org.jvnet.jaxb2.maven2</groupId>
  <artifactId>maven-jaxb2-plugin</artifactId>
  <version>0.8.1</version>
  <executions>
    <execution>
      <goals>
        <goal>generate</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <extension>true</extension>
    <schemaDirectory>src/main/resources/xsd</schemaDirectory>
    <args>
      <arg>-XuseJodatime</arg>
    </args>
    <plugins>
      <plugin>
        <groupId>nl.iprofs.util.ws.jaxb</groupId>
        <artifactId>jodatime-jabx-plugin</artifactId>
        <version>1.0.0</version>
      </plugin>
     </plugins>
  </configuration>
  <dependencies>
    <dependency>
      <groupId>nl.iprofs.util.ws.jaxb</groupId>
      <artifactId>jodatime-jabx-plugin</artifactId>
      <version>1.0.0</version>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</plugin>
Categories: Java Tags: , , , , ,

Character Encode your source

09/05/2012 1 comment

When writing source code in your project, you’re always simply writing text and when you’re writing text you are saving this text on your disk in a certain encoding. This is a subtle field in which mistakes are easy and can lead to interesting side effects.

In our project we’ve recently moved from JDK 1.5 to JDK 1.6 and while local builds worked fine, the build server (running on Linux) started complaining:

“Unmappable character for encoding UTF-8” Read more…

Categories: Java Tags: , ,

The art of testing

In a few other posts on this blog I talked about the importance of unit testing and Test-Driven Development (TDD).

TDD helps us to ensure we’ve covered everything in our system by tests. Sure thing if you never write more production code than to satisfy a failing test, you’ve always covered all your production code by tests.

But how do we write a good suite of tests? How do we ensure that our tests help us maintaining the system? And remember, in agile development maintenance starts after the first successful compilation. Read more…

Categories: Java Tags: , , , , ,

Mini XPDay 2012 – a full and interesting day

On April 23rd, the Mini XPDay 2012 was held in conference center Kapellerput, in Heeze (NL). I went there to (re)connect with some people, and learn more about Agility and myself. It was a good day with interesting sessions in a lot of different areas.

Read more…

Categories: Scrum Tags: , , , ,

Captcha’s in Wicket

In this post I’ll describe how to add a captcha to your web application with Wicket. A captcha is a a type of challenge-response test used to ensure that the response is generated by a person. Adding one thwarts bots sending a large amount of filled in forms to be stored.

This article deals with the best known one: an image with a series of characters and an input field to which the user must fill the characters of the image. First I describe how to do this, using the captcha component that is shipped with Wicket. After that I describe how to add the well known recaptcha. Read more…

Categories: Frontend, Java Tags: , ,

Debugging web pages on mobile devices

As a web developer I often use front-end debugging tools like Firebug (Firefox) or Webkit Inpector (Chrome) to inspect or edit html & css and to run JavaScript (for example JQuery). Regular web pages shown by the browser can be inspected using such tooling as soon as the page is loaded.
With mobile devices however this principle is not (directly) possible. Of course you can run debug tooling opening the html as a file on your pc, deploy the application to a mobile device keeping your fingers crossed hoping it will run ok. It will be frustrating to see that web pages show and act different on a mobile device compared to the content being shown in a web browser on a pc. In this case the device is a black box and most of the times you have no clue what is causing the layout and behavior problem.
Searching the internet I have found a way to actually debug web pages on the mobile device using the browser of the pc. This article will show you on how to set this up, so that you can debug mobile web apps.

Read more…

Follow

Get every new post delivered to your Inbox.