Juliano, As currently envisioned modifications to the registry after construction time, i.e. at runtime, would still not be possible. The new API is somewhat misleading in that respect which I think is another good reason to change it.
--knut On 1/24/07, Juliano Viana <[EMAIL PROTECTED]> wrote:
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
