Atomicity

A new Jekyll site, hosted on GitHib Pages.

Jackson JSON provides many different ways to customize the serialization process of a class, most of these methods utilise annotations on the classes themselves. I recently had the requirement to customize the serialization of a class when I had no access to change the source code of that class. That meant that using annotations wasn’t an option and I had to find another way.

After a fair amount of googling I stumbled across the following page (written by the author of Jackson):

Every day Jackson usage, part 3: Filtering properties

There are 7 options detailed in this post, 6 of which use annotations on the class itself. Option 7 is my only option then. Here it is:

7 . Most extreme way to filter out properties: BeanSerializerModifier

And if ability to define custom filters is not enough, the ultimate in configurability is ability to modify configuration and configuration of BeanSerializer instances. This makes it possible to do all kinds of modifications (changing order in which properties are serialized; adding, removing or renaming properties; replacing serializer altogether with a custom instance and so on): you can completely re-wire or replace serialization of regular POJO (“bean”) types.

This is achieved by adding a BeanSerializerModifier: the simplest way to do this is by usingModule interface. Details of using BeanSerializerModifier are more advanced topic; I hope to cover it separately in future. The basic idea is that BeanSerializerModifier instance defines callbacks that Jackson BeanSerializerFactory calls during construction of a serializer.

Right, so now I know what I need to use but there’s no details on actually how to use it.

Classes of interest

The 3 classes of concern are:

org.codehaus.jackson.map.ser.BeanSerializerModifier org.codehaus.jackson.map.Module org.codehaus.jackson.map.ObjectMapper BeanSerializerModifier

When extended this class provides 4 entry points which can be used to customize the serialization process:

changeProperties() - Implementations can add, remove or replace any of passed properties. orderProperties() - Implementations can change ordering any way they like. updateBuilder() - Implementations may choose to modify state of builder, or even completely replace it. modifySerializer() - Implementations can modify or replace given serializer and return serializer to use. Module

This is a simple interface used for registering extensions with ObjectMapper. The setupModule() method will be called during initialization and this provides an instance of Module.SetupContext. The method addBeanSerializerModifier() on that context object can then be used to register a custom BeanSerializerModifier.

ObjectMapper

This is the main class within Jackson for serializing and deserializing objects, the Module is registered with this object.

Usage

Firstly you extend BeanSerializerModifier and override the serialization process in whatever custom way you wish. For example you might wish to reorder the fields and also exclude some. The API for this is well documented, read the javadocs.

Next you need to wire your modifier class into the ObjectMapper and you do this by creating a Module and then registering that with the ObjectMapper using registerModule(). In the setupModule() method in your module you register the new BeanSerilizerModifier.

Example Code

To show how this works in practice I’ve put together a small project that implements a FilteringBeanSerializerModifier, which changes the serialization behaviour of ObjectMapper by filtering out fields on specified classes.

You can find the source code on GitHub here:

https://github.com/ultraflynn/jackson-custom-serialization

When a unix filesystem fills up the first question asked is usually, “Who is using the most disk space?”. Naturally there’s many ways of finding out but this works for me.

This will look for files being measure in Gigabytes and give you a list of the directories using the most. If your file system has smaller files on them substitute the “G” for “M”.

If that produces too many result it can be limited this this.

This will only go to one level of depth in the directory structure and will be looking only at directories with the word “snapshots” in them.

This also produces a grand total of files. This will always be displayed last in the output because the sort is numeric and it’s the highest number.

Often whilst tailing a log file in Unix you want to have the specific thing you are watching for highlighted as it appears. Here are two ways of achieving this.

Option 1 - tail/perl

t() { tail -f -n5000 $1 | perl -pe “s/$2/\e[1;31;43m$&\e[0m/g” }

Option 2 - sed

sed filename.txt /string-to-watch-for F

The dependency management in Play is a bit of an afterthought which is being address in V2.0 but for those using V1.X we’re stuck with using a Play yaml front-end to Ivy. Most of the time it’s absolutely fine but when you are doing local development of non-Play libraries which are stored in a corporate Maven repository (such as Nexus) you end up having problems.

The issue stems from the way in which Ivy (and therefore Play) uses those Maven repositories. Maven repositories are configured in the dependencies.yaml file which supports a subset of the behaviour permitted in the .ivy2/ivysettings.xml configuration file. Once Ivy has resolved the dependency it stores a copy in it’s local cache to avoid having to load it from the Maven repository again. And this is the problem. What if the artifact changes in the repository? Generally that’s not the case, usually you’d expect a new version of an artifact to be deployed to the repository. That is unless it’s a SNAPSHOT version, i.e. an ongoing development version, and this is exactly the situation when you are developing a non-Play library and a Play application at the same time.

Consider the following situation; you are working on a Play application which uses a library that you are also developing, which is not a Play application. You change that library and you perform a Maven “install” to compile and place the snapshot artifact into you local Maven repository. Then you run your Play application to see whether your Play application works using the new version of the library. This isn’t going to work because Ivy has cached the library in it’s own local repository. It doesn’t look for changed artifacts in the Maven repository, and this makes joint development of Play! applications and non-Play libraries a little tricky.

There is a workaround though, instead of defining the Maven repositories through the dependencies.yaml file you define them as a chained resolver in the .ivy2/ivysettings.xml file and there it’s possible to define a “changingPattern” on the resolver which indicates that the resolver should re-check the dependency if it’s a SNAPSHOT.

Here’s how to do this:

(I’m working on a pure Maven solution for Play so that Ivy isn’t involved at all and then this whole problem goes away. It’s going to be interesting to see what this process is going to look like when Play v2.X comes along)

Matt is a highly experienced senior software engineer with 14 years of investment banking experience (and 18 years in the IT industry) working for various Tier 1 banks in both the City and Canary Wharf. Over the past 5 years he has specialised in the area of Credit and Market Risk, working on timeseries analysis, credit submission, regulatory reporting and workflow.

Matt is highly delivery focused and a natural problem solver, he brings both a deep technical understanding of the technologies he uses and also an enthusiasm to get the job done. He is also an experienced technical mentor and enjoys helping others understand how best to use technology.

Matt has a degree in computer science (2.1) and a first in Object Oriented Design.

Quality software design is absolutely vital to producing applications that fulfil business objectives and Matt is a firm believer in quality architectural and technical design being the key to becoming a successful software engineer. He is also passionate about code being well designed, maintainable and fit for purpose and puts great emphasis on best practice design, readability and comprehensive testing.

Outside of work Matt is a keen runner, competing in ultra distance races which demonstrates his focus and commitment to a goal. He is also a family man and has 3 gorgeous daughters who demand all of his time when not working or running.

http://uk.linkedin.com/in/mattbiggin

Atomicity specialise in providing high quality technical solutions to complex business problems. Services range from on-site technical expertise through to the development, delivery and support of custom-built domain specific applications.

Technology never stands still and at Atomicity we pride ourselves on keeping up to date with the latest innovations and in developing the skills to know when to apply them. It’s occasionally said that when you’re holding a hammer every problem looks nail. The one-size-fits-all mentality just doesn’t work and it’s vital to choose the appropriate technologies to solve a particular problem. Having a comprehensive toolbox of tools, concepts and working practices is critical to being able to deliver the right solution.

It’s not just about technology though, our developers focus on getting things done within a team environment. There are a myriad of different concepts and practices, like Agile and Scrum which focus on team dynamics through to GTD and Pomodoro which allow individuals to be effective.