commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [HiveMind] Question about HiveMind scope and purpose
Date Wed, 09 Jul 2003 15:27:35 GMT
Howard M. Lewis Ship wrote:

> HiveMind is being very, very actively developed.  I've been putting a lot of info onto
my blog:

> I realize that some aspects of Avalon and HiveMind overlap.
> I think our goals are a bit different.  HiveMind is intended to form a lower-layer; Avalon
is a
> services container, HiveMind is a services and configuration microkernel.  The majority
of HiveMind
> is related to building and contributing configuration elements.  HiveMind expressly does
not have
> the same kind of Inversion of Control that Avalon has; IoC or not is left to the developer.
> (or at least the Avalon containers I researched) require more explicit connection of
services.  I
> did not see anything akin to an Eclipse plugin model for handling configuration ... that's
> HiveMind's strong suit ... HiveMind's "assembly" stage occurs dynamically, at runtime.

:)  I understand completely where you are comming from.  There are now three
different container implementations in Avalon land now.  Fortress and Phoenix
are the released containers, and Merlin is still under development although
it is fully functional and rather featureful.  Groking what's what can be a
bit daunting.  We are in the process of identifying the most flexible code base
and evolving into one code base which will help lessen the load to understand

That said, Avalon does firmly entrench the IoC pattern--which has paid for
itself in spades on many projects--but enough of that here.  Both Phoenix and
Merlin have a MicroKernel, and Merlin has runtime assembly features.  So there
is more overlap than you might of origionally thought.

However, more on that later.

> I know it sounds like "not invented here" syndrome, but I had a short window of opportunity
to put
> something together, keep it open-source, but use it in a very large scale project at
work.  In this
> situation, it was faster, easier and politcally safer for me to build it myself than
it would be to
> take the time to fully grok and adapt Avalon.  Additionally, a key requirement for me
is line
> precise error reporting [*]; this is a major amount of work to graft into an existing
code base.

Also quite understandable.  As to "politically safer", the politicing in Avalon
land has gone down quite considerably in the last month or so.  It is a much
nicer place to be now.  That said, at the time you started working on HiveMind
things were probably in turmoil in Avalon--so I can understand your hesitance
at that time.

> Ultimately, I see HiveMind fitting in below Avalon; perhaps it may be adopted as the
way in which
> the Avalon container is configured, rather than the way services hosted within the Avalon
> are configured.

I am very interested in seeing how HiveMind and Avalon can cooperate.  While
HiveMind has a set of features and other goodies, there is some overlap.  That
overlap does not mean that one must survive and the other die, but it means
that we might be able to cooperate on how to define different features/aspects
that will work in both environments.  I want to see where the two projects can
cooperate, sharing experience and such.  By helping each other understand the
differences and similarities we can probably establish a good relationship.
It will help the Avalon team understand where they have failed to meet your
requirements, and it will help you understand the challenges we have already
faced and how we overcame them.

> [*] In Tapestry, and now in HiveMind, XML configuration files are read and converted
> "descriptor" objects, which are then used to create runtime objects.  In Tapestry, it's
> specifications used to create components and pages and such.  In HiveMind it is more
> The line precise bit is: when the XML files are read, the exact location (file, line
and column) for
> each descriptor object is recorded as a property of the object.  When the descriptor
object is used

Hmm.  Have you seen my BXML project at d-haven?
It will allow you to compile XML into a SAX producing object (i.e. compiling
your configuration files so that reads are blazingly fast).  It also provides
line precise error messages.  It compiles the XML file into an XMLReader
compatible class.

Anyway, I can probably leverage the lessons learned from that into the
configuration reading code for Avalon...  Where else are line-precise
error messages used?

> to create a runtime object, this location property is applied to the runtime object.
 The end result
> is that exceptions in the runtime objects, long after files have been parsed, can be
related back to
> exact locations within the input files.  You don't have to sleuth it out from a stack
trace, a
> property of the exception will be the exact location to look.  This works out to be a
> productivity boost ... you spend very little time guessing at problems, instead the framework
> directs you to the exact problem.  This is all combined with exceptions that include
a location
> property, and Tapestry's exception reporting mechanism is capable of displaying those
> properties.

Where should I look for this?  I am interested myself in incorporating that

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message