I am trying to support this without having to change the kernel. This type of support sounds like a job for SubDependencyResolver, but that get called before the kernel is given a chance to resolve it. Do you think SubDependecyResolver should come last in the resolution strategy?
On Wed, Dec 10, 2008 at 1:05 AM, Krzysztof Koźmic < [EMAIL PROTECTED]> wrote: > Hi, > I wrote about it some time ago in the context of using WCF configuration > file as sole source of information for resolving WCF components. > My idea was to extend the way IKernel resolves components. Right now when > it does not have a component registered (or we're trying to register > asbtract component as you wrote) it throws. > Alternatively, to support this kind of scenarios, we might extend it (via > facility?) that would be called in those situations (i.e. while registering > otherwise illegal component, or while resolving unregistered component). > It would require two methods: > > *bool CanProvide(Type componentType, string name, IKernel kernel);//kernel > throws when it returns false > object Provide(Type componentType, string name, IKernel kernel); //OR > IHandler Provide(Type componentType, string name, IKernel kernel, out > IHandler[] dependencies);* > > This is only an initial idea and it would have to be thought through to > ensure that it easily fits with other aspects of the container. > > This solution would be IMHO flexible enough to handle I think all of WCF > needs (incl, not-yet-implemented support for config file), AND would easily > solve the problem you described. > > Thoughts? > > > Ayende Rahien pisze: > > I just applied a patch to detect and give a good error if we are trying to > register a component whose implementation is abstract. That broke the WCF > facility, which allow you to register just the interface, and rely on the > WCF machinery to provide the real implementation. > Currently I "fixed" the build by making sure that the test in the code > specify an implementation, but considering a common case for the WCF client > facility, we won't _have_ an implementation. > Any suggestions for solving this? > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
