Not right now, but that might be a great idea 2008/12/10 Craig Neuwirt <[EMAIL PROTECTED]>
> 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 -~----------~----~----~----~------~----~------~--~---
