Should we move that check into the DefaultComponentActivator ctor so it is raised during registration?
2008/12/10 Ayende Rahien <[EMAIL PROTECTED]> > You are correct, and that is why I am moving this feature to the component > activator, where we can give a better error, and not break existing > scenarios > > 2008/12/10 Craig Neuwirt <[EMAIL PROTECTED]> > > If we disallow interfaces/abstract registrations then I think we'll make it >> more difficult to do thinks like the FactorySupport does by just registering >> an interface and interceptor. How would the suggested approach support >> that? >> >> 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 -~----------~----~----~----~------~----~------~--~---
