Yes, eventually. It seemed to only happen when the .ctor parameter name (in
this case, "workDispatcher") was the same as the property name
("WorkDispatcher"), _and_ the same type.
Note also that I'm using XML file-based configuration, using the
<parameters> child of the <component> element to specify a specific
IDispatcher implementation, like so:
<component id="parserWorkQueue"
service="MyNameSpace.IWorkQueue`1[[MyNameSpace.ParserWorkItem,
MyAssembly]], MyAssembly"
type="MyNameSpace.WorkQueue`[[MyNameSpace.ParserWorkItem, MyAssembly]],
MyAssembly">
<parameters>
<workDispatcher>{$workItemDispatcher}</workDispatcher>
</parameters>
</component>
Any thoughts?
On Tue, Jul 21, 2009 at 8:59 AM, Jonathon Rossi <[email protected]> wrote:
> There should be no problem using a public getter and a private setter. I
> tried an example before and didn't get the exception you were getting with
> the old version.
>
> Are you considering upgrading?
>
>
> On Tue, Jul 21, 2009 at 10:36 PM, Michael Yeaney <[email protected]
> > wrote:
>
>> I had originally wanted consumers of the service to be able to talk to the
>> resolved dependency. For example, we have a WorkQueue<T> class that
>> internally needs an IDispatcher<T> instance to dispatch work out. I had
>> wanted consumers of the work queue class to be able to ask the dispatcher
>> for it's internal state directly (mainly stats), instead of re-exposing the
>> same information through the work queue itself. Hence, the private setter -
>> I only wanted external folks to read the data, never set it.
>> Does this help?
>>
>> On Tue, Jul 21, 2009 at 8:05 AM, Jonathon Rossi <[email protected]>wrote:
>>
>>> The object not set to an instance of an object exception is a bug, and
>>> has already been fixed.
>>>
>>> However, MK will still set mandatory and optional dependencies even
>>> though they are the same type. Is there a reason you want a non-private
>>> setter when the service dependency has already been fulfilled?
>>>
>>>
>>> On Tue, Jul 21, 2009 at 10:25 AM, Michael Yeaney <
>>> [email protected]> wrote:
>>>
>>>> Hi all...
>>>>
>>>> Using Castle.Microkernel version 1.0.3.0 (have not upgraded yet), and am
>>>> experiencing some rather strange behavior with the
>>>> DefaultComponentActivator
>>>> class. It seems that if you have a property (optional dependency) with
>>>> _exactly_ the same name as a constructor arg (required dependency),
>>>> DefaultComponentActivator will attempt to set the dependency not once
>>>> through the .ctor, but twice - once through the ctor, and again through the
>>>> property (via the SetUpProperties method).
>>>>
>>>> Normally, this isn't a big issue (although I am a bit curious as to why
>>>> the dependency is set a second time, after being satisfied through the
>>>> ctor). However, if the property in question has a private setter (in other
>>>> words, read-only, so external folks can view inside the object but not set
>>>> it), the Resolve<T> method will raise an "Object not set..." exception,
>>>> even
>>>> though the constructor has already been run and the component is alive.
>>>>
>>>> Is this a known issue with 1.0.3.0? If it's not a bug, can somebody
>>>> explain the logic behind this?
>>>>
>>>> Cheers!
>>>> Michael
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Jono
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Jono
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
