Using Compile-Time AspectJ Weaving as @Transactional Proxy Provider

With my continued effort to annihilate the use of CGLib library, I reached the point of dealing with Spring Framework's Transaction management. Like with other support libraries from Spring Framework, transaction support is enabled via AOP proxies.
These proxies are often created using CGLib and as such they require our beans to violate Item 13 (Minimize the accessibility of classes and members) from "Effective Java (2nd Edition) by Joshua Bloch". CGLib proxy creation requires a non-final class with default empty constructor which prevents us from declaring our fields as final (Item 15?).

I could try and use Java dynamic proxy (supported by Spring Framework) but sometimes even dynamic proxies have their limitations (we reached such limitation by declaring a type @Transanctional and @ManagedResource - both tried to create different proxy types). Simply by looking at Spring TX schema I noticed it supports AspectJ mode. After reading some posts on bytecode weaving, comparing Spring AOP with AspectJ and performance charts (you got to read this) - I decided to use AspectJ to replace any AOP usage we have in our context (other than transaction support, we use advices). Another decision I made was to use compile-time weaving instead of load-time. Spring Framework has a very easy configuration if we wish to enable load-time weaving but it requires us to modify our application server configuration.

pom.xml
First of all, to enable compile time weaving, we need to add an AspecJ compiler to our build cycle. Maven has an aspectj maven plugin that can be easily added to enable compile time weaving.



Spring Framework Application Context Configuration
Now comes the part where we tell Spring that we want transaction support using the aspectj mode.


Notice that I also included </tx:advice> which tells Spring what are the basic transaction attributes to apply for each transactional call (e.g. method calls starting with count shouldn't be allowed to modify the database state).

Bean


Note that now we can declare our bean as final and reduce the implementation visibility to package only. Not needing the default empty constructor we can also declare our fields as final. Let's review the affect made by adding the @Transanctional to our service: If we were to leave the declaration on the type we would have to wrap each and every method with a transaction support (even private methods and even when calling this from within our service). If our service implementation contains only public methods, it wouldn't make any difference, but I would still recommend annotating only the public methods and by that proxy the concrete flow with transaction support.

In conclusion, we started with a runtime retention annotation and transformed its behavior to function like it is compile time. The performance benefits are immediately shown and even other aspects enjoy the benefits of compile time weaving. I think anyone who uses Spring Framework transaction management should consider using the above solution. Now go ahead and apply it on your project!

Event Driven Programming With Event Roaster

Often, in a multi layered, structured application it is sometimes required to notify several services on a system state change. Such change could be of some user interaction with our application, exception thrown from a specific layer or new client registered with our publishing service. These operations can be handled in a variety of paradigms, but for today's lesson: Event Driven Programming.


Recently I faced a problem with our ever growing application of knowing of a network topology change and notify several modules. The initial approach we took was to send important events to a centralize service, which knows almost the entire application structure, that can modify modules state based on the called method. Over time this service got larger and larger, complexity level rose and the maintainability efforts went to the roof. Searching for a suitable solution I broke the behavior to small strategy methods to which I could call from the original method. These strategies are actually event handlers for the state change. Looking around for event handling framework that will suite my needs I came across GWT's HandlerManager, Java's beans implementation, EventBus, ELF and even SpringSource event multi caster. Most, if not all of the above frameworks follow the same guidelines and principals with their provided solution, some are a lot easier to configure than other but what most of them lack is the (poor) support of configuration by annotations.

That's where my github.com account went in handy - I decided to write an event handling framework of my own. Named the project - Event Roaster. The framework is fully annotation configured and if you're working with IoC container like Spring it even provides you with EventServiceFactoryBean. So, here's what you need  to know before you can start working with it:



The snippet above demonstrates how simple the configuration really is and layout for event publishing and handling. Objects you wish to pass around as events are annotated with @Event (no need to implement anything, any object will do) and handler methods are annotated with @EventHandler, each method declaring which event it handles. Handlers can set their priority when called and (future versions will include the ability to) block further event processing. Publishing (a.k.a Firing) an event is as simple as calling the fire event in a matching event service. The event broadcasting is done asynchronous using a multi-threaded executor service. That's all there is to it, implement your handling methods and you're good to go.

Event Roaster is an open source project and as such it requires some attention and assistance by its users and contributers. Future versions are waiting release to Maven's Central repository using Sonatype OSS repository (project can't go to Central unless one of its dependency will move to Central as well). Feedback, feature requests and any general assistance will be appreciated. 

