I kind of chatted with Aki a bit about this today. To follow up on list:
I basically have no problem with doing this as long as the defaults remain as today (unfiltered). However, if we start pursuing this, it may also be good to make it also apply to the other things that can be pulled in such as BusLifecycleListeners, ServerLifecycleListeners, and ClientLifecycleListeners. Also, it's likely also useful to allow the "reverse" where a bundle could register a *LifecycleListener with some OSGi properties that specify which buses and services to apply it to. Anyway, mostly just a bunch of potentially cool feature requests. :-) Dan On Mar 14, 2013, at 7:32 PM, Aki Yoshida <[email protected]> wrote: > Hi, > Currently, I think there is no filtering option in automatic feature > loading over osgi services. > I think it's nicer and safer to have some kind of filtering mechanism. > > I am thinking of not just the enable/disable boolean flag, but a regex > filter to match against the service-publishing bundle's symbolic names > and feature names. > > Cocretely, we define bus properties that look something like, > bus.feature.osgi.load.allowFeatures > bus.feature.osgi.load.denyFeatures > bus.feature.osgi.load.allowBundles > bus.feature.osgi.load.denyBundles > > each taking a regex string. > > and writing in a pseudo-code, > given > f = feature > bsn = bundleSymbolicName > fn = featureName > > we use the condition > if (match(allowBundles, bn) && !match(allowBundles, bn) > && match(allowFeatures, fn) && !match(denyFeatures, fn)) { > add(f) > } > > or use a simpler rule with only the bundle name check part. > > Do you have comments or preferences? > > Thanks. > regards, aki -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
