[jboss-jira] [JBoss JIRA] Commented: (AS7-1994) access to the ModelNodeRegistration during handling of an operation and during deployment

[ https://issues.jboss.org/browse/AS7-1994?page=com.atlassian.jira.plugin.s... ] Stefano Maestri commented on AS7-1994: -------------------------------------- Brian said: Some thoughts before I start PTO again (I'm in the Beijing office today.) The exception happens because the OperationContextImpl enforces only updating the resource registry during stage MODEL. That's kind of arbitrary; I'll think about if it could be relaxed. It could be hacked around by not subclassing AbstractAddStepHandler but just implementing it's logic directly and calling context.getResourceRegistrationForUpdate() in the MODEL stage handler. Then use it later. Of course if I'd accept a patch with such a hack I should just remove the check for stage MODEL. The next question is the whole business of updating the resource registry from a service listener. The important thing is that operations acquire an exclusive lock on the ModelController. It's acquired when the first handler invokes any of the OperationContext methods that indicate the handler is going to mutate the model, the resource registry or the MSC services. (Read only ops don't acquired the lock.) It's released when that handler returns from execute(). Any mutation of the model/resource registry/MSC services must be done with that lock held. That semantic *must* be enforced; no patch that violates that will be accepted. This service listener approach doesn't necessarily violate that semantic. During stage VERIFY the thread executing the operation will block until the MSC service container is settled and all demanded services have started or failed. That *could* mean this listener will have been invoked. What has to happen is some logic to make sure this listener can't be invoked some other time. E.g. if the service is restarted; if the service is ON-DEMAND and isn't demanded, etc. If any of those things happen the listener should not mutate the registry. Hmm, that leads to the question of how this stuff gets cleaned up; e.g. what if the :reload operation is invoked? I think that should be ok, as the entire resource registry gets rebuilt. But, what's definitely missing is ManagedResourceRegistration.removeSubModel()/removeMetric()/removeOperationHandler(). There's no way for a "remove" handler to delete this stuff! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira