geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <>
Subject RE: HiveMind
Date Fri, 08 Aug 2003 18:24:36 GMT
HiveMind builds with Maven so it has one of those neat Maven web sites
(  It's more than the bare-bones, I have
good docs in place and more coming.

Again, my goal was to mix and match some neat stuff I'd seen elsewhere.  I like how Eclipse
plugins using simple rules ("look in this directory") and bootstraps itself from what it finds.
like the interceptor approach, used in JBoss 3.x, to converting POJOs into full-fledged services.

I also saw a lot to like in Avalon, but was driven away by the need for an explicit assembly
to identify all components and express the relationships between them.

HiveMind has a very strong sense of a "service".  It starts with a service interface; this
is paired
with a core implementation, a POJO that implements the interface.

You can then add any number of interceptors; these are classes generated on the fly that implement
the service interface and wrap around the implementation (or another interceptor).  Canonical
example, included in the framework, is LoggingInterceptor that logs method entry and exit.

The interceptor stack is dynamically assembled; any module may contribute interceptors to
service.  Contributions are simply references to another HiveMind service (as much as possible,
HiveMind is constructed recursively in this way) ... the ServiceInterceptorFactory interface
how a service may construct an interceptor.  Interceptors could be dynamic proxies, but even
is using Javassist to create new classes on the fly.  I digress.

One thing I want to avoid in HiveMind is endless, buggy, ad-hoc code for walking DOM represenations
(whether is w3c, JDOM, DOM4J, XOM ... any tree representation) of configuration data. Sure,
you are
expressing extension-point contributions as XML, but when you access the extension point,
you really
want to see Java objects there, not some XML representation.  I've adapted basic ideas from
Digester; when you define an extension point, you define the elements and attributes that
may be
contributed AND you define Digester-like rules for converting those elements and attributes
objects and properties.  That shifts the burden of error reporting and consistency checking
(stuff I
consider "plumbing") into the framework, where it belongs (and will be done consistently and

Unless I'm mistaken, Avalon doesn't have any concept similar to this.  I believe I saw a bit
configuration, and configuration data represented as XML, but not the big concepts from HiveMind
(and Eclipse): that contributions can come from multiple modules.

A very important aspect of HiveMind is developer productivity, including documentation.  HiveMind
includes Ant tasks that read a set of HiveMind module deployment descriptors and generate
JavaDoc-like documentation from them:

Where does this fit into Geronimo?  I have a vision of large "blocks" of functionality a multiple
sub-projects, each producing a JAR (and a HiveMind module deployment descriptor).
The central bootstrap framework will generate a HiveMind repository from those descriptors
bootstrap the application server from there.

Philosophy:  I don't deal very well with chaos.  I like to bring a semblance of order within
flexible framework, a strong, flexible skeleton to improvise against.  I believe a proper
makes it easier to make the right choice rather than the wrong one; that is, the easiest choice
should be the right choice, by design.

Final note: HiveMind is alpha because the feature set is not where I want it for a 1.0 release.
code itself is very well tested (88% code coverage)  and stable. At this point, I'm adding
around the edges (such as new builtin services and the like), not changing the internals in
major way.

Howard M. Lewis Ship
Creator, Tapestry: Java Web Components

> -----Original Message-----
> From: Alex Blewitt [] 
> Sent: Friday, August 08, 2003 1:38 PM
> To: Howard M. Lewis Ship
> Subject: Hive Mind 
> Sounds interesting. Can you go into a bit more detail? I 
> think the idea 
> of extension points is pretty much the right way to go; it's just a 
> case of convincing Those That Be that just because the 
> initial codebase 
> sits atop JMX ala JBoss, that there might be better ways of 
> doing it :-)
> Alex.

View raw message