Nope, perfectly happy with Handlers. 2008/12/10 Ayende Rahien <[EMAIL PROTECTED]>
> 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 -~----------~----~----~----~------~----~------~--~---
