Any thoughts on this? I'd really like to adopt Windsor 3 to get rid of our WeakReference memory leak that we have now.
Thanks. On Sep 7, 6:33 pm, Jeff N <[email protected]> wrote: > The goal for my lazy loader is never to resolve services (in the > semantic sense of the word service). Those are always interfaces with > internal implementing classes (to avoid accidental directl > instantiation)...so they are (and must be) explicitly registered in > the container at startup. > > It's only for proxy/interception support that the lazy loader is > really necessary. Let's take the example of my search args class. The > proxy automatically implements INotifyPropertyChanged....but do I > really need/want to do the busy work of registering all of these > simple classes as components? I feel like not... Plus let's say a > developer that doesn't really know anything about DI to interception, > but does know to add [NotifyPropertyChanged] wants to create a new > class. Should they really need to go into the Bootstrapper and > register it? Or add it to a white list? It seems kind of unnecessary > in terms of friction... > > Plus, on a completely unrelated note, registering all these types for > proxying means startup of the client application will slow down > substantially. Loading up all those assemblies where the types live > (like 10 of them) adds 2 or 3 seconds to startup. If I scan the > assemblies for types annotated with [Component] attribute or try to > register all types in the assemblies, startup performance becomes even > (much much) worse. > > So back to your point...in terms of white listing...adding all those > components to be proxies to a whitelist is kind of a big friction > point from a development standpoint. > > I hope I've expressed my concern clearly. Let me know if not. > > Thanks. > > On Sep 7, 6:06 pm, Krzysztof Ko¼mic <[email protected]> > wrote: > > > > > > > > > I agree the loader is fragile and sooner or later something will fall > > through the cracks with this approach. > > > What if instead of blacklisting types (thou shall not be resolved) you > > give it a whitelist or a whitelisting predicate. > > Only resolve types from "Foo.Services" namespace, or similar. > > > In general that's the goal for using lazy component loaders, to narrow > > down their scope as much as possible, rather than making it a catch-all. > > > What is the goal of your lazy component loader? > > > Krzysztof > > > On 08/09/2011 2:32 AM, Jeff N wrote: > > > > Yes, that does work (filtering the service at the LazyComponentLoader > > > layer)....and that's what I've done in the interim to test other > > > things: > > > > private static readonly Type[] ExcludedTypes = new[] { typeof(object), > > > typeof(ControllerBase), typeof(Person) }; > > > > if (ExcludedTypes.Contains(serviceType)) > > > { > > > return null; > > > } > > > > in the lazy component loader. > > > > But, I'm really concerned about having to identify all the places that > > > are bad candidates for lazy loading (there are literally hundreds of > > > places I'd need to check). Further, I might run across an assembly > > > that isn't visible to my loader....so essentially the loader becomes a > > > god class. > > > > If you can bake in some way of controlling the behavior, I'd really > > > appreciate it. If something is baked in, I guess it would have to be > > > done at the Kernel itself, not in the loader, right? Because even if > > > my loader changes it's behavior to ignore optional dependencies, the > > > other loaders might not know that I want to do so (LazyOfTLoader, > > > DelegateFactoryLoader, etc.)... > > > > I know it was a bug, but in my thinking, the old behavior really makes > > > more logical sense - lazy load something only when it's really > > > necessary....but of course I can appreciate the opposite perspective > > > too. > > > > Thanks. > > > > Jeff > > > > On Sep 7, 9:05 am, Krzysztof Ko¼mic<[email protected]> > > > wrote: > > >> What about adding some filtering to your lazy component loader? > > > >> WIth this example you gave here I suspect you would never want Person as > > >> a service anyway, hence applying some filtering based on structure might > > >> solve that. > > > >> - if requested type is in Acme.Services resolve it > > >> - otherwise (and I suppose Person would be in Acme.Domain or similar > > >> namespace) skip it > > > >> I don't think we have a setting to disable it currently, although if the > > >> above does not solve that for you I might look into introducing some way > > >> of controlling that behaviour... > > > >> HTH, > > >> Krzysztof > > > >> On 07/09/2011 10:55 PM, Jeff N wrote: > > > >>> That will solve the issue with MVC Controllers...but there are tons of > > >>> other places that rely on more intelligent setting. > > >>> For example: > > >>> public class SearchArgs > > >>> { > > >>> private Person _personToSearchFor; > > >>> public Person PersonToSearchFor > > >>> { > > >>> get { return _personToSearchFor; } > > >>> set > > >>> { > > >>> if (value != _personToSearchFor) > > >>> { > > >>> // do some relevant stuff: this breaks now > > >>> because it's automatically set to an empty, default instantiation of > > >>> person as soon as the args is resolved. > > >>> } > > >>> } > > >>> } > > >>> } > > >>> Is there no way I can inherit from the DefaultKernel and disable this > > >>> globally? This completely prevents me from upgrading. > > >>> Thanks. > > >>> On Sep 7, 3:01 am, Krzysztof Ko¼mic<[email protected]> > > >>> wrote: > > >>>> Ignore all base-class properties on Controllers when registering > > >>>> Krzysztof > > >>>> On 07/09/2011 1:41 PM, Jeff N wrote: > > >>>>> I understand that in Windsor 3 the design was changed so that optional > > >>>>> dependencies try to get resolved via an ILazyComponentLoader > > >>>>> I have a basic ILazyComponentLoader that does > > >>>>> Component.For(serviceType).Named(key) > > >>>>> This change breaks a TON of things in the solution, including all > > >>>>> ASP .NET MVC controllers (since an object property type (Model) on the > > >>>>> ControllerBase class is now injected with the wrong type. > > >>>>> Any suggestions on how to work around this? Essentially I just want to > > >>>>> revert to the old behavior by which optional dependencies are not > > >>>>> lazily loaded. Is there any way I get get the dependency being > > >>>>> resolved in context of my lazy component loader, so I can check if > > >>>>> it's optional and return null if true? > > >>>>> Thanks. -- 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.
