Ironically, the third use case is the one I'd really like to solve but may not have conveyed well.

In an OSGi environment I would have multiple bundles offering ComponentFactory services. These bundles may come and go as bundles are installed, started, stopped, etc.

Another bundle can listen for ComponentFactory service registrations and act as a broker whenever there is a need to instantiate a component. This broker would itself implement ComponentFactory and it is that implementation that is registered with logback. When logback needs to instantiate an object it could go to the broker, which knows about all implementations of ComponentFactory and could find the one that is willing to instantiate an object. This separates the notion of OSGi services from logback.

What I'd like to do is make it easy to dynamically add appender implementations (and other components too I suppose) without having to revisit the OSGi framework's configuration for each fragment. Instead, the configuration could specify the broker, which implements the OSGi service listener, one time and then everything is dynamic from that point on. The broker in this case would be reachable by logback's classloader.

In any event, hopefully that explained my intent. The interface you've proposed and configuration options sound great.