Perhaps the Karaf user's forum isn't the right place for this but I thought I'd at least show what I have and see if there's any interest. If this were hardened a bit more I think it would be a great mechanism for OSGi. I've installed and tested it via features files and it seems to work fine.
I now have a new bundle with a DS component that listens for Bus and BusConfigurator interfaces. The BusConfigurator contains a Map<String,BusConfiguratorBean> which is keyed by bus id to a BusConfiguratorBean. The BusConfiguratorBeans are basically like a Feature implementation with interceptors, features, properties. A BusConfiguratorBean can be associated with 1...N Bus ids in the map. In other words, while it allows for a great deal of granularity it can also be a coarser granularity - if 80% of your web services have identical security, logging, features, etc. they'd all use the same BusConfiguratorBean, that is, the same BusConfiguratorBean would be added to the map keyed by different bus ids. If a Bus comes in that doesn't have a configurator associated with its id, it is parked in the the unconfigured bus registry. If a configurator is later added, that configuration is applied to the Bus. So there's a bit of temporal decoupling. The one thing this will not do is /update/and already configured Bus. in other words, if a Bus/BusConfiguratorBean are paired and the Bus gets configured but in the future a new BusConfiguratorBean for that Bus comes in, this doesn't reconfigure the existing Bus. I certainly could keep the busses in a map and do such reconfiguration but I'd have to be a lot clearer about the mechanics and implications of that. For my use case, that's not really too important. The intended use case is to provide a mechanism to (a) avoid duplication of bus configurations, (b) provide a high degree of reuse, (c) provide high customization, (d) consolidate Bus configurations into a single bundle, and (e) easily support microservices like installation of webservices. So my intended use case is that the bus configurators would get installed early. As webservices get installed and uninstalled it tracks them and configures them as necessary. While the configurators could be updated after that and would configure any new webservices installed, it isn't anticipated to be the common use case. While I use DS as often as possible, I'm not as conversant as I'd like. Are there any issues with the way I have the listener mechanisms set up with dynamic and greedy? -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
