inline On Tue, Aug 11, 2009 at 1:57 AM, Adam Langley <[email protected]>wrote:
> 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 This is the current behavior, the handler encapsulate the activator, which actually manage the lifecycle. > > 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... > Argh, NO! If this is what you want, all you need to do is to write a custom life cycle. > > Ideas? > > Adam Langley > Senior Developer > www.winscribe.com > > > Please consider the environment before printing this email! > > From: [email protected] [mailto: > [email protected]] On Behalf Of Ayende Rahien > Sent: Tuesday, 11 August 2009 9:24 a.m. > To: [email protected] > 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 <[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 -~----------~----~----~----~------~----~------~--~---
