Hivemind
Ive been playng with Hivemind - a newly released Apache project. It’s tough being an early adopter as there’s very little meta-documentation to go look at. That is, something other than the documentation written by the project authors themselves. Im not saying that engineer-written documentation sucks or anything (though in most cases, it sucks rocks) but in the case of Hivemind, the documentation is pretty good. What was missing was “war stories” where people talk about the quirks, about how to get going from a standing start, and so on.
Inversion of Control / Dependency Injection Containers
Hivemind provides a friendly framework that supports coding according to the “Inversion of Control” (IoC) design pattern (also known as “dependency injection”). Martin Fowler (author of a fantastic book on Refactoring) has written a helpful article on inversion of control on his website. Fowler's article mentions a couple of other IoC containers - namely Spring and PicoContainer. Having looked at them both I have to say that I like Hivemind better than either of them. PicoContainer focuses very closely on dependency injection and object creation in a very admirable, single minded fashion. As a result it’s not quite got the breadth / richness of API and suppor for my purposes.
Hivemind in general
On startup Hivemind will scan the classpath looking for XML descriptor files to define services and modules that implement the given service descriptions. It assumes that it’s looking for a file called hivemodules.xml in a directory called META-INF. In general, this is where a standard Java manifest file would live in a JAR file, so seems logical enough. I had great trouble getting my hivemodules.xml file to be read, until I remembered that it needed to be in may class path - I added an ant task to copy it across as part of the standard compile process, just to make sure. Of course, that meant I needed to use ant rather than my usual IDE compilation process when the module descriptor file got changed. That, or put my source directory into the runtime classpath (either would work).
Dynamic plugins
I quickly ran into two limitations or issues with Hivemind that I’ll be needing to think about for the future. Fowler's article talked of dependency injection being of particular interest to people who wanted to implement a plugin style architecture; the main application needs to be unaware and independent of the 3rd party plugins that extend it in various ways. That is precisely the case with my open source project, Chronicle Lite, where a clean IoC pattern is used internally. This separation of concerns doesnt use an IoC container to manage the relationships but would benefit from using Hivemind. My problem is that Hivemind doesnt create a classpath dynamically on startup based on JAR files in the execution directory. Chronicle Lite, on the other hand, scans for JAR files and integrates them into the application on startup thereby allowing users to upgrade / enhance the application by simply dropping a JAR file into its directory.
It was the work of a few minutes to integrate Chronicle Lite's PluginScanner with Hivemind and I soon had the IoC container finding module descriptors in JAR files dynamically. (Chronicle Lite code shown in bold)
PluginScanner pluginScanner = new PluginScanner(pluginDirectory, statusReporter); ToolPluginScannerHelper toolPluginScannerHelper = new ToolPluginScannerHelper(); pluginScanner.addHelper(toolPluginScannerHelper); PluginClassLoader classLoader = pluginScanner.getClassLoader(); ClassResolver resolver = new DefaultClassResolver(classLoader); RegistryBuilder builder = new RegistryBuilder(); builder.processModules(resolver); Registry registry = builder.constructRegistry(Locale.getDefault());
Module names
I ran into an interesting issue as I was going on with things. It’s “first come, first served” when it comes to module names; the first time that Hivemind encounters a module, it’s added to its internal registry, and subsequent modules of the same name are ignored. Just a little “gotcha”, and certainly not Earth ShatteringTM, but it might bite someone.
What would be awesome would be an option that modules of the same name all coallesce into a single place. That way, all the plugins could live together. The container could still deal with clashes on actual service names within a given module.
Logging
I’ve used Log4J in applications but I've not used the JDK 1.4 logger at all. I note from reading online that the Apache commons logging framework (used by Hivemind) is agnostic about certain details, leaving them to the underlying logging framework, but I couldnt find out how to globally turn on logging at a certain level. Grrr. Lack of documentation, or simply my own stupidity, I dont know!
The reason that logging came up was the ability of Hivemind to transparently intercept services to (say) log method entry and exit, log timing / performance statistics and the like. My plugin JAR contained a hivemodules.xml file that said
So it wasnt obvious that when I later defined a logging interceptor that it would used the short name:
But stepping through the code indicated that, yes, my plugin service had been hooked even though I didnt see any logging (see 'inability to control commons.logging' for more details).
In conclusion
Hivemind works, and works well, especially when enhanced with some custom code to provide a dynamic classpath. Time will tell how many people post helpful “war stories” and thereby enhance the already good documentation, but I with the team well with the project and will continue my own investigations.