I agree! 95% of our code is DS. Only some very intense infra parts or more low level.
- Ray On Thu, Nov 10, 2016 at 10:05 AM, Neil Bartlett <[email protected]> wrote: > 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) > > -- *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)
