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 : [email protected] w^3 : http://www.Cetrea.dk/ On 19 May 2012 04:30, Krzysztof Koźmic <[email protected]> wrote: > 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 > > > On 18/05/2012 3:16 PM, Kim Birkelund wrote: > > 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 > > > On Thursday, 17 May 2012 10:11:30 UTC+2, Krzysztof Koźmic wrote: >> >> 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 >> >> On 09/05/2012 7:33 PM, Kim Birkelund wrote: >> > 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 >> > -- >> > 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 >> > [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. >> > -- > 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 [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. > > > -- > 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. -- 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.
