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 > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
