I assume this would mean that jmx styled applications or configuration apps would then have to restart hivemind or manually dump their new configurations to disk in order for any mutable changes to take place? My current client, a very large, very French oil service industry company, has an existing Avalon-based framework that allows these changes to be made dynamically, but essentially does nothing more than store them until the container is restarted. Only then do the changes become live.
A built-in mechanism for doing so would be greatly appreciated (as I'm attempting to move for replacing their "homegrown" solution with HM 2.0). :) On 1/24/07, Knut Wannheden <[EMAIL PROTECTED]> wrote:
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 > >
-- Gotta find my destiny, before it gets too late.-- Ian Curtis
