commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Essl <>
Subject Re: [HiveMind] two step bootstrap?
Date Sat, 27 Sep 2003 22:13:36 GMT
A configurable Registry is a good idea. It would solve this 'chicken egg 
problem(s)' you mentioned last time concerning the rule-definition. I think 
that's a way hivemind should go. That's elegant. That's real bootstraping.

However I see two (minor) implementation problems. First I think it adds 
some complexity, the reason is that the Registry (and framework) code is 
one time in the 'configuration-registry' state and than in the 'user- 
registry' state. That's a general problem of bootstraping (why I normaly 
try to avoid it). Actually I think this could be solved easaliy for 
HiveMind - but I just don't know.

The second - more severe - problem is that the Registry is currently just 
not configurable (except of specifying the modules). So if you go this way 
you will have to make it configurable. (Please note I don't mean 
configuration by the user may be even during running state but by the 
framework itself in the single threaded bootstrap phase). Therefore I 
currently only see how the 'configuration-registry' can be used for 
specifying different module locations but I don't see how you could give in 
anything else (new rules, transformers, service-models etc).

I see mainly two ways to solve this: Either hack in as needed (is faster 
and keeps the current code more stable) or refactor the core and make it 
more hivminded - using core Services (that's more work, more testing, more 
failer-possibility, but more consistent and more looking forward). I mean I 
have suggested the second aproach, but I am glad that Howard stopped me, 
because its indeed a major refactor and it's a bit early for that.

But if we hack I think we could do (as I see) the most wanted - the 
defintion of rules,translators - with out the configuration-registry. I 
think we could use 'late-binding' of the rules in the schema. Keep the 
rules in a Map which initially only contains the current-rules.  Than as a 
first thing before the Registry is returned the BuilderFactory parses (only 
using the build in rules) a certain defined configuration-point from which 
additional rules are filled in the map. And than when the user parses the 
configuration points the schemas get the rules from the map. That's also 

On Sat, 27 Sep 2003 11:42:24 -0400, Harish Krishnaswamy 
<> wrote:

> Is this just to clean stuff up, or are there other advantages that I am 
> not seeing?
> -Harish
> Howard M. Lewis Ship wrote:
>> Just had an interesting thought.
>> What if bootstrapping the Registry was a two step process?
>> How about if we first built a Registry based on META-INF/hivemind- 
>> bootstrap.xml files.
>> The services and configurations for this Registry exist to set up the 
>> main bootstrap.
>> For example, there would be services and configuration points to guide 
>> the module location and
>> parsing, and to (for example) define the available translators and 
>> (potentially) the available XML
>> rules ... maybe even the different service models.
>> We could then reach into the bootstrap Registry for a service that would 
>> create the runtime
>> Registry. The Bootstrap registry is then discarded.
>> --
>> Howard M. Lewis Ship
>> Creator, Tapestry: Java Web Components
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Using M2, Opera's revolutionary e-mail client:

View raw message