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

On 2/15/13 10:36 AM, Jeff Mesnil wrote: > > Le 14 févr. 2013 à 23:42, Brian Stansberry <brian.stansberry(a)redhat.com&gt; 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?