Ideally, just expose an event such as HandlerNotfound The problem is that we work with handlers, and I don't think you would want that
2008/12/10 Craig Neuwirt <[EMAIL PROTECTED]> > I need to support WCF stuff that Krzysztof requested so if you have any > details about this possible change, just give me a shout so we are on the > same page. > > thanks > > > 2008/12/10 Ayende Rahien <[EMAIL PROTECTED]> > >> 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 -~----------~----~----~----~------~----~------~--~---
