felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bartlett <njbartl...@gmail.com>
Subject Re: [Discuss] Resolver 'latch' bundle / sub module
Date Thu, 10 Nov 2016 15:05:13 GMT
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.


> On 10 Nov 2016, at 14:51, Raymond Auge <raymond.auge@liferay.com> 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 <
> janwillem.janssen@luminis.eu> wrote:
>> Hi,
>>> On 10 Nov 2016, at 13:27, davidb@apache.org 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)

View raw message