TypedFactoryFacility and delegate properties

[Kim Birkelund]

Hi

I suddenly ran into Windsor having populated a random Func<,> property with some delegate it thought up itself and found it to be caused by TypedFactoryFacility. 

I found a question on StackOverflow (http://stackoverflow.com/questions/5987323/can-windsors-typedfactoryfacilitys-implicit-delegate-factory-registration-be-d) that instructed that you should just remove the DelegateFactory responsible for doing this, however I cannot for the life of me figure out how to do that.

According to docs IKernel should have a RemoveComponent method, but it doesn't appear to in the version (3.0) I have.

Is there another way of getting around TypedFactoryFacility doing this?

/kim

[Patrick Steele]

Have you tried the DoNotWire attribute?

http://stackoverflow.com/questions/178611/windsor-container-how-to-specify-a-public-property-should-not-be-filled-by-the

---
Patrick Steele
http://weblogs.asp.net/psteele

> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/castle-project-users/-/6hB8RUdumtkJ.
> To post to this group, send email to castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to
> castle-project-u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/castle-project-users?hl=en.

[Krzysztof Koźmic]

If you don't want Windsor to interact with these properties then don't
expose them on your components:
http://docs.castleproject.org/Windsor.Whats-New-In-Windsor-3.ashx#Filtering_of_property_dependencies_10

@K

[Kim Birkelund]

This is not so much about my not wanting to expose the properties, but more about the factory facility making stuff up - especially for types that it would be impossible for me to make a registration (e.g. bool, since its a value-type). 

The DelegateFactory injects any delegate regardless of whether is any registration for the return type of the delegate and regardless of whether it is a valid type for registration.

Using the DoNotWire is not a reel solution either - in my opinion avoiding injection of stuff that shouldn't be, is not something that should be hardcoded into the component, but should be handled at the point resolution by specifying the correct dependency as an argument. But this is not the issue here, this is about DelegateFactory making unreasonable assumptions about the nature of publicly accessible properties of delegate type.

I fully understand the purpose of having DelegateFactory - providing lazy access to a dependency that isn't available yet, or one that needs to be resolved multiple times - but using any delegate type seems as a bad design choice to me.

/kim

> castle-project-users@googlegroups.com.

> To unsubscribe from this group, send email to

> castle-project-users+unsub...@googlegroups.com.

[Krzysztof Koźmic]

The thing with providing bool, string etc is a known bug (http://issues.castleproject.org/issue/IOC-331) which will be fixed in the next release.
If that gets fixed, would that resolve your issues?

@K

To view this discussion on the web visit https://groups.google.com/d/msg/castle-project-users/-/Hemz4Mw0ZvQJ.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-u...@googlegroups.com.

[Kim Birkelund]

The issue server appears to be down and has for the last few days, so
can't check out the ticket.

But, if by fixed you mean that it'll no longer inject delegates for
return types (both value-types and reference-types) that aren't
registered in the container, then that'll probably fix the issue, in
the sense that we just wont use it.

I still think it a bit too intrusive to simply use any delegate types
and would prefer that it only injected the factory-interfaces that
were explicitly registered - as for all other dependencies.

For specific uses of the Windsor something like this may make sense,
but in our case we use delegates on components for a number of
different purposes, and something like this could well interrupt that
pattern (I'm not saying the way we do it is a good design-pattern
:-)).

I would still like a way of disabling the DelegateFactory entirely,
and preferably in a supported manner, instead of "violently" pulling
out the part I'm dissatisfied with.


--
Med venlig hilsen/Best regards

Kim Birkelund
Software Engineer
Cetrea A/S, Denmark
address: Brendstrupgårdsvej 21 F, DK-8200 Aarhus N.
phone : +45 3840 0570
e-mail : k...@cetrea.dk
w^3 : http://www.Cetrea.dk/

>> > castle-pro...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > castle-project-u...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/castle-project-users?hl=en.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/castle-project-users/-/Hemz4Mw0ZvQJ.
> To post to this group, send email to castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to
> castle-project-u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/castle-project-users?hl=en.
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Users" group.