brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ahgittin <>
Subject [GitHub] brooklyn-server pull request #873: Upgrade types and bundles as per bundle m...
Date Wed, 01 Nov 2017 17:47:14 GMT
GitHub user ahgittin opened a pull request:

    Upgrade types and bundles as per bundle manifest headers

    Follow on from #872 which actually applies the upgrade in most places.
    One known gap, and possibly some unknown gaps, but the main cases are working.
    Suggest revisiting post-YOML as that will make it easier to handle upgrades due to a single
instantiation path (instead of the many we currently have).

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

    $ git pull bundle-upgrade-actually-upgrade

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

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

    This closes #873
commit a3673e4baadf6054c738e97dd3aaa3f5cc29fcc2
Author: Alex Heneveld <>
Date:   2017-10-31T17:14:36Z

    store catalog upgrade instructions in osgi manager, with convenience in CatalogUpgrades

commit 8b470ae58e27d49d228b54613f8d8faca5d5d729
Author: Alex Heneveld <>
Date:   2017-11-01T11:31:42Z

    store catalog upgrades, and use when resolving persistence records
    catalog upgrades now stored in TypeRegistry, with conveniences for finding upgrades
    markers and comments for shifting to a "load registered type" semantics instead of "load
java type"
    still todo is use this when we come to deploy - as per other tests

commit 1453dbaadb20f108563335b082d54f247499a96d
Author: Alex Heneveld <>
Date:   2017-11-01T14:30:36Z

    look at upgrade targets if type or bundle not found when rebinding instances and when
    this addresses most the places i found in the course of several tests.
    there may well be others, and not all the places give good logging,
    but those can be improved in the fullness of time
    (and with yoml we have many fewer creation code paths so things get simpler!)
    one thing that isn't addressed is within a persisted entity spec;
    this unpacks the definition at deploy time and persists the unpacking,
    rather than persisting the given entity spec yaml for use later.
    i think this can be addressed later.



View raw message