Jerome,
Today's V2 configuration works to my satisfaction, and I’m not aware
of any complaints in regards to changing multiple areas of
configuration.
In V2, changing configuration across multiple distinct configuration
objects ( eg MBeans corresponding to domain.xml elements) does indeed
cause a reconfigure even for each affected object.
I don't see how the same behavior in V3 would suddenly become an issue.
Lloyd
On Oct 19, 2007, at 4:18 AM, Jerome Dochez wrote:
>> Allowing arbitrary changes across an entire module config
>> hierarchy is complicated, but perhaps even more so for the module
>> writer, who might then have to accommodate wholesale changes to
>> multiple running threads/services of that module. So I don't
>> think that is a worthwhile goal, though we shouldn't preclude
>> being able to do it in the future.
>
> right, the thing that stresses me the most if we support only the
> happy medium if the flow of change events generated when such
> config hierarchy is changed. I really don't want to get into a
> pattern where we have behavior elements react to individual config
> element change because the notifications become noisy and you end
> up reconfiguring yourself multiple time.
>
> so something like behaviorA that uses configA, B and C
> on configA, set, set,set --> notification sent --> behaviorA
> reconfigure
> on configB, set, set,set --> notification sent --> behaviorA
> reconfigure
> on configC, set, set,set --> notification sent --> behaviorA
> reconfigure
>
> this use case would be worth investigating without trying to
> implement the transaction support.
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc