Those were my typo's - my bad. Regardless, what you suggested is indeed what is in my configuration file. Looks like I'll start prep'ing for an upgrade - thanks for the help.
Michael On Tue, Jul 21, 2009 at 9:54 AM, Jonathon Rossi <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
