I'm using the CollectionResolver (more specifically the ListResolver) to support scenarios where we want to inject multiple implementations of an interface. The CollectionResolver's behavior has been impacted by the changes to ResolveAll() in Castle 3. Previously, ResolveAll() would only return those implementations that could be resolved, and silently ignore any registered implementations that could not be resolved. Now, ResolveAll() fails if ANY one of the registered implementations cannot be resolved.
In general, I think this is a good change, as it ensures that we are actually getting all the implementations we think we are. However, I have a couple scenarios where I was actually using the old behavior to my benefit. I have an infrastructural component (IBar), registered by a common installer, that depends on a collection of IFoo (to be fulfilled by the collection resolver). In the common installer, I also register some implementations of IFoo, but these implementations depend on services that may or may not be registered. The idea is that a client can "activate" such an implementation of IFoo by registering the dependent service. Previously, if the client did not register the dependency of a particular IFoo, that implementation of IFoo simply wouldn't be injected into IBar (and other resolvable implementations would be). Now the resolution of IBar just fails in this scenario because the (previously optional) IFoo couldn't be resolved.
Is there any way to easily restore the old behavior? Ideally, I'd like to use the new behavior by default, but revert to the old behavior for a particular service (IFoo in this case). I've tried creating a IHandlersFilter implementation to accomplish this, but I've discovered that it is not possible to filter out ALL candidate handlers (return an empty array from SelectHandlers) -- if I attempt to, Windsor ignores the filter and tries to resolve all the candidate handlers anyway.
Any ideas? I'm also open to a totally different approach of achieving my goal, if you think I'm going about this the wrong way.
