Re: [wildfly-dev] Service assumptions and the web profile

On 3 Jun 2014, at 22:01, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >> One obvious question with this scheme is: what happens when Y is added, >> after the fact? The answer to this question depends on X. X must, in >> the same transaction, detect the addition of Y and decide what to do. >> Several actions are possible, depending on how X works and how its >> dependency on Y works. Options include automatically removing and >> rebuilding services with the new dependency, retroactively modifying X >> in some way so as to update it without stopping it, or simply ignoring >> the addition of Y, using a "reload-required" or similar state to >> indicate to the user that the running system is inconsistent with the >> stored model. >> >> I know we don't really have any APIs to directly facilitate these >> concepts, but this is a part of what the management SPI redesign is all >> about. In the new model, one will be able to express optional >> dependencies at a resource level rather than a service level. > > Jeff Mesnil -- I'm curious how useful the internal notification stuff > you've added in the existing code will be for this use case. Prior to > that there was nothing at all that X could count on to become aware of > the later addition Y. Notifications would work a the resource level. Notifications for added/removed resources are emitted[1] at the end of the step that adds/removes a resource in the MODEL stage. So a resource X could register a notification listener on the resource Y's path address. When the Y resource is added, the listener will be notified and X would be notified of the addition of Y and act accordingly. If I understand the example correctly, when a resource X is added, it could check whether the resource Y is already there and use it if that’s the case. Otherwise, it would register a notification listener and postpone this execution until the resource Y is added (with no guarantee it ever will). [1] https://github.com/jmesnil/wildfly/commits/WFLY-266_WFLY-3159_notificatio... -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev