Saturday, June 29, 2013

Govhack Brisbane 2013

A month ago I attended the Govhack (http://www.govhack.org/) event which was run around Australia to see what could be done with Government data in a weekend.

This was quite a bit of fun although I only had a day available to work on it the team had a cool idea for planning a trip using the Australia tourism data. We called it travelhackz and the summary is available at http://hackerspace.govhack.org/?q=groups/travelhackz

Big thanks to the rest of the team for their efforts on this!

Lamdba Jam 2013 (Brisbane)

A month ago I went to the YOW Lambda Jam conference in brisbane - http://www.yowconference.com.au/lambdajam/. This was quite a bit of fun and had plenty of interesting talks.

One thing that I do plan on looking up is the iteratee pattern in the play framework (http://www.playframework.com/documentation/2.0/Iteratees). This was presented by Nilanjan Raychaudhuri and looks very interesting, I plan on having a look at this sometime soon.

Hack and Heckle

Recently I joined Darren and Leigh in their Hack and Heckle podcast (http://hackandheckle.com/). We talk about technology and the news that we've seen in the week as well as the local meetups and whatever side projects we happen to be working on.

This has been quite a bit of fun so tune in if you are interested.

Wednesday, June 5, 2013

Jersey, JAXB and json with generics and inheritance

A month or two ago I ran into an issue where I was marshalling Objects to json using Jersey with JAXB annotations on my pojos but only the Super Class attributes were being marshalled. I have uploaded some code to github to demonstrate this:

https://github.com/nebnagrom/jaxbInheritance

In this contrived example we have a Super Class House which has a member variable which is a String and an @XmlRootElement annotation. There are three child Classes of House:
  • BlueHouse which has an additional Integer
  • RedHouse which has an additional String
  • GreenHouse which has an additional Boolean
We then also have a HousingEstate<T extends House> which wraps a typed collection of houses. In this example it has no behavior but in the situation I had we had behavior on this collection as well.

The issue occured once I started trying to return HousingEstate objects from my RESTful resource. When you invoked the resource you only got back member variables from the House class, i.e. something like this:

 {"houses":[{"houseName":"first blue"},{"houseName":"2 blue"}]}

 When what I wanted was more like:

{"houses":[{"houseName":"first blue", "blueAttribute":1},
           {"houseName":"2 blue", "blueAttribute":2}]}
 
After a bit of digging I found that I needed to add another annotation on the House class - @XMLSeeAlso like this:

@XmlSeeAlso({ GreenHouse.class })

After I added that I started getting the results I wanted.

I also tried this without generics or just using the Super Class but this did not work either. Interestingly I found that:
  1. Using no generics meant that I got House member variables only, even when I annotated BlueHouse with annotation and added BlueHouses to the collection
  2. Using the parent class as the Generic gave me Marshalling exceptions, probably to be expected though.
I haven't really tried to dig into what is going on here, I assume that there is something with generics and type erasure that makes it impossible for JAXB / Jackson to know that there is a child class that it should be looking at for the marshalling.

Stack trace of error you get with the House based version over the fold:


Thursday, February 7, 2013

Cryptography in Java

I spent an evening recently playing around with cryptography in Java. I had to look up something similar for work and then it piqued my interest so I had a bit of a play with it.

What I was looking to do was AES encrypt a file using a key derived from a passphrase. After some digging around it seems that the way to create a key is to use the PKCS #5 algorithm and hash the result. This can be done in Java with a key factory using the algorithm PBKDF2WithHmacSHA1:

    private static SecretKey generatePBKKey(String password) throws NoSuchAlgorithmException, InvalidKeySpecException {

        SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
        SecureRandom rand = SecureRandom.getInstance("SHA1PRNG");
        byte[] salt = new byte[16];
        rand.nextBytes(salt);
        KeySpec pbeKeySpec = new PBEKeySpec(password.toCharArray(), salt, 2, 128);
        SecretKey generatedKey = keyFactory.generateSecret(pbeKeySpec);

        SecretKey encKey = new SecretKeySpec(generatedKey.getEncoded(), "AES");

        return encKey;
    }


This key can then be used to initialise a AES Cipher which you can then encrypt the file with using a CipherOutputStream. Creating the AES Cipher was done using AES with ECB (Electronic Code Book) and PKCS5 padding.

        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
        cipher.init(Cipher.ENCRYPT_MODE, key);


 I wasn't sure what block mode and padding to use and this seemed to be what most use.

The best doco I could find from Oracle was the Java 6 guide which ran through the main classes - http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html

 The full code of what I ended up with is over the jump.


Thursday, January 3, 2013

Build failure in Windows with Maven

I had an 'interesting' problem with Maven and Windows today where the build was broken on a Windows machine but worked on Linux. All we were getting were weird cryptic errors that a class in the test directory could not resolve a class from the src directory. The build worked fine in the ide on windows just not when run on the command line.

Turns out the issue was that we had a lower case name for the package in src/main/resources but an upper case name in src/main/java. During the build the resources are copied over first this means that the directory was created as lower case. Then when the source was compiled it placed the class files in the lower case directory as Windows paths are not case sensitive.

For example we had src/main/java/FOO and src/main/resources/foo when this is built with maven you will get your class files compiled into the package 'foo' even though anything that imports this class will be looking for 'FOO'.

Hopefully this helps someone else so they don't spend a day pulling out their hair over this!