I’m also somewhat opposed to David’s approach. I feel that it conflates two separate concepts: bundles are for packaging and code delivery, this problem space is about enabling/disabling functionality based on observable conditions.
I would prefer to do this with Declarative Services. Rather than “holding back” an entire bundle, just do it with a DS component using a mandatory @Reference to a service. When the “external thing” happens, it is detected and mapped to a published service. The availability of the service allows the component’s @Reference to be satisfied and we are off to the races. This can also be easily understood and introspected at runtime using the scr:list and scr:info commands, or the WebConsole with X-Ray. Regards, Neil > On 10 Nov 2016, at 14:51, Raymond Auge <[email protected]> wrote: > > We've also implemented a robust, services based DB Schema upgrade and > verification framework. > > First off, schema are named (this could be one or more associated tables). > > The schema runtime publishes all known schema "versions" once it's ready, > each as a service. > > The upgrade services are dependent on particular versions of a named > schema, thus a sequence of upgrades services can operate in succession, or > one upgrade can make a large jump from one schema version to a much later > one. > > Of course when an upgrade is in progress the schema is un-published and so > no persistence operations can take place. > > Once the upgrade is complete it tells the schema engine which version was > created, and the schema runtime announces the schema version as a service. > > The persistence services depend on particular schema versions and so they > cannot provide services without a proper schema. > > With this framework we can: > - create schema from scratch > - do live upgrades > - block wrongly deployed versions so they don't screw up the data > - block new versions which don't provide adequate upgrade from the existing > schema to the expected one > - take persistence services out of us while upgrades are happening > - schema may depend on other schema/services > - the upgrade framework will parallelize upgrade operations where the > upgrade graph allows > > We're using this framework now for more than 2 years with around 100 schema. > > It's awesome to see a newly started system come up from either zero > database or from an older version to latest, performing all upgrades along > the way in a cascade fan out. > > - Ray > > > On Thu, Nov 10, 2016 at 8:56 AM, Jan Willem Janssen < > [email protected]> wrote: > >> Hi, >> >>> On 10 Nov 2016, at 13:27, [email protected] wrote: >>> >>> In some cases I have a requirement that a bundle should not resolve (or >>> start) when a certain external 'thing' hasn't taken place yet. For >> example >>> maybe you may not want to start a certain bundle until some operations >> have >>> been performed on a database. >> >> I’m not sure I understand the rationale for making the bundle >> non-resolvable >> when you want to wait for a certain (service?) operation to be complete. >> >> If you’re talking about database migrations that need to be performed >> before >> the services of your bundle are exposed to the rest of the system, then you >> could also prevent them from being registered until the migration scripts >> are >> finished. For a project of ours, we’ve implemented this pattern for all of >> our database migrations and it works really well. For this, we used a >> custom >> on/off service-dependency (we’re using DM4 for that) for our services that >> we >> could flip once the migration was complete causing DM to actually register >> the services. >> >> -- >> Met vriendelijke groeten | Kind regards >> >> Jan Willem Janssen | Software Architect >> +31 631 765 814 >> >> >> My world is something with Amdatu and Apache >> >> Luminis Technologies >> Churchillplein 1 >> 7314 BZ Apeldoorn >> +31 88 586 46 00 >> >> https://www.luminis.eu >> >> KvK (CoC) 09 16 28 93 >> BTW (VAT) NL8170.94.441.B.01 >> >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
