HiveMind builds with Maven so it has one of those neat Maven web sites
(http://jakarta.apache.org/commons/sandbox/hivemind). It's more than the
bare-bones, I have some
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 finds
plugins using simple rules ("look in this directory") and bootstraps itself
from what it finds. I
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 stage
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 any
service. Contributions are simply references to another HiveMind service (as
much as possible,
HiveMind is constructed recursively in this way) ... the
ServiceInterceptorFactory interface defines
how a service may construct an interceptor. Interceptors could be dynamic
proxies, but even better
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 Jakarta
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 into
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
comprehensively).
Unless I'm mistaken, Avalon doesn't have any concept similar to this. I
believe I saw a bit about
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:
http://jakarta.apache.org/commons/sandbox/hivemind/sample-registry/index.html
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 and
bootstrap the application server from there.
Philosophy: I don't deal very well with chaos. I like to bring a semblance of
order within a
flexible framework, a strong, flexible skeleton to improvise against. I
believe a proper framework
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. The
code itself is very well tested (88% code coverage) and stable. At this point,
I'm adding features
around the edges (such as new builtin services and the like), not changing the
internals in any
major way.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
> -----Original Message-----
> From: Alex Blewitt [mailto:[EMAIL PROTECTED]
> 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.
>
