Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-18417

Enabled plugins that are disabled by default don't stay enabled after Confluence upgrades

      To reproduce:

      1. Start Confluence 3.0
      2. Find a bundled plugin that is disabled by default (i.e. Mail Page Plugin)
      3. Upgrade it to the latest version (1.8)
      4. Enable the plugin
      5. Upgrade Confluence to 3.1
      6. The plugin is disabled.

      You can fix the problem, since as soon as you restart Confluence the plugin is disabled again.

            [CONFSERVER-18417] Enabled plugins that are disabled by default don't stay enabled after Confluence upgrades

            Ah right, I understand, ok here's what happens:

            1. The Bundled Plugins Classloader runs and installs the the mail page plugin. It respects the value stored in bandana.
            2. The Database Plugins Classloader then runs, finds the mail page plugin in the database and runs an upgrade.
            3. During the upgrade the classloader will disable the existing plugin.
            4. After the plugin is updated, the database plugin state store is restored to the plugin's original state (in this case to enabled).
            5. However the local state store is not.
            6. So when, the plugin manager comes to actually install the plugin, this piece of code fails:
              plugin.install();
              boolean isPluginEnabled = getState().isEnabled(plugin);
              if (isPluginEnabled)
              {
                  pluginsToEnable.add(plugin);
              }
              

            So in terms of the test, I just created two mock class loaders to simulate an upgrade.

            Brian Nguyen (Inactive) added a comment - Ah right, I understand, ok here's what happens: The Bundled Plugins Classloader runs and installs the the mail page plugin. It respects the value stored in bandana. The Database Plugins Classloader then runs, finds the mail page plugin in the database and runs an upgrade. During the upgrade the classloader will disable the existing plugin. After the plugin is updated, the database plugin state store is restored to the plugin's original state (in this case to enabled). However the local state store is not. So when, the plugin manager comes to actually install the plugin, this piece of code fails: plugin.install(); boolean isPluginEnabled = getState().isEnabled(plugin); if (isPluginEnabled) { pluginsToEnable.add(plugin); } So in terms of the test, I just created two mock class loaders to simulate an upgrade.

            I'm not suggesting that you should restart in your test I'm trying to understand what it is about the restart that causes the problem and wanted to make sure you where doing it in your test. I was expectig a second init or something but didnt see it.

            m@ (Inactive) added a comment - I'm not suggesting that you should restart in your test I'm trying to understand what it is about the restart that causes the problem and wanted to make sure you where doing it in your test. I was expectig a second init or something but didnt see it.

            The only way to simulate the same process is to perform an upgrade and restart confluence. Since we don't have that framework available, I did the next best thing and wrote a unit test.

            Brian Nguyen (Inactive) added a comment - The only way to simulate the same process is to perform an upgrade and restart confluence. Since we don't have that framework available, I did the next best thing and wrote a unit test.

            I think (after discussing with anatoli) the problem was caused because we weren't updating the correct plugin storage, and now you are. Please put a summary on your issues so the reviewer (who may not know anything about what you are doing) has a chance to understand the issue and your fix without having to read all the code around it.

            I see a test but I don't see any simulation of a an upgrade which your issue description talks about.

            m@ (Inactive) added a comment - I think (after discussing with anatoli) the problem was caused because we weren't updating the correct plugin storage, and now you are. Please put a summary on your issues so the reviewer (who may not know anything about what you are doing) has a chance to understand the issue and your fix without having to read all the code around it. I see a test but I don't see any simulation of a an upgrade which your issue description talks about.

            m@ (Inactive) added a comment - https://atlaseye.atlassian.com/changelog/confluence/?cs=106863

            Anatoli added a comment -

            Brian has mistyped the issue number in his commit message. This is the changeset.

            Anatoli added a comment - Brian has mistyped the issue number in his commit message. This is the changeset .

            This issue has no commits, if it has been committed against the wrong issue please link to the change set, or commit the changes so they can be reviewed.

            m@ (Inactive) added a comment - This issue has no commits, if it has been committed against the wrong issue please link to the change set, or commit the changes so they can be reviewed.

            Anatoli added a comment -

            Matt, this review will help you to get familiar with the code as it is the same part of the system as in [the cluster problem|CONF-18241]

            Anatoli added a comment - Matt, this review will help you to get familiar with the code as it is the same part of the system as in [the cluster problem|CONF-18241]

              bnguyen Brian Nguyen (Inactive)
              bnguyen Brian Nguyen (Inactive)
              Affected customers:
              0 This affects my team
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: