Okay, you would need to create one, create ComponentModel, etc... 2008/12/10 Craig Neuwirt <[EMAIL PROTECTED]>
> 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 -~----------~----~----~----~------~----~------~--~---