Team Coding

Ever seen a class and started thinking the only way to understand what it does is by rewriting (or deleting everything). This feeling has really no basis but it's more of a feeling that something just doesn't seem right. The truth is that we all find it easier to read code written by us than by others. Despite that, there is highly readable code and less readable. There are thousands of articles on code readability, clean, structured (newspaper metaphor), craftsmanship and other terms describing characteristics for code writing. But what characterizes a professional programmer? Extensive knowledge? Ability to lead a technology project? Or rather the mere definition of his directors that that developer reliability is of fire and forget. I think that what characterizes a professional developer is the ability to share, understand, expand and modify their work by other members of the development team.

I would like to coin another term - team coding. The way I see it, programming for a readable and clean code base is far superior to maximum efficiency. Team usually conform to some standard or a way of writing code (usually, a complete mess). Since most developers will simply follow the same style they encounter (explained partially by the Broken Window Theory), the style shouldn't be left undefined. Defining coding standards along with formatting rules, coding style and even how to write issues and comments might ease the development process. Here's a real life example: In a recent lecture I presented my development group how a unit test is structured. I explained that mocked members should have the mock prefix (e.g. mockFoo) and usually the class under test is called tested (or classUnderTest). As times went by, unit tests were added to the code base (thank God!) and additional test cases were added to existing ones. I sat for pair programming with another developer. When we reached to the part of adding a new test case she immediately wrote a case without even looking at the the field deceleration, simply by following the coding conventions for tests. That's team coding! Another team member was able to continue another developer work without too much hassle.

Style rules and automatic formatting actions reduced merge scope to conflicting statements only and developers can focus on what to write instead of where should a bracket should go. Modern IDEs (I'm currently working with Spring Tool Suite - an Eclipse distribution by SpringSource) support save actions that can configured to apply shared style rules. Oracle publishes Java Coding Conventions that will suite most teams. In my development group we took them as a basis and changed it a bit to better fit our code structure. The process of setting coding standards was long and had it share of discontent but these guidelines (style, standards, best practices, etc.) made our code base look (and feel) much more organized.

Some might argue that we reached the days where coding standards are not needed. I even heard an argument that every programer codes differently, and setting such conventions will damage their individualism. To that I have only one thing to say: Software development is like Communism - either you work as a team for the good of the company or you're sent to work on some BS assignment cleaning code. If Communism is not your thing and you're more into French stuff the idea is the same as The Three Musketeers :-) 

Strategy pattern as replacement to instanceof if statements

Let's begin with a simple rule: instanceof is an ugly pattern.



To add to this ugly pattern you might not notice a fault in such pattern (what if Bar extends Foo?) and the maintenance for it can go sky high as your system evolves. You will end up adding more ugly code and keep trying to rearrange those switches so that class hierarchy wouldn't collide with your logic.

The literature tells us that this type of design can be replaced by using the visitor pattern and make each class responsible on how it should be invoked by others. To me, that sounds awkward to force my domain objects to be familiar on their interaction with services, DAOs or other delegating classes. I prefer the use of strategy pattern and leave my code clean from coupling. The following is a slightly modified strategy pattern with a corresponding holder which enables re-use of strategies in a Dependency Injection environment. The very basic interface might looks as follows:



For the re-use part, we hold our concrete strategies in a holder in a simple Map (HashMap in the following example). If you're using some dependency injection framework you can inject all known implementation to the holder below and then inject the holder to clients use code.



To quickly go over the abstract implementation: the map holds our strategies by their declared discriminator/key. The holders uses generics to support using the holder with any extended type of strategy without casting. Another point to mention is the abstract method getDefaultStrategy() which enables our concrete implementation to use a default strategy (obvious) or throw some state exception if no strategy was found. You can simplify this implementation by using interfaces but with this added generic flexibility I managed to replace different strategies with the same basic holder abstraction.

The following is an example on how the holder and strategy above can be used in real life scenario.



