How do you plan to support it without changing the kernel? 1. If we were to support WCF config, I think it would be reasonable to only say to the facility "use the config file" and not register the services explicitly. Then, with current implementation of the DefaultKernel, we have no way of doing this, since Kernel checks its registered components, and if it doesnt find one, it throws. This all happends before event SubDependencyResolver gets a chance to be called.
> I think we should only raise an error if Abstract and not and interface. It > is very reasonable to support only interface registrations. 2. I'm not sure it's such a good idea. First, even WCF Contract can be a class, not an interface (not that I'm advocating it, but WCF allows it). Second, there may be other situations where user may want to register virtual component, and deal with it in a similar manner to WCF Facility. I think we need an opt-in mechanism for that. > I think we can do with the existing activator support 3. Ayende, can you elaborate a little bit on that? Cheers, Krzysztof >>> [EMAIL PROTECTED] 2008-12-10 15:15 >>> 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? > > > > > > > CONFIDENTIALITY NOTICE This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged, confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please delete all copies of this message and notify the sender immediately by return mail or fax ATSI S.A.(+4812) 285 36 04. Any email attachment may contain software viruses which could damage your own computer system. Whilst reasonable precaution has been taken to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening any attachments. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
