Hehe, yes. It’s not exactly related to the topic no, but it’s an issue I’ve encountered previously with Castle Windsor.
In my specific case, I think the “problem” is that the components providing IRootService and IChildServiceOne, IChildServiceTwo etc. will be registered as a provider of both these interfaces (the root interface and the specific child interface), which is not optimal in my case since it can lead to scenarios when the application gets the “wrong” component. I think it could be related to how I register the components though (this is done using custom logic on my side, so it could be slightly broken). Only IChildServiceOne and IChildServiceTwo should be in the container; IRootService should not. I should look into that first I guess. It just “feels” that the Castle Windsor default behavior of random-cherrypickism is not my preferred way of having the component resolving to work. J What is the easiest way to tweak this? (I already have a service override mechanism in place; this is just to avoid shooting ourselves in our precious feet…) Best regards, Per Lundberg From: [email protected] [mailto:[email protected]] On Behalf Of Krzysztof Kozmic Sent: den 4 mars 2011 01:24 To: [email protected] Subject: Re: Windsor breaking change: changing how container.ResolveAll works <-- your feedback needed Per, What you're talking about is not really related to the topic at hand, but anyway... What you're talking about is a feature, not a bug. Windsor will provide you the first available component for that service when you're depending on it. If you need a specific one either don't use scanning, or use service overrides. Same with ResolveAll, it should not matter in which order you get the components. Krzysztof On 04/03/2011 5:10 AM, Lundberg, Per wrote: Hi, While the subject of changing registration semantics has been brought up... Has there been any previous discussion on the matter of Castle Windsors default behavior related to property-based injection (and possibly also Resolve<T>()) when there are multiple components providing a given service? Think of a scenario like this: there is a service called ISomeService, and SomeServiceProviderOne and SomeServiceProviderTwo are both implementing the ISomeService interface. Now, what happens when you try to inject a component of ISomeService is that Castle Windsor chooses an arbitrary component providing the given service. To me, this seems like a bad default behavior, but perhaps Im just not seeing the full picture here. J Id rather have Resolve<T>() throw an exception in this case, since the behavior is likely not completely predictable to the application using the container. Which component will it get? Now, you could say that the application shouldnt care, but in reality this might not be the case. You might have specific needs, implying that you want ISomeChildService rather than ISomeService, but perhaps you are yourself implementing some other interface which makes it impossible to change the property type for example. Is there a (simple) way to change this default behavior? Many thanks in advance! (And also, of course, the question is whether this default behavior is sane or not) Best regards, Per Lundberg From: [email protected] [mailto:[email protected]] On Behalf Of Alex Henderson Sent: den 2 mars 2011 23:21 To: [email protected] Subject: Re: Windsor breaking change: changing how container.ResolveAll works <-- your feedback needed +1 I didn't realise ResolveAll<> didn't just return those components explicitly registered for that service. I'm fine with the change, as it's deterministic/won't break anything I've got relying on that feature. Cheers, Alex On Thu, Mar 3, 2011 at 2:02 AM, Jason Meckley <[email protected]> wrote: I also thought Windsor only resolved all types explicitly registered. I wouldn't have a problem with this change. -- 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] <mailto:castle-project-users%[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. -- 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.
