On Oct 19, 2007, at 9:25 AM, Lloyd L Chambers wrote:
> 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.
probably not an issue but if we could generalize the concept of
batching config changes and then streamline the notification process
once the batch is finished (without necessarily entering the
transactional complexity), it might be worth investigating.
It may be ok in v2 that we can get several events for each affected
object, and we can continue like that worse case, however it would be
safer as a client code to register interest in a group of object and
only get notified of changes once that group has finished changing.
>
>
> 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
>
>
>