It seems like even the approach I was going to take won't work because
the DefaultDependencyResolver will still make wide spread incorrect
choices. In other words, I can't just do:
protected override bool CanResolveCore(CreationContext context,
global::Castle.Core.ComponentModel model, DependencyModel dependency)
{
if (dependency.IsOptional && !
kernel.HasComponent(dependency.TargetType))
{
return false;
}
return base.CanResolveCore(context, model,
dependency);
}
because Windsor will still incorrectly choose constructor 1 over
constructor 2 below:
public Foo(string s)
{
}
public Foo()
{
}
I'm really not sure how to proceed at this point. Any advise would be
much appreciated.
Thanks.
On Sep 9, 2:31 pm, Jeff N <[email protected]> wrote:
> If I'm going to implement this myself, would you suggest inheriting
> from DefaultDependencyResolver and putting logic in Resolve to check
> if Kernel.GetAssignableHandlers == null?
>
> On Sep 9, 10:17 am, Jeff N <[email protected]> wrote:
>
>
>
>
>
>
>
> > 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.
