brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aledsage <...@git.apache.org>
Subject [GitHub] brooklyn-server pull request: Winrm4j upgrade
Date Fri, 25 Mar 2016 00:31:05 GMT
GitHub user aledsage opened a pull request:

    https://github.com/apache/brooklyn-server/pull/81

    Winrm4j upgrade

    Also see the commit "softwareProcess.restart: even on error, set expected=running", and
the details in that commit description.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/aledsage/brooklyn-server winrm4j-upgrade

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/brooklyn-server/pull/81.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #81
    
----
commit da26fb2a99b334dc8a9b8dc10d9bd960477c0c3e
Author: Aled Sage <aled.sage@gmail.com>
Date:   2016-03-25T00:26:30Z

    Tidy test imports
    
    Use com.google.common.collect instead of org.testng.collections

commit 4cad1009ec3d3ca89cc51b656f3613556bdfb1c1
Author: Aled Sage <aled.sage@gmail.com>
Date:   2016-03-25T00:26:49Z

    Upgrade winrm4j to 0.3.3

commit d08cda63f0d217a89937e7612988c46ab455d0c1
Author: Aled Sage <aled.sage@gmail.com>
Date:   2016-03-25T00:27:08Z

    deserializingClassRenames: include TestEntity etc

commit a0418bfb4805c2f1443e2077d9362127e644ff1f
Author: Aled Sage <aled.sage@gmail.com>
Date:   2016-03-25T00:29:51Z

    softwareProcess.restart: even on error, set expected=running
    
    Previously if the restart failed in some way (e.g. an error in the 
    launch script or a timeout waiting for serviceUp), we would leave the 
    expectedState as “starting”. This meant that serviceUp=false was not
    rendered as an error.
    
    Always setting expected=running is better, but is not great. For 
    example, if a script fails in restart then we won’t mark the 
    entity as onFire if the basic service-up checks still pass. This is
    different from the start() behaviour. But then we are doing less than
    in start (e.g. in start a script failure could mean that a WAR was not
    installed so the simple serviceUp reachability check would not be
    sufficient if customize() had failed).

----


---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message