Ayende, Are you planning to expose events on the NamingSystem when component not resolved?
2008/12/10 Ayende Rahien <[EMAIL PROTECTED]> > > > 2008/12/10 Krzysztof Kozmic <[EMAIL PROTECTED]> > >> >> How do you plan to support it without changing the kernel? >> > > custom naming sub system, probably > > >> >> 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. > > > We can extend the naming sub system to look for components in the wcf > config. > That can be done in the facility. > > >> >> >> > 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. >> > > agreed, consider the case where I want to do things like IronPython > components. > Actually, my DSL stuff is often used that way. > > >> >> > I think we can do with the existing activator support >> 3. Ayende, can you elaborate a little bit on that? >> > > See my next commit. > > >> >> 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 -~----------~----~----~----~------~----~------~--~---
