Uploaded image for project: 'Brooklyn'
  1. Brooklyn
  2. BROOKLYN-605

Rebind historic persisted state: referencing wrap:mvn bundles

    XMLWordPrintableJSON

    Details

    • Type: Dependency
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 0.12.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      Aled's email 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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              kemitix Paul Campbell
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 1h 50m
                1h 50m