Geronimo
  1. Geronimo
  2. GERONIMO-5764

Support Bundles Deployment in deployment command line

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.0.0
    • Fix Version/s: 3.0.0, 3.0.1
    • Component/s: commands, console, deployment
    • Security Level: public (Regular issues)
    • Labels:
      None

      Description

      Now we have to deploy a regular bundle via karaf shell: osgi:install file:/[bunlde_path], not deployer command line, so open this jira to track this feature enablement.

      1. GERONIMO-5764-record-bundle.patch
        81 kB
        Rex Wang
      2. GERONIMO-5764-install-uninstall-bundle.patch
        51 kB
        Rex Wang
      3. GERONIMO-5764-install-bundle.patch
        109 kB
        Rex Wang
      4. GERONIMO-5764.patch
        54 kB
        Rex Wang

        Issue Links

          Activity

          Hide
          Shawn Jiang added a comment -

          Besides "deploy install-bundle" command, we might need a "deploy list-bundles" for normal command line.

          So that the user don't have to enter karaf shell to do the simple job. thoughts ?

          Show
          Shawn Jiang added a comment - Besides "deploy install-bundle" command, we might need a "deploy list-bundles" for normal command line. So that the user don't have to enter karaf shell to do the simple job. thoughts ?
          Hide
          viola.lu added a comment -

          Lower priority

          Show
          viola.lu added a comment - Lower priority
          Hide
          David Jencks added a comment -

          I think this is a lot harder than it looks. We need some way to keep track of the bundle we deployed so that it can be restarted if the cache is cleared. IIUC this is not what osgi:install does. Also I think our deployer system should accept bundles and just start them (persistently). This will be much easier after ivan's work to line up configuration and bundle lifecyles is committed.

          Show
          David Jencks added a comment - I think this is a lot harder than it looks. We need some way to keep track of the bundle we deployed so that it can be restarted if the cache is cleared. IIUC this is not what osgi:install does. Also I think our deployer system should accept bundles and just start them (persistently). This will be much easier after ivan's work to line up configuration and bundle lifecyles is committed.
          Hide
          Rex Wang added a comment -

          How about add a new bundle config builder like what aries-deployer does? It will add the bundle jar to our repository and also the config.xml so that the bundle can start again if the catch is cleared.

          Show
          Rex Wang added a comment - How about add a new bundle config builder like what aries-deployer does? It will add the bundle jar to our repository and also the config.xml so that the bundle can start again if the catch is cleared.
          Hide
          David Jencks added a comment -

          This would mean that each bundle gets a Configuration object managed by the configuration manager. I was hoping that with Ivan's changes to line up gbean and bundle lifecycle we could eliminate the ConfigurationManager or at least greatly simplify it. So I'd rather wait for that before adding more responsibilities to the config manager.

          Show
          David Jencks added a comment - This would mean that each bundle gets a Configuration object managed by the configuration manager. I was hoping that with Ivan's changes to line up gbean and bundle lifecycle we could eliminate the ConfigurationManager or at least greatly simplify it. So I'd rather wait for that before adding more responsibilities to the config manager.
          Hide
          Ivan added a comment -

          One possible temporary solution now is that we could create bundle deployer suggested by Rex, but it just adds the bundle name to the config.xml and save it to the repository folder. Also, we need to hack the codes while starting the server, for those bundle entries, they are just started, not loaded in the configuration manager. And I think it could be ported easily in the future as said by David.
          Thoughts?

          Show
          Ivan added a comment - One possible temporary solution now is that we could create bundle deployer suggested by Rex, but it just adds the bundle name to the config.xml and save it to the repository folder. Also, we need to hack the codes while starting the server, for those bundle entries, they are just started, not loaded in the configuration manager. And I think it could be ported easily in the future as said by David. Thoughts?
          Hide
          Jarek Gawor added a comment -

          I am also in favor of creating a separate bundle deployer. But in my mind that deployer is totally separate deployer from the existing API (something like a PluginInstaller GBean?) to avoid all the Configuration/ConfigurationManager API which should be totally unnecessary in this case.

          As to the bundle persistence and updating config.xml. I don't think we have to do anything to add the bundle names to config.xml. We could just create a GBean that would maintain a list of bundles to start as an attribute for example. The bundle deployer would communicate with that GBean and just add a bundle name/location to the list.

          Show
          Jarek Gawor added a comment - I am also in favor of creating a separate bundle deployer. But in my mind that deployer is totally separate deployer from the existing API (something like a PluginInstaller GBean?) to avoid all the Configuration/ConfigurationManager API which should be totally unnecessary in this case. As to the bundle persistence and updating config.xml. I don't think we have to do anything to add the bundle names to config.xml. We could just create a GBean that would maintain a list of bundles to start as an attribute for example. The bundle deployer would communicate with that GBean and just add a bundle name/location to the list.
          Hide
          David Jencks added a comment -

          I think it is premature to work on this before we've decided how much information about started bundles we are going to save, and how. My current thinking is that we can do exactly what karaf does: some bundles go in system and are listed in startup.properties with their start level, and these survive clean framework starts, and everything else doesn't survive a clean start.

          Show
          David Jencks added a comment - I think it is premature to work on this before we've decided how much information about started bundles we are going to save, and how. My current thinking is that we can do exactly what karaf does: some bundles go in system and are listed in startup.properties with their start level, and these survive clean framework starts, and everything else doesn't survive a clean start.
          Hide
          Rex Wang added a comment -

          For the "PluginInstaller" like approach, it will need new command in cmd-line, new interface in web console, new api in geronimo-deploy-jsr88 used by GEP. So I suggest use the "ConfigurationBuilder" approach for the current user requirements. And we can easily get rid of it in future.

          Show
          Rex Wang added a comment - For the "PluginInstaller" like approach, it will need new command in cmd-line, new interface in web console, new api in geronimo-deploy-jsr88 used by GEP. So I suggest use the "ConfigurationBuilder" approach for the current user requirements. And we can easily get rid of it in future.
          Hide
          Rex Wang added a comment -

          attached GERONIMO-5764.patch.
          NOTE, this is just a workaround for the current requirement. After the kernel refactor, we need re-consider this part of code.

          Show
          Rex Wang added a comment - attached GERONIMO-5764 .patch. NOTE, this is just a workaround for the current requirement. After the kernel refactor, we need re-consider this part of code.
          Hide
          Jarek Gawor added a comment -

          Rex, this patch seems to work but it suffers from the same problems as current deployment of regular Java EE applications. Specifically, when you attempt to stop the module (from cmd line or Eclipse) the bundle is actually uninstalled from the framework. Since the user is deploying bundles, things should behave as if the user was interacting with bundles from the console. That is, stop means stop and not uninstall.
          So, hopefully, the current patch as a temporary solution should be ok but for 3.0 this should work as expected.
          Btw, GEP does not need to use JSR-88 API. It can use whatever we want to: JMX, HTTP, file deploy, etc. So it's not always necessary to modify the geronimo-deploy-jsr88.

          Show
          Jarek Gawor added a comment - Rex, this patch seems to work but it suffers from the same problems as current deployment of regular Java EE applications. Specifically, when you attempt to stop the module (from cmd line or Eclipse) the bundle is actually uninstalled from the framework. Since the user is deploying bundles, things should behave as if the user was interacting with bundles from the console. That is, stop means stop and not uninstall. So, hopefully, the current patch as a temporary solution should be ok but for 3.0 this should work as expected. Btw, GEP does not need to use JSR-88 API. It can use whatever we want to: JMX, HTTP, file deploy, etc. So it's not always necessary to modify the geronimo-deploy-jsr88.
          Hide
          Jarek Gawor added a comment -

          And a few more comments:

          1) The console now shows "deployed bundles". I know what's that for but this is just totally confusing to the user. How will the user know the difference between "deployed bundles" and "osgi bundles"?

          2) During a deployment of a bundle warning message is displayed: "Application module contains OSGi manifest..." This was added to remove the confusion when a Web application was deployed as regular Java EE application or as a WAB. So this warning message should be removed if this patch is applied.

          Given these issues, maybe we should reconsider and use a separate set of APIs for deploying regular bundles. We are trying to move off GBeans anyway.

          Show
          Jarek Gawor added a comment - And a few more comments: 1) The console now shows "deployed bundles". I know what's that for but this is just totally confusing to the user. How will the user know the difference between "deployed bundles" and "osgi bundles"? 2) During a deployment of a bundle warning message is displayed: "Application module contains OSGi manifest..." This was added to remove the confusion when a Web application was deployed as regular Java EE application or as a WAB. So this warning message should be removed if this patch is applied. Given these issues, maybe we should reconsider and use a separate set of APIs for deploying regular bundles. We are trying to move off GBeans anyway.
          Hide
          Rex Wang added a comment -

          Hi Jarek, Thanks for the review and comments.
          I agree with you, this is a temporary solution, so I did not commit it to trunk. I think after the kernel and life cycle refactor, we definitely should re-consider this functionality as David pointed to make it more OSGi-friendly.
          I hope using the OSGi jmx api directly instead of the KernelDelegate, but that does not provide any API can help do the bundle persistence and also record it for a clean start. Anyway, will try your suggestion to design a separate set of APIs. Thanks.

          Show
          Rex Wang added a comment - Hi Jarek, Thanks for the review and comments. I agree with you, this is a temporary solution, so I did not commit it to trunk. I think after the kernel and life cycle refactor, we definitely should re-consider this functionality as David pointed to make it more OSGi-friendly. I hope using the OSGi jmx api directly instead of the KernelDelegate, but that does not provide any API can help do the bundle persistence and also record it for a clean start. Anyway, will try your suggestion to design a separate set of APIs. Thanks.
          Hide
          Jarek Gawor added a comment -

          I believe we have ran into another problem with this patch / approach. When deploying a bundle with its own bundle activator, the activator will invoked during the deployment process. Here are the stack traces to demonstrate the problem:

          java.lang.Exception: Starting - Printing the Test Exception Trace from bundle
          at osgi_test.Activator.start(Activator.java:13)
          at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)
          at java.security.AccessController.doPrivileged(Native Method)
          at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774)
          at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755)
          at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370)
          at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284)
          at org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:208)
          at org.apache.geronimo.deployment.DeploymentContext.initializeConfiguration(DeploymentContext.java:189)
          at org.apache.geronimo.osgibundle.builder.OSGiBundleConfigBuilder.buildConfiguration(OSGiBundleConfigBuilder.java:130)
          at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:250)
          at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:138)

          java.lang.Exception: Stopping the OSGi bundle
          at osgi_test.Activator.stop(Activator.java:23)
          at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:843)
          at java.security.AccessController.doPrivileged(Native Method)
          at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:836)
          at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:501)
          at org.eclipse.osgi.framework.internal.core.AbstractBundle.uninstallWorker(AbstractBundle.java:788)
          at org.eclipse.osgi.framework.internal.core.AbstractBundle.uninstall(AbstractBundle.java:768)
          at org.apache.geronimo.deployment.DeploymentContext.close(DeploymentContext.java:513)
          at org.apache.geronimo.deployment.Deployer.install(Deployer.java:395)
          at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:265)
          at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:138)

          java.lang.Exception: Starting - Printing the Test Exception Trace from bundle
          at osgi_test.Activator.start(Activator.java:13)
          at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)
          at java.security.AccessController.doPrivileged(Native Method)
          at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774)
          at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755)
          at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370)
          at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284)
          at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:304)
          at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:282)
          at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:126)

          Show
          Jarek Gawor added a comment - I believe we have ran into another problem with this patch / approach. When deploying a bundle with its own bundle activator, the activator will invoked during the deployment process. Here are the stack traces to demonstrate the problem: java.lang.Exception: Starting - Printing the Test Exception Trace from bundle at osgi_test.Activator.start(Activator.java:13) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284) at org.apache.geronimo.deployment.DeploymentContext.createTempConfiguration(DeploymentContext.java:208) at org.apache.geronimo.deployment.DeploymentContext.initializeConfiguration(DeploymentContext.java:189) at org.apache.geronimo.osgibundle.builder.OSGiBundleConfigBuilder.buildConfiguration(OSGiBundleConfigBuilder.java:130) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:250) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:138) java.lang.Exception: Stopping the OSGi bundle at osgi_test.Activator.stop(Activator.java:23) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:843) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:836) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:501) at org.eclipse.osgi.framework.internal.core.AbstractBundle.uninstallWorker(AbstractBundle.java:788) at org.eclipse.osgi.framework.internal.core.AbstractBundle.uninstall(AbstractBundle.java:768) at org.apache.geronimo.deployment.DeploymentContext.close(DeploymentContext.java:513) at org.apache.geronimo.deployment.Deployer.install(Deployer.java:395) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:265) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:138) java.lang.Exception: Starting - Printing the Test Exception Trace from bundle at osgi_test.Activator.start(Activator.java:13) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:304) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:282) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:126)
          Hide
          Rex Wang added a comment -

          Hi Jarek, since we still stick to the old kernel, I plan to start this work for trunk this week. I will try the approach you suggestted to design a separate APIs and add the corresponding cli and portlets.

          Show
          Rex Wang added a comment - Hi Jarek, since we still stick to the old kernel, I plan to start this work for trunk this week. I will try the approach you suggestted to design a separate APIs and add the corresponding cli and portlets.
          Hide
          Rex Wang added a comment -

          Attached a new patch: GERONIMO-5764-record-bundle.patch

          This patch introduces a new GBean named BundleRecorderGBean, it can load var/config/bundle-records.properties to install all the bundles list there when server starts. The properties file records many Bundle's URI/startLevel pairs which separated by a "=".

          This patch also provides a couple of new CLIs to help record the bundles that user want to start even after clean the cache. For example:
          a) deploy record-bundle --inplace --start --startLevel 90 D:\BlueprintSample\SampleBundles\HelloWorld.jar
          This command records the bundle in the above properties file, and start it in osgi framework.

          b) deploy operate-record --list
          This command can list all the records as following:
          --------------------------------------------
          Index Installed Started StartLevel URI
          1 true true 70 file:///D:/OSGi/Felix/bundles/BlueprintSample/SampleBundles/BPHelloWorld.jar
          2 false false 80 file:///D:/_g/_tr4bd/impl.jar
          3 true true 90 file:///D:/_g/_tr4bd/user.jar

          GEP can use the new GBean to "persist" an OSGi bundle installation.

          -Rex

          Show
          Rex Wang added a comment - Attached a new patch: GERONIMO-5764 -record-bundle.patch This patch introduces a new GBean named BundleRecorderGBean, it can load var/config/bundle-records.properties to install all the bundles list there when server starts. The properties file records many Bundle's URI/startLevel pairs which separated by a "=". This patch also provides a couple of new CLIs to help record the bundles that user want to start even after clean the cache. For example: a) deploy record-bundle --inplace --start --startLevel 90 D:\BlueprintSample\SampleBundles\HelloWorld.jar This command records the bundle in the above properties file, and start it in osgi framework. b) deploy operate-record --list This command can list all the records as following: -------------------------------------------- Index Installed Started StartLevel URI 1 true true 70 file:///D:/OSGi/Felix/bundles/BlueprintSample/SampleBundles/BPHelloWorld.jar 2 false false 80 file:///D:/_g/_tr4bd/impl.jar 3 true true 90 file:///D:/_g/_tr4bd/user.jar GEP can use the new GBean to "persist" an OSGi bundle installation. -Rex
          Hide
          Rex Wang added a comment - - edited

          Just upload a new patch: GERONIMO-5764-install-bundle.patch
          I modified the design as the following:
          1. Only one cli is kept. That is:
          deploy install-bundle --inplace --start --startLevel 90 D:\BlueprintSample\SampleBundles\HelloWorld.jar
          This cli will install the bundle to osgi framework and record it in the var/config/bundle-records.csv file. If "--start" option is specified, the command uses the OSGi's FrameworkMBean to start the bundle.

          2. Use a BundleTracker to track Uninstalled bundles, if the bundle is listed in the bundle-records.csv, the tracker will erase it. That is, user can use the normal osgi uninstall command to uninstall a recorded bundle and its record will be automatically erased in back.

          3. Modified the BundleRecorder interface, only one API is exposed:
          public long recordInstall(File bundleFile, boolean inplace, int startLevel)
          So, if GEP want to start/stop a bundle, it could use the OSGi's FrameworkMBean, like what does in install-bundle cli.

          -Rex

          Show
          Rex Wang added a comment - - edited Just upload a new patch: GERONIMO-5764 -install-bundle.patch I modified the design as the following: 1. Only one cli is kept. That is: deploy install-bundle --inplace --start --startLevel 90 D:\BlueprintSample\SampleBundles\HelloWorld.jar This cli will install the bundle to osgi framework and record it in the var/config/bundle-records.csv file. If "--start" option is specified, the command uses the OSGi's FrameworkMBean to start the bundle. 2. Use a BundleTracker to track Uninstalled bundles, if the bundle is listed in the bundle-records.csv, the tracker will erase it. That is, user can use the normal osgi uninstall command to uninstall a recorded bundle and its record will be automatically erased in back. 3. Modified the BundleRecorder interface, only one API is exposed: public long recordInstall(File bundleFile, boolean inplace, int startLevel) So, if GEP want to start/stop a bundle, it could use the OSGi's FrameworkMBean, like what does in install-bundle cli. -Rex
          Hide
          Rex Wang added a comment -

          commit to trunk At revision: 1137893

          Show
          Rex Wang added a comment - commit to trunk At revision: 1137893
          Hide
          David Jencks added a comment -

          I'm -1 on the additional bundle-records.csv file. We already have the karaf startup.properties file which lists the bundles that will still get started after a clean. Why do we need another file with apparently the same purpose?

          I also am not sure that we should let people osgi uninstall such persistent bundles and have it mean that they will no longer be started on the next server start. If you osgi uninstall a bundle listed in startup.properties it will still get started the next time the server starts. I think there should be an explicit command to take the bundle out of startup.properties.

          I think that modifying what the server looks like after a clean is a big deal and we should avoid introducing more ways to make such changes and discourage people from making such changes to an existing server.

          Show
          David Jencks added a comment - I'm -1 on the additional bundle-records.csv file. We already have the karaf startup.properties file which lists the bundles that will still get started after a clean. Why do we need another file with apparently the same purpose? I also am not sure that we should let people osgi uninstall such persistent bundles and have it mean that they will no longer be started on the next server start. If you osgi uninstall a bundle listed in startup.properties it will still get started the next time the server starts. I think there should be an explicit command to take the bundle out of startup.properties. I think that modifying what the server looks like after a clean is a big deal and we should avoid introducing more ways to make such changes and discourage people from making such changes to an existing server.
          Hide
          Rex Wang added a comment -

          The problem is we do need provide a way(API) to persist-"install" a bundle to Geronimo.
          I can use startup.properties to replace the bundle-records.csv file and add a new cli: "deploy uninstall-bundle" to erase the records in startup.properties. Is that acceptable?

          -Rex

          Show
          Rex Wang added a comment - The problem is we do need provide a way(API) to persist-"install" a bundle to Geronimo. I can use startup.properties to replace the bundle-records.csv file and add a new cli: "deploy uninstall-bundle" to erase the records in startup.properties. Is that acceptable? -Rex
          Hide
          David Jencks added a comment -

          I think that would be OK.

          Show
          David Jencks added a comment - I think that would be OK.
          Hide
          Rex Wang added a comment -

          uploaded GERONIMO-5764-install-uninstall-bundle.patch and commit to trunk at revision: 1141015

          Updates are:
          1. use the startup.properties to record the bundles
          2. add a new cli: deploy uninstall-bundle

          thanks.

          Show
          Rex Wang added a comment - uploaded GERONIMO-5764 -install-uninstall-bundle.patch and commit to trunk at revision: 1141015 Updates are: 1. use the startup.properties to record the bundles 2. add a new cli: deploy uninstall-bundle thanks.
          Hide
          Jarek Gawor added a comment -

          While working on the GEP side of this feature I ran into two problems so far:

          1) Fragment bundles are not supported. The server will fail to start if a fragment bundle is added to startup.properties file.

          2) Right now it is possible for a bundle added to startup.properties to start before any of the required Geronimo configuration modules are even installed. Which means the bundle might not startup properly. This I believe might be fixed by ensuring the deployed bundles are started after all the configuration bundles are started - via configuring the right start level. This needs to be investigated and fixed.

          Show
          Jarek Gawor added a comment - While working on the GEP side of this feature I ran into two problems so far: 1) Fragment bundles are not supported. The server will fail to start if a fragment bundle is added to startup.properties file. 2) Right now it is possible for a bundle added to startup.properties to start before any of the required Geronimo configuration modules are even installed. Which means the bundle might not startup properly. This I believe might be fixed by ensuring the deployed bundles are started after all the configuration bundles are started - via configuring the right start level. This needs to be investigated and fixed.
          Hide
          Rex Wang added a comment -

          fix #1 at revision: 1145896, we won't start the fragment bundle when launch the framework.

          For #2, I agree with you. Currently we install car's dependent bundles in car's activator, which is not that osgi-friend. That is, if the recorded bundle has the same start level with the car, there is no guarantee which one will start first. This could cause the recorded bundle fail to resolve and start. I believe setting the startlevel properly can resolve this.
          On the other hand, GEP need find a place to record each bundle's start level, or just by default use the initial bundle startlevel + 10 ?

          -Rex

          Show
          Rex Wang added a comment - fix #1 at revision: 1145896, we won't start the fragment bundle when launch the framework. For #2, I agree with you. Currently we install car's dependent bundles in car's activator, which is not that osgi-friend. That is, if the recorded bundle has the same start level with the car, there is no guarantee which one will start first. This could cause the recorded bundle fail to resolve and start. I believe setting the startlevel properly can resolve this. On the other hand, GEP need find a place to record each bundle's start level, or just by default use the initial bundle startlevel + 10 ? -Rex
          Hide
          Yi Xiao added a comment -

          As the life cycle of Geronimo's modules is not under the control of OSGI framework, only +10 in GEP side still can not work successfully.
          It will be a heavy work to make all the Geronimo's modules' under the control of OSGI framework, I think an optional way is that try to start the resolved bundles after all the Geronimo's modules have been started.
          Anyway, I will still add the OSGI start level code in GEP side.

          Show
          Yi Xiao added a comment - As the life cycle of Geronimo's modules is not under the control of OSGI framework, only +10 in GEP side still can not work successfully. It will be a heavy work to make all the Geronimo's modules' under the control of OSGI framework, I think an optional way is that try to start the resolved bundles after all the Geronimo's modules have been started. Anyway, I will still add the OSGI start level code in GEP side.
          Hide
          Rex Wang added a comment -

          Yes, Geronimo modules is installed and started after the framework launch, which means it is out of the control from the start level service
          Commit the workaround At revision: 1146683

          Show
          Rex Wang added a comment - Yes, Geronimo modules is installed and started after the framework launch, which means it is out of the control from the start level service Commit the workaround At revision: 1146683
          Hide
          Yi Xiao added a comment -

          Thank you, Rex, it works! I will create a sub jira under GERONIMODEVTOOLS-759 in GEP to adapt the new feature.

          Show
          Yi Xiao added a comment - Thank you, Rex, it works! I will create a sub jira under GERONIMODEVTOOLS-759 in GEP to adapt the new feature.
          Hide
          Rex Wang added a comment -

          At revision: 1151383, I committed some improvements of bundle recorder:
          (1) use the logic in pluginInstallerGBean when install bundle, so that the Artifact could be calculated the same way, and also can convert a normal jar if the file is not an OSGi bundle.
          (2) when delete an item in startup.properties, also delete the odd empty lines.

          Show
          Rex Wang added a comment - At revision: 1151383, I committed some improvements of bundle recorder: (1) use the logic in pluginInstallerGBean when install bundle, so that the Artifact could be calculated the same way, and also can convert a normal jar if the file is not an OSGi bundle. (2) when delete an item in startup.properties, also delete the odd empty lines.
          Hide
          Jarek Gawor added a comment -

          I discovered two problems with the current implementation:

          1) As introduced as part of this work the following change http://svn.apache.org/viewvc?view=revision&revision=1146683 has a side effect of starting any bundles and not just bundles installed via the install-bundle function. That means that this code can attempt to start bundles of an OSGi application which should not start at that time.

          2) Since BundleRecorderGBean was updating etc/startup.properties with the installed bundles that means that "deploy" or "client" tools would start these bundles as well.

          Show
          Jarek Gawor added a comment - I discovered two problems with the current implementation: 1) As introduced as part of this work the following change http://svn.apache.org/viewvc?view=revision&revision=1146683 has a side effect of starting any bundles and not just bundles installed via the install-bundle function. That means that this code can attempt to start bundles of an OSGi application which should not start at that time. 2) Since BundleRecorderGBean was updating etc/startup.properties with the installed bundles that means that "deploy" or "client" tools would start these bundles as well.
          Hide
          Jarek Gawor added a comment -

          Committed changes to address both issues in revision 1388283. To address #1 the bundles installed via install-bundle command will be started by the BundleRecorderGBean after all configurations are started. To address #2 the bundles installed via install-bundle command are now tracked in the $GERONIMO_HOME/etc/installed-bundles.properties file.

          Show
          Jarek Gawor added a comment - Committed changes to address both issues in revision 1388283. To address #1 the bundles installed via install-bundle command will be started by the BundleRecorderGBean after all configurations are started. To address #2 the bundles installed via install-bundle command are now tracked in the $GERONIMO_HOME/etc/installed-bundles.properties file.
          Hide
          Jarek Gawor added a comment -

          In revision 1390068 I ended up moving the logic in http://svn.apache.org/viewvc?view=revision&revision=1146683 to FrameworkLauncher.java and executing it only for bundles listed in etc/startup.properties file. The reason is that a bundle that has dependencies on a later installed bundle, it might also be required by another later installed bundle. Therefore, the bundle listed in etc/system.properties have to be installed first and started later.

          Show
          Jarek Gawor added a comment - In revision 1390068 I ended up moving the logic in http://svn.apache.org/viewvc?view=revision&revision=1146683 to FrameworkLauncher.java and executing it only for bundles listed in etc/startup.properties file. The reason is that a bundle that has dependencies on a later installed bundle, it might also be required by another later installed bundle. Therefore, the bundle listed in etc/system.properties have to be installed first and started later.

            People

            • Assignee:
              Jarek Gawor
              Reporter:
              viola.lu
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development