With 2 changes to your configuration (which I assume is gmail code), I set
up the same example using XML configuration and it resolves fine with a
private setter using the trunk. I'd suggest upgrading to 2.0 or the trunk.
MyNameSpace.WorkQueue`*1*[[MyNameSpace.ParserWorkItem, ...
<workDispatcher>*$*{workItemDispatcher}</workDispatcher>
On Tue, Jul 21, 2009 at 11:05 PM, Michael Yeaney
<[email protected]>wrote:
> 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
>>
>>
>>
>
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
