Hm,I would say that we need a LazyHandler, then, no? 2009/8/6 Krzysztof Koźmic <[email protected]>
> Hi, > > Funny, how we were discussing with Craig this very issue not further than > two days ago. > Anyway, I agree, that we should have something like ILazyComponentsProvider > (being handler missing Craig mentioned) > that would be last place to ask, before throwing exception. Note that this > would also have to support missing required (optional as well?) > dependencies. > I think that after lazy loading we should register the component in the > container, so that next time its ask for it's loaded using standard means. > > Krzysztof > > > Craig Neuwirt wrote: > > Ayende, > > I believe the IHandlerSelector was mainly used to select from an existing > set of handlers. What we > need is HandlerMissing support which will allow us to dynamically return > handlers and/or register them > at the same time. I am on vacation for a few days, but we can chat about > this (If not already implemented ;-) > when I return on Tues. > > Cheers, > craig > > On Wed, Aug 5, 2009 at 6:07 PM, Ayende Rahien <[email protected]> wrote: > >> IHandlerSelector is how I would handle this. You would need to provide an >> implementation of IHandler that provide instances via the WCF client >> support. >> Shouldn't be too hard, I think. >> >> On Thu, Aug 6, 2009 at 1:52 AM, Adam Langley <[email protected]>wrote: >> >>> >>> After speaking to Krzysztof Kozmic, this question is directed primarily >>> to Ayende and Craig Newirt, >>> >>> I require that Windsor has the ability to resolve component types to a >>> WCF client endpoint configured in system.servicemodel/client rather than >>> to a well-known type. >>> Krzysztof suggested that I ask if anyone has attempted to add the >>> required extensibility points to the micro-kernel to facilitate this >>> feature, so that I may build on it to bring it to completion. >>> Additionally, any suggestions on how this should be implemented would be >>> greatly appreciated. >>> Krzysztof believes that before the last resort of throwing >>> ComponentNotFoundException, subscribed facilities should have the chance >>> to resolve the component. >>> >>> After taking a brief look at the code this presents two hurdles. >>> >>> Firstly, when the configuration is initially built, any components that >>> do not have a Type attribute are ignored, meaning that the naming >>> subsystem will never admit knowledge of them. >>> Secondly, even if the naming subsystem admitted knowledge of the >>> component, code needs to be added to locate a facility that has taken >>> responsibility for the type resolution, and delegate the call to >>> it/them. >>> >>> There are several decisions around how this feature should 'behave', >>> what do you think? >>> >>> Thanks >>> >>> Adam Langley >>> >>> >>> >>> >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
