Creating your own custom Spring configuration.

Recently I volunteered myself to do some of the Spring integration for Hazelcast, for one main reason actually.. I had always wondered how to actually do that. It is something you don't get to do often in a corporate working environment. As with most things Spring related it actually turned out to be very simple.

First thing I needed to do was define a schema for the Hazelcast xml config. If you want to add your custom XML configuration into Springs', it will require that you have a schema for the specific XML.

So what is the quickest way to get started on a schema? Altova XML Spy, it generates a basic XSD form a sample XML which takes care of about 40% of the actual work. Then it's all about the details, min / max constraints, enumerations, defaults, attributes and documentation. I believe XSDs should be verbose, so the version below is not 100% complete but it is a good starting point.
I am not going to add the XSD to this post as is quite long and doesn't add much with regards to the actual Spring integration. If interested, it is available here...

On the Spring side you need the following:
1. An implementation of: NamespaceHandlerSupport, this basically tells Spring when it finds "hazelcast" use the "HazelcastBeanDefinitionParser".



2. An implementation of: AbstractSimpleBeanDefinitionParser. This implementation actually processes the XML from the Spring application config. You need to override
getBeanClass and doParse methods, to specify what type of object and how to create it respectively.


3. 2 files in the META-INF
3.1. A spring.handlers file containing the namespace and the NamespaceHandlerSupport implementation (in my case):
http\://www.hazelcast.com/schema/config=com.hazelcast.spring.HazelcastNamespaceHandler

3.2. A spring.schemas file containing the location of the schema:
http\://www.hazelcast.com/schema/config/hazelcast-basic.xsd=hazelcast-basic.xsd

and that is it...

The XML you described in your XSD is now available to be used within your the Spring config.

The example below is a Hazelcast map cache config, which can then be injected where required as ref="config".



The source and tests for this are available in the Hazelcast code project here.

Guice & Hazelcast.... Method Caching Interceptor

A couple days back I did Spring, AspectJ, Hazelcast Method Caching Aspect and I received an anonymous question on how to do the same thing in Guice I had heard of Guice, I knew what it was, but... I have been a Spring zealot for many years now, so my first reaction was:
What??? Guice? me?? ... Not use Spring? ... why would you ever not do this is Spring?... after a bit more whining I finally found myself saying "Oh ok, let me do it in this Spring wannabe "Juice" framework, just to prove that Spring is better."

All I can say is dammit! I hate being wrong ... the Guice is sweet. It took me about an hour to go from never using it before to having this AOP Method Cache Interceptor project done. A lot of that time was me being a typical developer and playing rather than actually reading the docs. In other words, it's simple, and that is always a good thing.
Now before someone takes this the wrong way: I know Spring does a lot more, Guice is focused on DI, Spring integrates with more, most of the popular Google apps run on Guice so it is rock solid etc. etc... I am not doing this as a comparison and definitely don't want to choose sides, but rather just showing another way of doing something.

I will only be posting the interesting bits of this project here, the full source is available here :
Source Code

First thing, Guice is available in the Maven repo and they recommend using that rather than the google.code site. The POM for this project:



Guice (as they say in their documentation) takes full advantage of annotations and generics. So for this project I created a @Cacheable interface to allow me to annotate the methods I wanted cached.


To configure Guice you need to extend an AbstractModule, this is where you configure what gets injected where by what. In the example below I use a construct called a Provider to allow me to use the Hazelcast factory to inject and instance. One other important thing to note in the code below is the "requestInjection(cache)" when injecting into interceptors you need to specify that in order to that injection before actually using the interceptor.

The AbstractModule:


And lastly for the actual interceptor. Right at the bottom of the source below you will see the @CacheName interface, this is one of a number of ways to map configuration values to be injected. The interceptor implements MethodInterceptor and you get all the required information about the method execution from the MethodInvocation parameter.



So there you go Mr Anonymous, hope it helps.

Spring, AspectJ, Hazelcast Method Caching Aspect

After my recent discovery of Hazelcast, I decided to update my caching aspect project to include a Hazelcast implementation.

The source code for this project is available here

For more information please refer to the actual source or my original Ehcache post. The main difference here is that the Hazelcast implementation is by default a distributed cache, and takes advantage of all the other functionality that Hazelcast provides.
The main points of interest for this implementation are:
- The actual aspect class. See code below.
- The application context. See xml below.
- The Hazelcast configuration. I am using the default Hazelcast configuration, located in the hazelcast-version.jar. To use a custom one, you can define a hazelcast.xml and inject it via Spring.
- The CacheKeyStrategy in the code below is an interface defined to allow key generation for the cache for specific requirements. There is a default implementation that simply sorts and uses hashcodes of the values in the class. You can define a strategy per type you want to cache.

note: java docs only removed for size of post

The aspect:


The application context:


The test case:

Hazelcast - a simple distributed caching alternative

I have over the last couple years used EhCache either via Spring (with AOP) or having it configured as hibernates' cache. I have never had the time or the need to look into the whole distributed caching available with Terracotta. However I recently stumbled on to Hazelcast and read the following:

"Hazelcast is pure Java. JVMs that are running Hazelcast will dynamically cluster. Although by default Hazelcast will use multicast for discovery, it can also be configured to only use TCP/IP for environments where multicast is not available or preferred. Communication among cluster members is always TCP/IP with Java NIO beauty. Default configuration comes with 1 backup so if one node fails, no data will be lost. It is as simple as using java.util.{Queue, Set, List, Map}. Just add the hazelcast.jar into your classpath and start coding."

I was instantly intrigued. So it sounds simple enough...Open IDE...jump in... being a maven fan, I figure, why download and manually "install" when you can just use maven, so I search around a little and add the following to a pom.

Edit: 1.8.4 is now outdated check http://www.hazelcast.com/downloads.jsp for the latest.

From the online documentation, I saw there was an InstanceListener interface. I create a simple Main class, that implements that and lists the instances.



So running this just adds a listener to the Hazelcast instance. According to the documentation Hazelcast allows for the following (and lots more):
# Distributed java.util.{Queue, Set, List, Map}
# Querying distributed data

I created a couple Main classes to run these separately, so that I could see if they are usable across different JVM executions.








So within minutes... I have a distributed cache across 4 applications, that I can monitor, control, query... (and btw. Hazelcast allows you to add indexes to the caches, same as a database to optimize queries).
If I was to place these 4 applications on 4 different machines, they will by default cluster (multicast for discovery) and have built in failover, monitoring and even persistence if required.

Coming from an environment where we have dozens of servers all caching data, this has got to be one of the most exciting open source products I have come across. Now I just need to convince the powers that be to prototype this and this may be the first open source project I actually try get involved in. The possibilities I am seeing for this type of functionality and then integrating it with the Spring Framework may actually make my brain explode.