Recently I spent some time thinking about the Aksesi project. I have made some decisions that I’m going to cover in the next post. The very first thing on my list was to remove all of the TODOs from the code and refactor awful parts. In this post, I’m going to show you what I’ve changed in last few days.

I would like to remind you that all of the sources are available in my Github repository. Moreover, in the README file, you can find short project description with its main assumptions.

Packages rearranging

In my after-hours projects, I got used to mixing business logic and framework-related parts together. Moreover, in same packages, I also put configuration utilities.

I’ve reorganized all of the packages into three main subtrees: application, configuration, and infrastructure. In the configuration subtree, I’ve placed things connected with application configuration e.g. bean post processors (which I’ll cover later in this post). In the infrastructure part, there are classes connected with, more or less, framework. There you can find all of DTOs, converters, and controllers. Finally, in the application subtree, domain elements were placed. In com.aksesi.application sub packages, you can find converting strategies, descriptors, model elements and so on.

BeanPostProcessor interface

Previously I had the PassowrdConversionServiceConfiguration which was responsible for registering converters (character and gesture). In the moment of creating this class, I knew that it will be an only temporary solution. As a final version, I decided to use appropriate interface which is provided with Spring Framework.

The BeanPostProcessor interface is very useful because it allows you to manage application’s beans instantiation. Since now every  AbstractConverter object is registered in the postProcessBeforeInitialization method.

In the same way, Converter interface implementations are registered.

@Representation annotation for the rescue

The PasswordDTOConverter was very poorly written. The implementation assumed that there were only two types of password elements. This solution was closed to adding new ones. I knew that the more generic solution was required but then some problems arose.

How should we recognize which converter for password element should be used? In other words – where should we find the value for the clazz variable? I decided to write TargetClassProvider class which is responsible for handling information like this. The class owns the map of elements where a source class is represented by a key and a target class by a value. The idea is fine but the problem is still the same. How do we connect a source and target class together?

It hit me that it is a perfect place for custom annotation. I wrote @Representation annotation.

The annotation as an argument takes a name of a target class. In the example below GestureDTO elements will be converted into Gesture elements:

All of the classes that are annotated with the annotation are registered with TargetClassProviderPostProcessor.


There were a few TODO markers that had been removed.

I spent some time on looking for the safe way of removing all converters ( PasswordEncrypter.removeAllConverters). After realizing that converterMap does not leak outside of the object, I decided to replace old map with the new one. Knowing it, I’m sure that there won’t be a memory leak because if there won’t be any other reference then memory will be released.

Another marker was connected with lack of appropriate converter in the conversion process. I decided to just skip an element if the service doesn’t have any advice about a converter for a given type.

As I mentioned in the introduction, this post covers cleaning which was done as an introduction to the next stages of development. I introduced basic mechanisms that made Aksesi code more extendable and generic. In the next few days, I’ll describe all new ideas and the schedule.

You may also like