Hi That's a good idea, I think the component that is to be added "temporarily" would be in the child container then, right? I think that parent containers cannot resolve dependencies from child container (but children can resolve from parents), so I wouldn't get the entire story - I wouldn't known if my new component would be satisfying a dependency in the parent container. While I have use parent/child containers before, for a very specific need centered around object disposal - I have gotten then feeling that chained containers are avoided if possible.
Adam Sent from my iPhone On 22/05/2011, at 1:10 PM, João Bragança <[email protected]> wrote: > What if you registered it with a child container? Then you could > somehow calculate the diff of what is resolvable. > > On May 20, 3:57 pm, Krzysztof Kozmic <[email protected]> > wrote: >> Adam, >> >> That is an interesting idea. >> >> In Windsor v3 there's an interface called IDependencyInspector which >> you might use. It is called back from IHandler's (which implement >> IExposeDependencyInfo) with list of that handler's missing >> dependencies. >> >> I suppose you could then check type of those dependencies against the >> type you're about to register and collect information from there. >> >> It obviously is not a 100% accurate approach. A lot depends on how you >> register that type, which services you will expose from this type, if >> there are any service overrides etc. >> >> Krzysztof >> >> On May 16, 7:53 am, "Adam Langley" <[email protected]> wrote: >> >> >> >>> Team, >> >>> I am curious, I would like to know, ahead of time, what result adding a >>> new component to the MicroKernel will cause. >>> For example, say I have a few components already registered, but some >>> are currently 'awaiting dependencies'. I would like to know, if I were >>> to add another component to the kernel (which may or may not resolve >>> these dependencies), what components will be resolvable as a result... >>> but I dont want to _actually_register_it_ (yet). >>> I just want to be able to say to the user "If you add this new >>> component, it will itself be awaiting X dependencies..." or "It will be >>> utilised by Component Y to complete its dependencies" etc etc. >> >>> Then the user can decide whether or not they want to go ahead. >> >>> Summary: I want to be able to evaluate the change in ComponentModel to >>> the MicroKernel state, resulting from a component registration or >>> deregistration, ahead of time (without actually applying the >>> registrations). >> >>> How might I achieve this? Does Castle support transactional isolation of >>> component registration? Because that might be useful in this scenario... >> >>> Thanks, >> >>> Adam Langley > > -- > 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.
