Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.0
    • Fix Version/s: 3.0.2
    • Component/s: osgi
    • Security Level: public (Regular issues)
    • Labels:
      None

      Description

      ConfigurationActivator needs it's stop method to shut down the plugin.

      Calling configurationManager.unload(id) is symmetrical with start and should leave the configuration model in a consistent state, but resets the load attribute in config.xml to false, which prevents restarting the server.

      Just stopping and unloading the configuration gbean works fine but may leave the configuration model (in the configuration manager) in an inconsistent state.

      This needs further investigation.

        Issue Links

          Activity

          Hide
          Ivan added a comment - - edited

          From the beginning, we are trying to match the Configuration lifecycle to the bundle lifecycle, it brought us too much issues. Since currently Geronimo Kernel is still there, shall we treat them separately.
          While starting the bundle, preload the ConfigurationData, the most reason to do this is for having a chance to mantaine an artifactid -> bundleContext map, if there is another way to do it, we would do nothing.
          While the bundle is active, we could do any configuration lifecycle operations, it will not affect the bundle's status, it only changes Geronimo repository.
          While stopping the bundle, we also stop/unload the configuration.
          While uninstalling the bundle, we will stop/unload/uninstall the configuration.
          Just an idea, not sure anything importand is missing

          Show
          Ivan added a comment - - edited From the beginning, we are trying to match the Configuration lifecycle to the bundle lifecycle, it brought us too much issues. Since currently Geronimo Kernel is still there, shall we treat them separately. While starting the bundle, preload the ConfigurationData, the most reason to do this is for having a chance to mantaine an artifactid -> bundleContext map, if there is another way to do it, we would do nothing. While the bundle is active, we could do any configuration lifecycle operations, it will not affect the bundle's status, it only changes Geronimo repository. While stopping the bundle, we also stop/unload the configuration. While uninstalling the bundle, we will stop/unload/uninstall the configuration. Just an idea, not sure anything importand is missing
          Hide
          David Jencks added a comment -

          Configurations have more, or at least different, states than bundles expose through BundleActivator:

          bundles plugins
          resolved plugin installed
          started configuration gbean started
          ------ configuration gbeans started

          Whether starting the configuration gbean should automatically start the gbeans in the configuration is stored in the load alse in config.xml. Normally, stopping the configuration gbeans will indicate to geronimo that you want this attribute set to "false".

          If you stop a plugin bundle, you definitely want to stop the gbeans first. However, if you are shutting down the server, you don't want to change the attribute values.

          In general we need a better way to deal with this extra state.

          Show
          David Jencks added a comment - Configurations have more, or at least different, states than bundles expose through BundleActivator: bundles plugins resolved plugin installed started configuration gbean started ------ configuration gbeans started Whether starting the configuration gbean should automatically start the gbeans in the configuration is stored in the load alse in config.xml. Normally, stopping the configuration gbeans will indicate to geronimo that you want this attribute set to "false". If you stop a plugin bundle, you definitely want to stop the gbeans first. However, if you are shutting down the server, you don't want to change the attribute values. In general we need a better way to deal with this extra state.
          Hide
          Rex Wang added a comment -

          If stopping the bundle causes load=false set, so does shutting down server. But, should load=false bind with bundle(plugin) stoped? IIUC, a geronimo plugin is a specific osgi bundle that can be discovered by geronimo extender, and "load=false" can be consider as an attribute tell "will the bundle start autoly?", which definitely under control of our extender.

          -Rex

          Show
          Rex Wang added a comment - If stopping the bundle causes load=false set, so does shutting down server. But, should load=false bind with bundle(plugin) stoped? IIUC, a geronimo plugin is a specific osgi bundle that can be discovered by geronimo extender, and "load=false" can be consider as an attribute tell "will the bundle start autoly?", which definitely under control of our extender. -Rex
          Hide
          Rick McGuire added a comment -

          When a configuration bundle is constructed, are headers added to the manifest with important metadata (such as the artifact id)? This would make it fairly simple to determine this type of mapping without needing to keep a side table of the information.

          Show
          Rick McGuire added a comment - When a configuration bundle is constructed, are headers added to the manifest with important metadata (such as the artifact id)? This would make it fairly simple to determine this type of mapping without needing to keep a side table of the information.
          Hide
          Rick McGuire added a comment -

          I think the blueprint model maps pretty closely to what's going on here, with the addition of being able to explicitly start/stop the Gbean context of a given bundle. With the blueprint model, a bundle can have the states stopped, started with BlueprintContainer active, and started with no Blueprint Container active. The last state can only occur if there is a startup error or the extender is shutdown. I think it makes a lot of sense to allow the framework to manage the bundle state, and the Geronimo kernel (extender?) manage the configuration state as separate entities.

          Show
          Rick McGuire added a comment - I think the blueprint model maps pretty closely to what's going on here, with the addition of being able to explicitly start/stop the Gbean context of a given bundle. With the blueprint model, a bundle can have the states stopped, started with BlueprintContainer active, and started with no Blueprint Container active. The last state can only occur if there is a startup error or the extender is shutdown. I think it makes a lot of sense to allow the framework to manage the bundle state, and the Geronimo kernel (extender?) manage the configuration state as separate entities.
          Hide
          Shawn Jiang added a comment -

          Normally, stopping the configuration gbeans will indicate to geronimo that you want this attribute set to "false".

          If you stop a plugin bundle, you definitely want to stop the gbeans first. However, if you are shutting down the server, you don't want to change the attribute values.

          Can we just separate the (load=)attribute setting from the lifecycle ? IMO, It's not a part of lifecycle, if the user want set (load=) to true/false, there should be explicitly API to call but not just an indicating action during config stop lifecyle.

          Show
          Shawn Jiang added a comment - Normally, stopping the configuration gbeans will indicate to geronimo that you want this attribute set to "false". If you stop a plugin bundle, you definitely want to stop the gbeans first. However, if you are shutting down the server, you don't want to change the attribute values. Can we just separate the (load=)attribute setting from the lifecycle ? IMO, It's not a part of lifecycle, if the user want set (load=) to true/false, there should be explicitly API to call but not just an indicating action during config stop lifecyle.
          Hide
          Ivan added a comment -

          Not sure whether we have conclusion for this, I would like to add the operations of removing bundle in the unloadConfiguration method first, for currently, while undeploying the applcations, the bundle is still there. Thoughts ?

          Show
          Ivan added a comment - Not sure whether we have conclusion for this, I would like to add the operations of removing bundle in the unloadConfiguration method first, for currently, while undeploying the applcations, the bundle is still there. Thoughts ?

            People

            • Assignee:
              Unassigned
              Reporter:
              David Jencks
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development