Hold off for a bit until I get a grasp of where you're headed.
Thank you for your answer and sorry that I did not realy make so clear what it is good for. My suggestion may look big but is rather small.
I'm concerned about some lifecycle issues; especially maintaining good support for contributions and
substitution symbols.
Sorry that I did not make clear that I did not suggest any additional functionality like late(r) loading of modules. I just wanted to suggest some refactoring which makes the addition of new functionalities to the core easier - like late loading of mudules. Ie for now the ModuleLoaderService would just allow to be called once and later this might be changed. I think the current enforcment of a closed Registry through the api just hinders furhter evolution of the Service management. Currently it is also not so clean to add ie a DependencyService - needed for clean shut- down - or as you suggest a service which manages transformers.
When I say core services, I do not mean services which are loaded like 'normal' services through an xml description. I mean simple Singletons which are directly constructed by the Registry and which are registered in the Registry just to be accesible like normal Services. Core-services are also not meant to be independent normal services. They are part of the core, are dependent on each other and are integrated with the core. In my view they are just a standard mean of extending the core in a HiveMinded fashion. I think that fits better in the overall HiveMind way.
As said I have not realy thought of late loading of modules. However as I see regarding services its not realy a problem. Concerning contirbutions its a bit more complicated. I would say that the new ConfigurationService just fires events when new contirubtions are added to an extension point. (But that's certainly not the whole story.)
You add module A and module B and build some services; then add module C which makes contributions
that affect the services in A and B ... the current "lock down" design ensures consistency.
I was thinking in the shower about some issues; that it would be nice to build even more of HiveMind
in HiveMind; for example, be able to make a <contribution> to define new rules and translators,
rather than making them (basically) statically defined. I kept treading down some chicken-or-the-egg
bootstrap problems.
That's an excellent idea and also a good example for me. Make a core- service (RuleTranslatorService) and change ModuleLoaderService that it does as first thing give the ModuleDescriptors to the RuleTranslatorService. The RuleTranslatorService than scans all the Contributions for well defined ids (nameing the rules and translators), removes them from the description and adds to itself the translators. The ConfigurationPointImpl will than use the RuleTranslatorService.
At the same time, I'd like to know about the use cases you feel could be addressed better,
especially from the point-of-view of a HiveMind user.
I don't suggest additional functionality so also no new use-cases for the user. The main additional functionality I want to build on top of this is a clean shut-down process (without it no ConnectionPools -> no DAOs -> no need for TransactionInterceptors; also security checking will need some Resource-Service to identify users and their permissions). For doing that I looked at JBoss-JMX which inspired this. I looked at JBoss because as I see it is currently the functionally most advanced open Service-Manager and JMX is a good specification - but just not thought as a ServiceManager.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
