yup 2008/12/10 Ayende Rahien <[EMAIL PROTECTED]>
> 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 -~----------~----~----~----~------~----~------~--~---
