Oh man... singleton bundle... wow totally missed that one. Glad I wasn't writing the osgi cert at that moment.
So yes this solves part of the model. The other part is to preventing a bundle requiring an older version of a schema from resolving once the schema has been elevated beyond it's version. On Wed, Sep 24, 2014 at 11:01 AM, Thomas Watson <tjwat...@us.ibm.com> wrote: > Perhaps I am simplifying the scenario, but isn't this a bundle singleton? > Here I am assuming the same bundle symbolic name is always providing the > schema that you want to be a singleton also. > > There than bundle singletons, which equate to the osgi.identity capability > namespace, there is no notion of a capability singleton. > > Tom > > > > > > From: Raymond Auge <raymond.a...@liferay.com> > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Date: 09/24/2014 09:55 AM > Subject: [osgi-dev] Requirements and Capability uniqueness model? > Sent by: osgi-dev-boun...@mail.osgi.org > ------------------------------ > > > > Is there a provision or mechanism in Req&Cap which might enforce > uniqueness? > > One scenario for this is different versions of bundles requiring different > DB schema of the same DB tables. > > We have modules which build/upgrade their schema on demand when new > versions are installed.. but this breaks the osgi "mutli bundle version" > model. > > I'm wondering what is the best way to model this. > > I'd like to enforce the following model: > > 1) when a bundle attached to a schema resolves it sets a capability of > it's schema to some version (this value is persisted system wide) > 2) a new bundle version cannot resolve if a lower version bundle attached > to same schema is still active (i.e. once the old bundle is stopped, and > the new one is allowed to resolve it bumps up the schema version) > 3) an old bundle version cannot resolve once the schema version has been > elevated to some higher level > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect > *Liferay, Inc.* <http://www.liferay.com/> (@Liferay) > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
