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
