Well, IMO if you're calling ResolveAll<IRoot>() I would expect to find
some components for that service.
If you're only using IRoot for resolving all it should not affect
anything, and if you need to make sure service overrides should set you
up. I don't have all the picture so I'm talking in general terms but I'm
pretty sure that can be solved elegantly with the tools at hand.
On 07/03/2011 5:08 AM, Lundberg, Per wrote:
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. JWhat 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]>
[mailto:[email protected]] *On Behalf Of *Alex
Henderson
*Sent:* den 2 mars 2011 23:21
*To:* [email protected]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[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.
