RE: HiveMind

["Howard M. Lewis Ship" <hl...@comcast.net>]

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:Alex.Blewitt@ioshq.com] 
> 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.
> 

Re: HiveMind

[Stephen McConnell <mc...@apache.org>]

Howard M. Lewis Ship wrote:

>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.
>

Howard:

I had similar concerns that basically filtered down to a requirement for 
a couple of sub-systems within a containment API:

* auto-discovery of component types and services
* auto-assembly using runtime context and deployment heuristics

What this means is that you can easily use deployment descriptions that 
are really compact.  This is achieved by maintaining a registry of 
component type information pulled in from structural units (jar files), 
maintaining associations between type definitions and published 
services, and when the need arises, dynamically constructing deployment 
solutions based on packaged deployment profiles and type-level defaults. 

Cheers, Stephen.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin

RE: HiveMind

[J Aaron Farr <fa...@apache.org>]

Quoting "Noel J. Bergman" <no...@devtech.com>:

> Howard M. Lewis Ship wrote:
> 
> > 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.
> 
> ref:
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=geronimo-dev@incubator.a
> pache.org&msgId=796538
> 
> You might want to revisit that, since they have been trying to solicit
> your
> interest in collaboration.  Berin is quite sincere about their interest
> in
> working with you.
> 
> There have been a variety of container efforts there doing different
> things,
> but they've finally reached a point where everyone is starting to jell
> around a micro-kernel model where the micro-kernel isn't a container
> from
> the end-user perspective, but is a means for building a container using
> pluggable container services.
> 
> I think you'll be very pleased if you start talking with them about
> where
> they see the new container going.
> 
> 	--- Noel
> 
> 

I'll second that thought.

I'm sure the Avalon project would love to collaborate.

-- 
 jaaron  <http://jadetower.org>

RE: HiveMind

["Noel J. Bergman" <no...@devtech.com>]

Howard M. Lewis Ship wrote:

> 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.

ref:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=geronimo-dev@incubator.a
pache.org&msgId=796538

You might want to revisit that, since they have been trying to solicit your
interest in collaboration.  Berin is quite sincere about their interest in
working with you.

There have been a variety of container efforts there doing different things,
but they've finally reached a point where everyone is starting to jell
around a micro-kernel model where the micro-kernel isn't a container from
the end-user perspective, but is a means for building a container using
pluggable container services.

I think you'll be very pleased if you start talking with them about where
they see the new container going.

	--- Noel

RE: HiveMind

["Noel J. Bergman" <no...@devtech.com>]

Howard M. Lewis Ship wrote:

> 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.

ref:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=geronimo-dev@incubator.a
pache.org&msgId=796538

You might want to revisit that, since they have been trying to solicit your
interest in collaboration.  Berin is quite sincere about their interest in
working with you.

There have been a variety of container efforts there doing different things,
but they've finally reached a point where everyone is starting to jell
around a micro-kernel model where the micro-kernel isn't a container from
the end-user perspective, but is a means for building a container using
pluggable container services.

I think you'll be very pleased if you start talking with them about where
they see the new container going.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org