Agreed. (inline) Ayende Rahien wrote: > inline > > On Tue, Aug 11, 2009 at 1:57 AM, Adam Langley <alang...@winscribe.com > <mailto:alang...@winscribe.com>> 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! No, letting lazy handler provider, or whatever we call it decide whether it wants to register the handler in the container or not, should let you cover probably all the scenarios. I say let's have _a_ way of implementing that, then we'll spike its usage in WCF Facility (and if I find some time, I plan to do also MEF integration that would require this as well) and see how that works, and what did we miss. Ay? > > 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 <http://www.winscribe.com> > > > Please consider the environment before printing this email! > > From: castle-project-users@googlegroups.com > <mailto:castle-project-users@googlegroups.com> > [mailto:castle-project-users@googlegroups.com > <mailto:castle-project-users@googlegroups.com>] On Behalf Of > Ayende Rahien > Sent: Tuesday, 11 August 2009 9:24 a.m. > To: castle-project-users@googlegroups.com > <mailto: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 > <mailto: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 > <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 -~----------~----~----~----~------~----~------~--~---
