Duration to Human Readable Format

Any developer at some point writes this kind of code snippet:


And how often the above developer wishes to output this duration variable in some human readable format?
Here's a short utility to perform such conversion


Enjoy (and don't forget to credit in case you borrow this code)!

Prevent EhCache From Storing Null Values in Cache

For quite some time we've been using the @cacheable annotation in our application to enable cache on designated use cases. As a default behavior, any flow passing through the annotated method is cached by the calling method (with arguments, if applicable) as key and the returned value as the cached value. EhCache uses an Element object to keep records in the cache store so that even if we return null from methods, an element entry will be cached (EhCache also stores thrown exceptions if you wish it).

But what if we don't want to cache nulls? There isn't any configuration attribute you can set to prevent such behavior. So how do we handle such a scenario? We can write a CacheEventListener to remove null value entries. The CacheEventListener can look something like this:
EhCache requires a factory to be declared in order to enable it to use our customized listener. Since my event listener is stateless, it can be used as a single instance. So my corresponding factory can look as follows:
Now we need to tell EhCache to enable this factory on cache events. ehcache.xsd supports declaring cache event listener factory per cache configuration. Declaring such factory on the target cache is as follows:
Now elements are removed if their cached value is null. Use wisely.

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. 

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. 

Notes from TheEdge 2010

On Thursday I’ve participated in AlphaCSP’s TheEdge 2010 Conference.

Java – The Road Ahead 

The opening session by Brian Goetz, Java Language Architect, was an excellent one and a great way to open a Java conference.
Brian presented the Java road map and what will soon be Java7 (also 8 and 9). Java7 was suppose to be published by the end of 2010 but due to Oracle acquisition's of Sun, the time frame moved to Mid2011 and Java8 to 2012. One of Java7 key features is the presentation of Project Coin, which presents new try-catch blocks with automatic resource cleaning and throwing the correct (inner) exception from the try block.

try (InputStream is = new FileInputStream(“filename.txt”); 
     OutputStream os = new FileOutputStream(“anotherfile.txt”); { 
    // … some code 
} catch (IOExecption e) { 
    // this exception is only related to ‘some code’ inside the try and not for the resources themselves 
    // no need to call is.close() or os.close() (which might throw exception) 
}

Project Coin also includes its sub-project: Project Diamond which makes creating generic typed instances a lot easier by asking the compiler to guess the correct type erasure (B.G. : “what the hell are erasures anyway?!”) and remove those long-long double declaration when creating collections.

List<Map<String, List<Integer>> list = new LinkedList<Map<String, List<Integer>>();

After ‘Diamond’ will look like

List<Map<String, List<Integer>> list = new LinkedList<>(); 

 Big Data is Here

On the Enterprise track we were presented with the large data handling framework such as Hadoop (and its related component such as Hadoop File System, Hive [Hadoop key-value DB]). These frameworks will be part of your development process as your product evolve into millions of transactions and billions of records. Spring Data eases development and deployment for integrating these frameworks with Spring.

Secrets Of The Rock Star Programmer

Presented by the book author: Ed Burns. The hour long presentation showed interviews with some of Java “Rock Stars” like: Spring Framework founder (Rod Johnson) and Hudson CI creator (Kohsuke Kawaguchi). The interviews and most of the presentation was to discuss what are the desired skills from programmers to become a “Rock Star”.

If you want to know what it takes, you probably need to read the book…

 Neo4J

As large data database come more and more into the industry, some implementations are inadequate with the data relations itself. Available on the market are key-value DBs (Hive), large table DB (Cassandra) and one other which I can’t remember but irrelevant for me. Neo4j is graph relation large data database which stores the data as graph association. The important note is that neo4j is only intended for large data. If you have a “small” thousands of records – stick with relation database. When you’re facing with millions (or even billions) records, associated as graph.

The examples given by Peter Neubauer were focusing on GIS systems but the usage itself looks endless when you wish to describes graph relations between your entities. A very common usage is social graph of members in social network (such as Facebook or Twitter).

Scala

Scala is a functional language with object oriented concepts. Scala code runs directly on the the JVM (like JRuby, Jython, Groovy, etc.). Like Groovy, it enables developers writing fewer code to achieve quicker development cycles and deployment. The presentation touched the mere surface but from the looks of it, it worth trying but I wouldn’t go and use it across the application.

HazelCast

For my opinion, one of the conference highlights. HazelCast is a distributed data grid framework which enables scalable distribution between nodes. Presented quickly by Guy Nir, it was really a nice presentation which APM might not need but still good to know of such framework. It’s concept is identical to other distribution systems (such as AMQP), but I would wait for Spring template to better support common operations (transactions, casting, multicasting, “hazelcasting”, queues…).

Hope to attend 2011 TheEdge Conference.

Adding additional information to unit test logs

Usually, when we write unit tests with debug enabled or data base tests with Hibernate show_sql property turned on, we end up with a huge output log were it's hard to see where each test case method started (or ended).

Comes to your rescue - TestExecutionListener with Spring TestContext Framework. By simply implementing the TestExecutionListener interface, you can add various functionalities to your test cases. These customized listeners can be easily put in action by annotating your test class with @TestExecutionListeners and providing your implementation to the framework

Here's a simple implementation for outputting additional information to your test logs with test name (class containing your test methods) and test case you're currently running: 

public class ExtraInfoListener extends AbstractTestExecutionListener {

    private static final Log logger = LogFactory.getLog(ExtraInfoListener.class);

    @Override
    public void beforeTestMethod(final TestContext testContext) throws Exception {
        final String testName = testContext.getTestInstance().getClass().getSimpleName();
        final String testCaseName = testContext.getTestMethod().getName();
        logger.info("******************************************************************");
        logger.info("  Running test case: " + testName + "#" + testCaseName);
        logger.info("******************************************************************");
        super.beforeTestMethod(testContext);
    }
}

Excellent presentation on working with 3 major J2EE frameworks in a layered application. This group has a lot of great presentations to follow. If you can pass the accent, you’ll get a great overview on GWT+Spring+Hibernate best practice.