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.
