Perhaps there could be a mechanism to continue to be queried for the validity of this object? For example, if the main use for this would be managing WCF endpoints, they can transition to a faulted state, at which time they can no longer be used anymore, so its actually the ChannelFactory that needs to be cached (aswell)... Im not sure of the best way to achieve this though.
I think the lazy handler should either: 1. allow the lazy handler to specify that its result should NOT be stored within the container, allowing the handler to return it on every request 2. or, allow the container to store the object using the appropriate lifecycle, BUT before returning the object, it passes the object to the lazy handler (ILazyHandler.IsComponentStale(object component) ?) to allow it to return false to let the container use its cached instance, or return true to have its query method called again to create a new instance of the type. This way it can look at the endpoint.State == Faulted, to test if it should recreate it or not... Ideas? Adam Langley Senior Developer www.winscribe.com Please consider the environment before printing this email! From: castle-project-users@googlegroups.com [mailto:castle-project-us...@googlegroups.com] On Behalf Of Ayende Rahien Sent: Tuesday, 11 August 2009 9:24 a.m. To: castle-project-users@googlegroups.com Subject: Re: Design questions for resolution of IOC-ISSUE-161 Hm, I would say that we need a LazyHandler, then, no? 2009/8/6 Krzysztof Koźmic <krzysztof.koz...@gmail.com> 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> 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> 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 -~----------~----~----~----~------~----~------~--~---
