[jira] [Commented] (BROOKLYN-605) Rebind historic persisted state: referencing wrap:mvn bundles

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/BROOKLYN-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16659409#comment-16659409 ] 

ASF GitHub Bot commented on BROOKLYN-605:
-----------------------------------------

GitHub user kemitix opened a pull request:

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

    [WIP] BROOKLYN-605 rebind fails for historic state

    

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

    $ git pull https://github.com/kemitix/brooklyn-server BROOKLYN-605-rebind-fails-for-historic-state

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

    https://github.com/apache/brooklyn-server/pull/1010.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 #1010
    
----

----


> Rebind historic persisted state: referencing wrap:mvn bundles
> -------------------------------------------------------------
>
>                 Key: BROOKLYN-605
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-605
>             Project: Brooklyn
>          Issue Type: Dependency
>    Affects Versions: 0.12.0
>            Reporter: Paul Campbell
>            Priority: Major
>
> Aled's [email|https://markmail.org/message/rgxv6sask2sbrcff] from the dev mailing line :
>  
> Hi all,
> TL;DR: I've hit a problem with rebinding to historic persisted state, 
> when wrap:mvn has been used for OSGi bundles - the symbolic name 
> changed, so classloading didn't work on rebind. Which of the solutions 
> should we go for?
> _*PROBLEM*_
> The persisted state refers to a class in aws-java-sdk 1.11.245, but in 
> my newer brooklyn I've upgraded this bundle to 1.11.411 (the old bundle 
> is not there). Because this jar was added using wrap-mvn, the two 
> versions of the bundle have different symbolic names! Brooklyn therefore 
> doesn't know to look in the newer aws-java-sdk bundle.
> The bundle was added via a feature.xml containing:
> <bundle>wrap:mvn:com.amazonaws/aws-java-sdk-bundle/${aws.java.sdk.version}</bundle>
> When built locally, this produced a bundle with the very strange 
> symbolic name:
> wrap_file__Users_aledsage_amp_cloudsoft-amp-karaf-5.2.0_system_com_amazonaws_aws-java-sdk-bundle_1.11.245_aws-java-sdk-bundle-1.11.245.jar
> _*EXISTING FUNCTIONALITY*_
> Brooklyn currently supports a couple of related features:
>  1. The persisted state will by default not include bundle versions. We
>     are therefore willing to use newer versions of a given bundle.
>  2. When adding your own bundle, you can include metadata in it's
>     MANIFST.mf to say what bundle/version it replaces.
>     See brooklyn-docs guide/ops/upgrades/_blueprints.md
> However, I don't want to use (2) because that would involve fiddling 
> with the wrap:mvn to add more metadata.
> _*POSSIBLE SOLUTIONS*_
> There are no doubt many ways to solve this problem. I describe a few of 
> them below.
> I think I favour the class-renames approach because of its simplicity.
> *_Add support to class-renames_*
> Our deserializingClassRenames.properties allows rebind to handle class 
> renames, or a specific class moving from one bundle to another. This is 
> useful for historic persisted state.
> We could add support for bundle wildcards, to say that all classes in 
> one bundle can be loaded from another bundle.
> For example:
>      wrap_blah_aws-java-sdk-bundle-1.11.245.jar\:*  : 
> wrap_blah_aws-java-sdk-bundle-1.11.411.jar\:*
> *_Support a bundle-upgrade configuration file_*
> We could add support for a config file that gives explicit named bundle 
> replacements. This would augment the existing functionality (2 above), 
> but instead of the replacement bundle being defined in the new bundle's 
> metadata, it could also be defined in this configuration file.
> For example, $BROOKLYN_HOME/etc/org.apache.brooklyn.bundleupgrade.cfg 
> could contain something like:
>      wrap_blah_aws-java-sdk-bundle-1.11.411.jar:
>        Brooklyn-Catalog-Upgrade-For-Bundles: 
> "wrap_blah_aws-java-sdk-bundle-1.11.245.jar: *"
> (would need to figure out the cfg versus yaml format here, obviously!)
> *_Recognise 'wrap' bundles, and allow newer versions_*
> When loading the class, we could recognise the "wrap_" prefix. We could 
> figure out from the symbolic name what it was built from, and be willing 
> to use bundles that are newer versions.
> However, playing with wrap:mvn, the bundle naming is not as obvious as 
> one would expect. The symbolic name below is a very different structure 
> from that above:
> wrap_mvn_com.example.brooklyn.test.resources.osgi_brooklyn-test-osgi-com-example-plainoldjar_1.0.0
> This example was created in karaf client by running:
>      bundle:install 
> wrap:mvn:com.example.brooklyn.test.resources.osgi/brooklyn-test-osgi-com-example-plainoldjar/1.0.0
> See brooklyn-server's 
> org.apache.brooklyn.util.core.ClassLoaderUtils.tryLoadFromBundle.
> *_Require users to set the symbolic name, when using wrap:mvn_*
> We could require users to *not* use the simple "wrap:mvn", and instead 
> force them to ensure a more predictable symbolic name + version is used.
> However, that sounds harder for users. It also doesn't solve the problem 
> for anyone with such historic persisted state.
> _*LONG TERM / DOCS
> *_We should warn people about this in our docs, including a description 
> of how to work around it.
> We should discourage the use of complex types in config keys and 
> sensors, where we (or the user) don't explicitly control the versioning 
> and schema of those types.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)