As you can see, ExampleStrategy is simply extending the Strategy interface and provide a single execute() method. By injecting all known implementation (your IoC container should do it for you) and passing them to our AbstractStrategyHolder we're ready to use our strategies in our designated flows. Small note: I wouldn't recommend using the class type as discriminator but sometimes it's our best option.

We managed to clear our ugly instanceof switch with a single call to a strategy holder and invoke the matching strategy - cleaner code, easy maintenance. Need another reason why this is better? Testability! With this design implementation we can better test our code and write small, individual tests to our flows. Need another?! Extensibility! Need new strategy to perform another action? Add a new strategy and let our IoC container inject it to our current holder implementation (I've seen this happen so many times I believe that alone should convince you to use the strategy pattern).

The code examples (and for the builder example in earlier posts) can be found here.

Configure Spring's Hibernate SessionFactory with Connection Pooling

Ever seen the following exception and had no clue how to solve it?

0000-00-00 00:00:00,000 ERROR org.hibernate.transaction.JDBCTransaction - JDBC begin failed
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was37277 seconds ago.The last packet sent successfully to the server was 37277 seconds  ago, which  is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the serv er configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.

The simplest explanation is that Hibernate was trying to use a connection that was closed (timed out) by the database (MySQL in the example above). You google the exception and find endless solutions when most of them are telling you you need a connection pool. Sounds easy, right? Simply add some Hibernate properties to your session factory bean and the problem solved.... Not really.

When using Spring ORM to create our session factory, we usually use some LocalSessionFactoryBean implementation which configure Hiberante and initialize it properly. What it doesn't tell us is that Spring is actually overriding connection settings - specifically the connection provider. The following was taken from the actual session factory initialization code in LocalSessionsFactoryBean:

if(dataSource != null) {
  Class providerClass = LocalDataSourceConnectionProvider.class;
  if(isUseTransactionAwareDataSource()||dataSource instanceof TransactionAwareDataSourceProxy) {
    providerClass = TransactionAwareDataSourceConnectionProvider.class;
  } else if(config.getProperty(Environment.TRANSACTION_MANAGER_STRATEGY) != null) {
    providerClass = LocalJtaDataSourceConnectionProvider.class;
  }
  // Set Spring-provided DataSource as Hibernate ConnectionProvider.
  config.setProperty(Environment.CONNECTION_PROVIDER, providerClass.getName());
}

So how do we configure our connection to use some connection pooling? Instead of configuring our session factory, we configure the data source to use a pooled data source. By using c3p0's ComboPooledDataSource we're able to wrap our current data source with a connection pool by configuring few simple properties. The following is an example how to declare our data source bean (values shouldn't be hard-coded, visible here for example purpose):

<bean id="dataSource" 
    class="com.mchange.v2.c3p0.ComboPooledDataSource" 
    p:driverClass="com.mysql.jdbc.Driver"
    p:jdbcUrl="jdbc:mysql://localhost:3306/db"
    p:user="myuser" p:password="secret" 
    p:minPoolSize="5" p:maxPoolSize="20" 
    p:maxIdleTime="7200"
    p:idleConnectionTestPeriod="300" 
    p:preferredTestQuery="select 1" />

Another property you might wish to add is p:testConnectionOnCheckIn="true" but you may have to pay a price - performance wise. This property tells our connection provider to re-validate the connection before performing any database operations. If you think your connections will be violently closed - use it.

That's it, we're done. Our data source is wrapped with a connection pool and Spring session factory is guaranty to have an available connection - a live one. I recommend having some performance tuning to figure out the optimal settings for your application.

Builder Pattern for Persistence Objects

Usually, when dealing with persistent entities we would like to keep records at the same state they are stored in the database and keep the newly created entities unmodified until we are persisting them to a database. The first requirement is quite easy to accomplish when using interfaces. For instance, our data access layermight export the following as its domain objects:

Notice that our domain object interface doesn't expose any mutators (setters). Client retrieving these records is unable to change their state. If your services are read only - we're basically done. We hide our concrete implementation by declaring those classes as private package visible (I would also add final to be even stricter) and initialize them anyway preferable (constructor, setters). Easy, right?

Now, let's say our service enables CRUDoperations. We present our clients with the option to persist entities by passing a DTO/ VOimplementing the same interfaces as shown above. First ( Lazy) option: the client can have its own domain hierarchy implementation based on our published interfaces. Hmmm, nice option, but we don't want to force our clients to have unnecessary code when we can provide it with some assistance. Second option, publish our DTO and force the client to create the object by passing alldata values to the constructor (no mutators) - better, but what if our constructor has 5-6 (or more) fields? [ code smell] Third option: expose a default constructor and mutators and have the client initialize the object with multiple invocation lines, one-per-setter (we can have a mix mode of the 2 ndand 3 rdoptions but it's still the same). But, leaving mutators exposed might damage our requirement of keeping our entities unmodified until we reach the actual persist part. So, what should be a better option (I don't think it's the best, since any solution should fit the desired requirements)?

Here comes the builder pattern - we offer the client easy initialization of DTOs but prevent it from changing it once it's done. We add an inner  private static class called Builder which will allow easy initialization of our domain objects. Why inner class and not FooBuilder ? That's simply a flavor, I prefer having a class called Builder for each of my domain objects. Both options (inner or external) will give us the same result and have the same structure. Let's say we have the following DTO as our Foo implementation:


I won't go into details describing the DTO itself, simply say that I'm using Hibernateas an ORMand added some Hibernate Validatorsto give it a more realistic look and feel. Notice the default constructor is not available to client interaction (Hibernate can easily interact with it) and so does our mutators (private package scope). Another thing to notice is the special care we give collections: we never return the actual field or use the parameter given to us (collections are mutable [ 1, 2]). So, how can our clients initialize the above DTO? By using a Builder!


This example is what the general design should be like. For each mutator method we expose on our builder we can add validation logic or validate the entire object in the build() method. Notice we added 3 static factory methods to our original DTO to support 3 operation types: creatinga new instance, updatingan existing one or mergingvalues from existing one to a new instance. Another point to notice is that our builder returns itself from each mutator and that the build()method returns the interface (blocking any future changes to the instance). For ease of use we can add helper mutators to create complex objects by passing parameters to our builder to create (e.g. class holding IP and port - add  setIpAndPort(IP ip, int port)  and  setIpAndPort(IpAndPort ipAndPort)  to our builder)

With this approach we get the requirements we asked for when offering our clients CRUD operations. This design guideline might look as an overkill but the maintenance benefits and ease of client usage is what we're really looking for. With modern IDEs (like Eclipse, IntelliJor NetBeans) we can simply create a coding template to auto-generate builder implementation for our persistence objects. This design is not limited to persistence layer. Every time you need to create an object with too many constructor arguments (and you prefer not to refactor that class) - use a builder. Builder pattern - another tool in your clean code toolbox. 

Unit Testing Principals and Coding Kata

For the past few weeks I've been trying real hard to teach unit testing principles to my development group. Thinking on the subject I decided to create a workshop for the group to actually practice writing unit tests. Luckily, my managers gave me the approval and opportunity to spend a decent amount of time on creating a lecture and coding workshop for the subject. 

Watch it on Prezi

The following is the lecture I presented to the group last week. The presentation was accompanied by explanations and examples from the group day-to-day tasks. Most of the ideas and axioms presented were collected from books I read to better understand and improve my software craftsmanship skills. Primary books dealing with unit testing and tests in general are: Clean Code by Robert C. Martin, Working Effectively with Legacy Code by Michael Feathers, Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck, John Brant, William Opdyke and Don Robert. I've also covered few topics presented in blog posts from the hacker chick blog [1, 2] and Martin Fowler blog [1] (thank you, Uri).

A coding Kata was created to illustrate a small code base (legacy as it has no unit tests) of bank account operations. The logic, of course, doesn't really makes sense, but I used all the elements and principals most developers will encounter during their daily development tasks (Entity, DI, DAO, etc.). I've included a sample unit test for the PromotionService class so developers can learn by example when trying to write other tests. The Kata practices writing mock enabled unit tests using EasyMock focusing on IMocksControl and Capture scenarios. Some test cases were offering the option of using of EasyMock's nice mock (as a simple stub) or practicing strict mock of recording behavioral order.

The workshop took almost 3 hours to complete. Still waiting to get some additional feedback from the participants but so far all are positive ones. From what I managed to hear, people are discussing the topic and concepts I presented and I hope they will eventually agree with most issues. I have no doubt that I will keep having argues on the subject, but hopefully less than before (well, I can dream, right?).