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 <aye...@ayende.com > <mailto:aye...@ayende.com>> 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 > <alang...@winscribe.com <mailto:alang...@winscribe.com>> 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 castle-project-users@googlegroups.com To unsubscribe from this group, send email to castle-project-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
