• Icon: Feature Request Feature Request
    • Resolution: Done
    • Icon: Major Major
    • 7.1.2.Final (EAP)
    • 7.1.1.Final
    • OSGi
    • None

      It has to be possible to deploy a large set of bundles at the same time without triggering the resolution of each bundle individually.

      Currently, if you deploy multiple bundles either through CLI or via the hot deployment folder the deployer processes each bundle individually. If you try to deploy 287 bundles with interdependencies, this would mean you have to install them in the absolute correct order or else the deployer finds missing dependencies and undeploys the bundle again.

      The OSGi framework API allows for installation of multiple bundles before calling a single refresh call to trigger the re-wiring. The deployer needs to support a mechanism similar to this as well.

            [AS7-4324] Batch deployment of bundles

            Could you please point me in the direction of the part of the OSGi specification that says bundles must be installed, resolved and started as a set and that automatic refreshing is not allowed when a new bundle is hot deployed? I took a look at v5 and was unable to find anything like that.. although I could have easily missed it.

            Aaron Whiteside (Inactive) added a comment - Could you please point me in the direction of the part of the OSGi specification that says bundles must be installed, resolved and started as a set and that automatic refreshing is not allowed when a new bundle is hot deployed? I took a look at v5 and was unable to find anything like that.. although I could have easily missed it.

            Thomas Diesler added a comment - https://community.jboss.org/thread/223943

            I think I am still seeing this issue because I am deploying a large amount of bundles and the deployment scanner is executing halfway through my # cp *.jar deployments/ command so it only sees half the bundles, then it executes again and sees the other half but nothing resolves correctly... because that is treated as two different deployment batches?

            Apache Felix provides an auto-deploy feature where it monitors a directory for changes and enacts these changes. If there are unresolved bundles present and a new bundle is installed that provides the necessary packages it will automatically refresh those dependent bundles.

            It may not be required by the specification, but it's actually really handy for development. If JBoss won't support this feature how am I to successfully deploy large batches of bundles?

            Aaron Whiteside (Inactive) added a comment - I think I am still seeing this issue because I am deploying a large amount of bundles and the deployment scanner is executing halfway through my # cp *.jar deployments/ command so it only sees half the bundles, then it executes again and sees the other half but nothing resolves correctly... because that is treated as two different deployment batches? Apache Felix provides an auto-deploy feature where it monitors a directory for changes and enacts these changes. If there are unresolved bundles present and a new bundle is installed that provides the necessary packages it will automatically refresh those dependent bundles. It may not be required by the specification, but it's actually really handy for development. If JBoss won't support this feature how am I to successfully deploy large batches of bundles?

            An OSGi Framework does not auto refresh/resolve A when bundle B gets installed/resolved/started. Even if A has a requirement that could potentially be wired to a capability provided by B.

            You need to make sure that you install stuff together that you want to resolve together or deal with ordering in some other way.

            Thomas Diesler added a comment - An OSGi Framework does not auto refresh/resolve A when bundle B gets installed/resolved/started. Even if A has a requirement that could potentially be wired to a capability provided by B. You need to make sure that you install stuff together that you want to resolve together or deal with ordering in some other way.

            Still an issue, if I deploy a bunch of bundles where one dependency is missing, of course the bundles fail to deploy. But when I deploy that one missing dependency the container should detect that the missing dependency is now present and refresh the other bundles which should start as a result?

            Can we have a feature to turn back on, or make configurable, automatic refresh of bundles as it was in JBoss 7.1?

            Aaron Whiteside (Inactive) added a comment - Still an issue, if I deploy a bunch of bundles where one dependency is missing, of course the bundles fail to deploy. But when I deploy that one missing dependency the container should detect that the missing dependency is now present and refresh the other bundles which should start as a result? Can we have a feature to turn back on, or make configurable, automatic refresh of bundles as it was in JBoss 7.1?

            Please verify against the current AS8/master

            Thomas Diesler added a comment - Please verify against the current AS8/master

            I don't think this is fixed, in 7.2.0 I have to restart the AS several times to progress through the bundle inter-dependencies...

            Aaron Whiteside (Inactive) added a comment - I don't think this is fixed, in 7.2.0 I have to restart the AS several times to progress through the bundle inter-dependencies...

            Done

            deploy --name=foo .../org.acme.foo.jar
            deploy --name=bar .../org.acme.bar.jar
            /subsystem=osgi/bundle=foo:start
            

            Thomas Diesler added a comment - Done deploy --name=foo .../org.acme.foo.jar deploy --name=bar .../org.acme.bar.jar /subsystem=osgi/bundle=foo:start

              tdiesler@redhat.com Thomas Diesler
              tiekmann Tim Diekmann (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: