Sounds very interesting :) Carsten
David Bosschaert wrote > Hi all, > > 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. > > Normally the only way you can prevent a bundle from resolving is if it has > some unresolved requirements. However, requirements and capabilities are > only attacheable to bundles and to add a requirement at runtime would > require adding a specific bundle that has that capability which could get a > bit messy - you may end up with a lot of capability-only bundles. > > So I've been prototyping an alternative approach to this: a bundle with a > resolver hook. The bundle prevents bundles that are configured to be 'held > behind' from resolving until the latch has opened and they are allowed to > resolve. > > In practice it worked like this. The implementation bundle looks for > bundles that are marked with a specific resolver latch capability: > Provide-Capability = > aaa.bbb.ccc.resolverlatch;aaa.bbb.ccc.resolverlatch=foobar > The capability has a latch name too, in the above case that's 'foobar'. > > The resolver latch bundle is configured (via configadmin) with a list of > latch names that it should initially prevent from resolving. > It also provides a service that can be called by an external entity - eg > the one that knows about the database in the above example - to release the > latch with a certain name... At that point the bundles with that latch name > capability can be started. > > It's quite a small project altogether, and it might be useful by others > too. I'd like to contribute this to the Felix project as an independent > submodule. > > Thoughts anyone? > > Cheers, > > David Bosschaert > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
