On 6/16/16 8:42 AM, Kabir Khan wrote:
> On 16 Jun 2016, at 10:29, Kabir Khan <kabir.khan(a)jboss.com> wrote:
>> On 16 Jun 2016, at 10:29, Kabir Khan <kabir.khan(a)jboss.com> wrote:
>>> On 15 Jun 2016, at 23:19, Kabir Khan <kabir.khan(a)jboss.com> wrote:
>>> I have written up analysis/design notes for the new notification registrar
>>> My main doubt is about the usefulness of the
> The only reason this is there is it was there in Brian's original draft. I think
I'd like to remove it for now
Unless the intent is to do something along the lines of when something happens in
subsystem A to modify some resources elsewhere?
The reason for this is just that the only reason to receive a
notification is to in turn take some action. So unless whatever they
want to do has nothing to do with the rest of the system, they must:
1) Update the state of the MBeanServer, affecting JMX domains other than
jboss.as[.expr]. This kind of thing is what was specifically mentioned
by users in some of the discussions that led to this.
2) Take some action affecting the management resources, either via the
ModelController or via the jboss.as[.expr] mbeans. Perhaps deploy
3) Hack at MSC services via something like CurrentServiceContainer.
4) Update some state stored in static fields, which can then be read by
other code of theirs that has access to the field.
I think it's ok to not support 2) for now; we can see if people ask for
it with a concrete use case. That said I think it's not good if we can't
support it by making these notifications truly asynchronous to the
operation that spawns them. Not providing a ModelControllerClient isn't
going to block people using the jboss.as[.expr] mbeans, so the problem
still exists, it's just more hidden.
We don't want people doing 3) as its not a supported API. People who
want to do that should write a subsystem. Same with 4) although at least
there they aren't hacking our code, just their own.
>>> The NotificationRegistrarContext is used by
NotificationRegistrar.registerNotificationListeners(), which in turn is called by a
service's start() method. The service is installed by an add handler. Is my memory of
calling the ModelControllerClient execute methods at this stage a bad thing correct? I
mention that the MCC can be cached for later use by the handlers, which on one hand I
think should be ok since the handlers are executed on asynchronously,
>> Actually, WFCORE-1157 makes the server state lifecycle events synchronous, so the
above isn't 100% true
>>> but on the other hand having notification handlers mess around with the model
seems a bit strange as well.
>>> wildfly-dev mailing list
> wildfly-dev mailing list
wildfly-dev mailing list
Senior Principal Software Engineer
JBoss by Red Hat