hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: hivemind impressions/comments/rant
Date Tue, 10 May 2005 12:40:18 GMT


> [..] 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).

I would distinguish between configuration and service like this:
- active component implementing business logic
- usually a singleton
- has dependencies on other services
- needs configuration data to work with

- passive data container
- multiple instances containing different data
- usually doesn't have any dependencies
- contribution is possible from different modules.

In deed configurations are just another kind of XML/java binding.
But HiveMind centralizes the binding code. The unwanted but often
found alternative is, that each services that needs configuration data
implements it's own file-handling, parsing, type conversion etc.

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

I'm successfully working without a one/jar one hivemodule by using
the submodule element. I use a central descriptor whose only
responsibility is the import of multiple descriptors that are defined
at package level and reside in the classpath:

<module id="start" version="1.1.0" >
     <sub-module descriptor="org/test/package1/module1.xml"/>
     <sub-module descriptor="org/test/package2/module2.xml"/>
     <sub-module descriptor="org/test/package3/module3.xml"/>

The central descriptor can be loaded from a Servlet-Filter
(like HiveMindFilter) for example.

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

Fully acknowledged


+++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++
GMX bietet bis zu 100 FreeSMS/Monat:

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

View raw message