Hi Christian, your use case seems like creating some kind of automatic policy derivation mechanism based on other properties of the scenario. It's an interesting approach that makes some scenarios more flexible as they don't need to explicitly use policies but could make the thing complex as we don't see policies explicitly?
But in any case, I think this use case has a different aspect than simply controlling/restricting the automatic engagement of the published features or lifecycle listeners from somewhere else into the bus. regards, aki 2013/3/15 Christian Schneider <[email protected]>: > Hi Aki, > > I also experimented with something similar some time ago. > The idea was like in your case to have some control over which features are > activated. I called the project policy manager. > > I extracted some meta data about each endpoint or client into a simple data > structure. Then I used jxpath to allow users to create filters based on the > extracted > data. So a rule consisted of a jxpath expression and one or more feature > names to enable. > > One thing that is very interesting to pursue is to also use jaxws:properties > for the filtering. This allows the user to define custom meta data in an > endpoint definition that you can then > use in the rules. > > Christian > > Am 15.03.2013 00:32, schrieb Aki Yoshida: > >> 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 > > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com >
