[wildfly-dev] Service assumptions and the web profile

[Kabir Khan]

Another issue would be if service A has an optional dependency (as described, not using the actual optional dependency) on service B.
We’re describing allowing A to react if B shows up. Should we also react if B goes away?

On 4 Jun 2014, at 13:39, Jeff Mesnil <jmesnil at redhat.com> wrote:

> 
> On 3 Jun 2014, at 22:01, Brian Stansberry <brian.stansberry at redhat.com> 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_notification_support_and_jmx#diff-889ac0c285b120937da9477f6d61ab1dR689
> -- 
> Jeff Mesnil
> JBoss, a division of Red Hat
> http://jmesnil.net/
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev