brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From neykov <>
Subject [GitHub] incubator-brooklyn pull request: Sensors chained for service up
Date Fri, 29 Aug 2014 16:32:51 GMT
Github user neykov commented on a diff in the pull request:
    --- Diff: core/src/main/java/brooklyn/entity/basic/ ---
    @@ -123,23 +137,29 @@ public AbstractApplication setParent(Entity parent) {
         public void start(Collection<? extends Location> locations) {
             Collection<? extends Location> locationsToUse = getLocations();
    -        setAttribute(Attributes.SERVICE_STATE, Lifecycle.STARTING);
    +        ServiceProblemsLogic.clearProblemsIndicator(this, START);
    +        ServiceStateLogic.setExpectedState(this, Lifecycle.STARTING);
    +        ServiceStateLogic.ServiceNotUpLogic.updateNotUpIndicator(this, Attributes.SERVICE_STATE_ACTUAL,
"Application starting");
             try {
    +            // if there are other items which should block service_up, they should be
done in preStart
    +            ServiceStateLogic.ServiceNotUpLogic.clearNotUpIndicator(this, Attributes.SERVICE_STATE_ACTUAL);
             } catch (Exception e) {
    -            setAttribute(Attributes.SERVICE_STATE, Lifecycle.ON_FIRE);
    +            // TODO should probably remember these problems then clear?  if so, do it
here ... or on all effectors?
    +//            ServiceProblemsLogic.updateProblemsIndicator(this, START, e);
    --- End diff --
    Does "recordApplicationEvent(Lifecycle.ON_FIRE);" change SERVICE_STATE_EXPECTED? How is
it marked ON_FIRE atm?

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message