As I see HiveMind is a cool combination of a very good configuration api and a good but improveable service-manager, which allows to split up your app in small components avoiding the uber-objects. My problem is that the Registry with all its impl helper classes is - while it is also currently well designed - just such a uber-object. It does everything from registring components, managing configuration, managing services ... and more to come. And this leads of course to all the disadvantes of uber-objects especially hard to understand, maintain and improve.
So I would suggest to do some refactoring. I suggest to make the Registry realy just a map of service-ids to ServicesExtendsionPoints and factor everything else out in a set of core services (an idea taken from JMX). This would look like this:
1.) Registry: ServiceExtensionPoints can be registerd and retrieved by id - except of some convinience-methods nothing else. It also builds up in the constructor the following core-services. For backward compatibility it also holds a map of Modules.
2.) ConfigurationService: is a map of ConfigurationPoints (like the registry again by id)
3.) DependencyService: keeps information about dependencies between services. It only holds the service ids. It does not 'manage' the services. It only gives information about dependencies.
4.) XMLParserService: takes a Location or a ClassResolver and produces a set of ModuleDescriptors
5.) ModuleLoaderService: Does generally what the RegistryBuilder does now. It takes a set of ModuleDescriptors and checks if everything is ok (references etc). Than adds ConfigurationPoints to the ConfigurationService, ServiceExtensionPoints to the Registry and dependencies to the Denpendency service.
6.) (may be: ShutdownService): manages a clean shut-down using the DependencyService (However I am not so sure how to implement this).
7.) (may be: EventService): fires core events (starting, adding modules, adding Configurations, shutdown etc).
In bootstrap the user first constructs a new Registry and than uses the XMLParserService and the ModuleLoaderService to add her modules. (Of course there should be static convinience methods).
As you can see I also suggest to remove this Module one to one mapping in the registry. That's because I think the module (contrary to eclipse) is more or less a convinient namespace declaration in the descriptor with an attached ClassLoader. When the system is running the modules-mapping is not realy needed anymore. If someone needs the module (Location in exceptions, the Classloader) the module can always be retrieved from the ExtensionPoint. This makes (first and most important) the code less complex, is more efficient (no double lookup for a service) and is less memory intensive. (If someone needs to lookup services or config-points by module I would suggest to add a search core-service, which could provide many more lookup possibilities - ie by Service interface, meta-information etc).
I also think this refactoring is not to hard to do. Most of the real taff stuff like XMLParsing, Rule processing, ServiceExtensionPointImpl etc can be reused straight away (As said HiveMind is also currently very well designed). Regarding backward compatibility for current Services and the bootstrapp process nothing realy changes . The BuilderFactory can be easily rebuild to be a helper which builds a Registry and just calls in the core- Services. The same also applies to the registry and the Module implementation. I love HiveMind it is realy cool and clever. It is also well designed and this is just a bit of a design-improvent (it does not add any functionlity). However I think this change is worth doing to make it easier for newbies (maybe comming from the JMX side) to understand and improve HiveMind. Therefore I want to do the changes if no one vetos.
I just want to you to ask if you think it is worth doing and if I can start coding or should wait a bit.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
