[jboss-as7-dev] Add Notification support to the domain management API

[Brian Stansberry]

On 2/15/13 10:36 AM, Jeff Mesnil wrote:
>
> Le 14 févr. 2013 à 23:42, Brian Stansberry <brian.stansberry at redhat.com> a écrit :
>
>> Just some basic categories of use cases:
>>
>> 1) Internal to the server. See usage of ControlledProcessStateService
>> for an example. It's essentially a notification emitter for a couple
>> specific management events.
>>
>> A lot of internal to the server use cases though might be better done
>> with services though. For example, say a service injects a
>> SocketBindingService to learn it's socket configuration during start.
>> Then that service wants to listen for notifications of changes to the
>> socket binding config. Is it better off listening for messages from a
>> generic notification mechanism, or should the SocketBindingService
>> itself generate events?
>
>
> In this case, I'd still use a generic notification mechanism. The SocketBindingService will have its configuration changes through calls to :add/:remove/:write-attribute operations in any case, right?
> The service that injects a SocketBindingService could register a listener on the SBS's path address and be notified on any config changes.
>
> I think we could also allow any resource (or service) to generate well-defined notifications too (e.g. when a host joins/leaves a domain) but notifications from :add/:remove/:write-attribute could cover most of the use cases.
>

There's a distinction though between a model change and a runtime 
change. If I change some attribute on a management resource, that may or 
may not be relevant to currently running services. Quite often there is 
no runtime change other than the process is put into reload-required state.

We need to be very careful about this distinction. If listeners are 
added for model changes that incorrectly assume there's an equivalent 
runtime change, and then the listener goes and changes its own runtime, 
that's where we can have problems.

Perhaps a generic management notification API is still the right way to 
handle this, just with extra information in the event that describes the 
runtime impact. I haven't thought about how hard that would be to do 
with the current management infrastructure.

You're on the right track asking about use cases. What is the listener 
hoping to achieve by getting a notification?

-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat