Hello,
A while ago I started working on an extension to Hivemind that would
provide a web-based GUI for editing service properties and
configurations at runtime. At the time i figured out that it would be
difficult to do so because of the static nature of the registry. I
managed to produce something that worked by advising the registry using
aspects, but I decided to wait until 2.0 was developed in order to try
doing this again. Having a mutable registry can be something very useful
in some applications (like implemented the concept of a "distributed"
registry) but I understand that it can become overly complex.
- Juliano.
Knut Wannheden wrote:
Hi all,
I just took a look at the new registry construction API in the 2.0
proposal. I think it looks very good but one thing I'd like to discuss
is the mutability requirements. I'm talking about the various addXxx()
methods and the fact that some Collection objects returned by some
getters must be mutable. Specifically I'd like to discuss if the
mutability in the API is needed and / or desired.
From what I can work out the mutability of the module definitions is
used by HiveMind for the following things:
1. Module definition construction -- The actual implementations of the
API can use the addXxx() methods to construct the actual module
definition.
2. Merging "hivemind" module definition -- If the user is using the
optional XML support in HiveMind then HiveMind will during registry
construction merge definitions for the "hivemind" module from the
hivemodule.xml file in the XML module with the plain Java definitions
in the framework module. (Note that this is a specific case of the
former usage described.)
3. Extension resolving -- During registry construction HiveMind will
"move" any extensions (service implementations, service interceptors,
contributions, and the new configuration parsers) which have been
registered at the module level to the appropriate extension point by
removing it from the respective module's collection (returned by a
getXxx() method) and add it to the extension using an addXxx() method.
I hope I didn't miss anything now.
IMHO it would be great if we could drop the mutability requirements
and thus both simplify the API and make it easier to write an
implementation for it. One use case I had in mind is something James
mentioned: mapping a Spring application context to a HiveMind module.
Any other opinions on this one?
Regards,
--knut
