hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Wannheden <>
Subject Re: hivemind impressions/comments/rant
Date Tue, 10 May 2005 08:56:51 GMT

First off I'd like to say that this type of constructive critisism is
most appreciated.

On 5/10/05, Viktor Szathmary <> wrote:
> For simple dependencies, it's easy enough to set things up. The first
> dubious point is the distinction between services and configurations.
> IMHO this distinction really doesn't help at all: it doesn't add any
> value to introduce two concepts, where one would be sufficient. Both
> services and configurations are objects that get initialized via xml
> declarations and have dependencies. It's not clear to me, at what
> point a certain dependency should be a service or a config. A
> configuration seems to be necessary when I want to create a reasonable
> XML syntax (schema) for initializing objects of this kind later on
> (and even though you can make the xml for configurations look
> reasonable, they remain Lists which is an artifact that impacts the
> domain object model).

My first impression of HiveMind was also that this dichotomy of
services and configurations was sort of arbitrary. After all they are
in the end both mapped to POJOs... But after using HiveMind for a
while I got to appreciate this distinction. I define configurations
whenever I need to provide an extension point with which other modules
can affect the behaviour of "my" services.

As you say a configuration is nothing but a collection (in HiveMind
1.1 it can also be represented as a Map), but that only affects your
domain model in so far that it corresponds to a one-to-many

> I feel the XML configurations lack the simplicity and consistency
> that's crucial for developers to effectively use the framework. What
> would have been a few simple lines of java code (not to mention a
> scripting language) become tedious pages of XML. I feel HiveMind
> reinvents the XML/OO binding wheel once again, estabilishes it's own
> schema language, variable substitutions etc. IMHO this is a critical
> issue. It would be better to promote the Java based dependency
> management APIs and expose them to direct manipulation, scripting
> languages and your favorite java/xml binding framework, rather than
> trying to reinvent this. Madness lies this way, and you can already
> see the numerous dead corpses on the roadside :) - think Jelly, the
> numerous wretched xml/oo mappers that would be best to forget, etc..

IMHO the Hivemind "module descriptor language" is very well conceived
in that the descriptors are very concise and crisp. Yet I agree with
you that it would be good with a Java API to let you do the same thing
in other ways (be they more verbose or more succinct). This topic is
being discussed right now on the developer mailing list (see
Please join in on this if you have any concrete (or vague) ideas /
opinions on this topic.

> Registry initialization should be more flexible and support different
> deployment scenarios that are not one jar/one hivemodule. A common
> real-world example is environment-specific configurations. The
> approach I implemented was a custom registry initialization sequence,
> that after addDefaultModuleDescriptorProvider(), finds a
> "hivemind.registry" in the classpath, and loads the further
> hivemodules listed there (these are simple resource URIs that look
> like classpath:/com/example/foo.xml or
> file:/foo/myproject/config.xml), then loads further config resources
> that were programmatically added (eg. from a testcase setUp()). I feel
> this should be part of the framework - if you're interested I can send
> the corresponding code.

Would it help if the META-INF/hivemodule.xml mechanism were
supplemented with a system property defining a list of descriptor
URIs? I would be hesitant to add another configuration file with its
own syntax.

I'd also be interested in how your code initializes the registry.

> Documentation needs to be more example-based (at the least give more
> guidance on where in the reference to look for things). It's a real
> headscratcher to figure out some of the functionality that is clearly
> there (jndi, ejb remoting, etc). Guidelines/best practices should be
> focused on.

This is definitely something we need to improve upon. There are some
good examples on the HiveMind site. I think we should promote these to
the front page (even in front of the reference documentation) and
enrich them with links to specific pages in the reference works. Other



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

View raw message