Why do you have ComponentOne and ComponentTwo both providing IRoot in
the first place in the container?
In most cases this ends up being one of the following:
- you're doing it wrong and you only need one of them
- one is a decorator of the other in which case simple service override
on the decorator is enough to handle this (or explicit ordering of the
registration)
- you want one most of the time and the other in few selected cases in
which case explicit ordering and service override in exceptional cases
will get you covered.
Krzysztof
On 11/03/2011 4:02 AM, Lundberg, Per wrote:
Hi,
Sorry about the delay on my behalf...
The problem is not mainly with ResolveAll<IRoot>(); that one works
correctly AFAIK.
The problem is with code like this:
[Inject]
public IRoot SomeComponent { get; set; }
(I’ve implemented the Inject attribute as a way to control whether
property injection will occur or not.)
Here, a dependency on IRoot is declared. But what if you have
ComponentOne and ComponentTwo both implementing IRoot (and being
registered as IRoot providers)? Either one will be chosen, and the
user (i.e. the person writing the code) will have no clue that this
ambiguity exists.
That’s what I am concerned about; I’d like to modify the injection in
this case so that a proper exception will be thrown, to alert the user
(= the developer) that something funny is about to take place… JAny
ideas? Perhaps “subresolvers” or something like that could be used.
Best regards,
Per Lundberg
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of
*Krzysztof Kozmic
*Sent:* den 7 mars 2011 01:21
*To:* [email protected]
*Subject:* Re: Windsor breaking change: changing how
container.ResolveAll works <-- your feedback needed
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. Its not exactly related to the topic no, but its an issue
Ive 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]>
[mailto:[email protected]] *On Behalf Of
*Krzysztof Kozmic
*Sent:* den 4 mars 2011 01:24
*To:* [email protected]
<mailto:[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]
<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]
<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.
