I gave this another thought yesterday while relaxing on the beach. HiveMind doesn't have a way to redeploy because a descriptor changed. That wasn't on e of the problems I wanted to solver with HiveMind initially.
It's a complicated problem, because the very nature of HiveMind is to intertwine services. Service A may use configuration B that includes a bean obtained from service C that is itself driven by configuration D. If a contribution to service D changes, how does that affect service A? I suppose, in theory, you could do some tricky forward chaining so that a change to configuration D will be identified a propagated forward, invalidating service C and configuration B and ultimately service A. You could then have the proxy for service A somehow obtain a new instance that reflects the change to configuration D.
What are you willing to pay for that? The CPU and memory expense of determining what has changed and what is affected looks prohibitive to me. Something would have to poll for changes to the modules, re-parse the module descriptors, rebuild the various module descriptors, and send notifications to proxies and other objects.
The thing is, HiveMind is supposed to be light and fast. I have always pictured HiveMind running inside an EAR. When the EAR is redployed, the old HiveMind Registry is shutdown and a new HiveMind Registry is created and started to replace it. During development, just bounce your application (i.e., restart Jetty). I'm doing this today on my current project, and it's not a great imposition ... just a couple of seconds to stop and restart. The Jetty Launcher plugin makes it a single click.
So I'm still filing this under YAGNI(You Aint Gonna Need It).
The blog is the wrong place. hivemind-user@jakarta.apache.org is the right place. Details on subscribing on the web site.
ReplyDelete