2008/12/10 Krzysztof Kozmic <[EMAIL PROTECTED]> > > 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.
For WCF, I was going to load resolve any services in the configuration file. However, I agree with you that extending the kernel to add the ability to defer unresolved components to another entity before raising exception would be a nice feature > > > > 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 (1) would represent a nice general solution would would be beneficial to WCF Facility and others. However, I think we need to support more fine grained control so that you can register an interface and perhaps one or more interceptors without having to have a facility or other hook > > > > 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 -~----------~----~----~----~------~----~------~--~---
