That makes sense. So far the only use case is I currently maintain a method that I use to dump the container state to the logs so I can 'peer' inside and see what is going on.
I guess it would be nice to just have a single method that would tell me if everything is configured correctly, where correctly is defined as all dependencies are met. I would think that even if something was generated at runtime you would have a way to check to see that something is there or not, but yeah some of the more advanced windsor features would be tricky. Thanks for the heads up :) -d 2010/9/22 Krzysztof Koźmic <[email protected]> > Dru, > > I do plan to do the following for vNext (subject to change): > > - add logging to the container itself similar to what Jono did in > DynamicProxy. It works well in DP > - expose some API to easier gain access to what's going on in the container > and run diagnostics... (to be used in Unit tests) > > in latest version you can plug the DefaultDebuggingSubSystem (it plugs > itself automatically if the debugger is attached at the time container is > being set up) and then interrogate it for the information it shows in the > debuggger (components with *potentially* missing dependencies, components > having *potentially *mismatched lifestyles...) > > The problem is that, due to dynamic nature of Windsor, what it detects > statically may be (and often is) overridden at runtime, so what might have > been an issue becomes a non-issue (say - dependencies are provided to a > component dynamically so although Windsor thought it is missing dependencies > all is fine) . > > This may give you both false positives and false negatives and I don't want > people to stop writing unit tests for their container configuration and rely > on container.Validate() solely. > > > So my question to you now - how would you use this method, and when? > > cheers, > Krzysztof > > > W dniu 23 września 2010 03:33 użytkownik Dru Sellers > <[email protected]>napisał: > >> is it possible to get something like structuremap's Validate method that I >> could then dump to the logs myself? >> -d >> >> >> >> 2010/9/19 Mauricio Scheffer <[email protected]> >> >>> Cool! those IContainerDebuggerExtensions are pretty much what I had in >>> mind :-) >>> >>> >>> 2010/9/19 Krzysztof Koźmic <[email protected]> >>> >>> Oh, and BTW - all the debugger view stuff is completely static as well >>>> - it uses the dependency graphs that Windsor builds internally, hence it >>>> does not detect stuff that gets attached dynamically. >>>> >>>> >>>> On 19/09/2010 3:55 PM, Mauricio Scheffer wrote: >>>> >>>> Spike is here: >>>> github.com/mausch...<http://github.com/mausch/Castle.Windsor.Diagnostics/blob/master/Castle.Windsor.Diagnostics.Tests/Tests.fs>(it's >>>> VERY rough) >>>> >>>> >>>> 2010/9/19 Mauricio Scheffer <[email protected]> >>>> >>>>> I started spiking something about this a couple of days ago... I was >>>>> thinking about semi-static analyses (i.e. without actually resolving >>>>> any components) to find common problems like cyclic dependencies, >>>>> lifestyle >>>>> issues, missing dependencies, and also visualizing the dependency graph. >>>>> I know lots of scenarios can't be analyzed like this, but it's still >>>>> better than nothing, as long as we don't have false positives. >>>>> These analyses would be then run as tests, their only input would be >>>>> the constructed IWindsorContainer instance. >>>>> Debugger visualizers are nice to have, but IMHO debugging and stepping >>>>> is the last resource. It's just better to have assertable tests, or at >>>>> least >>>>> something that generates some sort of report over the whole graph. >>>>> >>>>> -- >>>>> Mauricio >>>>> >>>>> >>>>> 2010/9/18 Krzysztof Koźmic <[email protected]> >>>>> >>>>> hehe, >>>>>> >>>>>> We'll do that also via logging in v3, but that requires adding loggin >>>>>> throughout the entire framework and big changes is something I wanted to >>>>>> avoid for .5 release. >>>>>> >>>>>> This provides best (cost*risk)/benefit ratio. And it has proven very >>>>>> valuable to me on several ocasions already :) >>>>>> And not just me: http://mookid.dk/oncode/archives/1553 >>>>>> >>>>>> cheers, >>>>>> >>>>>> Any other feedback? >>>>>> >>>>>> >>>>>> On 19/09/2010 11:28 AM, John Simons wrote: >>>>>> >>>>>> I think the idea of reporting such mismatches is great +1 but >>>>>> reporting them through visual debugger -1. >>>>>> Sorry mate. >>>>>> >>>>>> Cheers, John >>>>>> >>>>>> On 19/09/2010, at 11:09, Krzysztof Koźmic <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Windsor has no internal logging as of yet. >>>>>> >>>>>> I consider adding it for v3 but adding logging, or adding debugger >>>>>> visualizer is much more work. >>>>>> This works only if you start your app with attached debugger and break >>>>>> into the code where the container is in scope. >>>>>> >>>>>> Krzysztof >>>>>> >>>>>> On 19/09/2010 11:06 AM, John Simons wrote: >>>>>> >>>>>> So is this warning only available/visible in debug attached mode? >>>>>> Or can I also see it in my logs? >>>>>> I guess what I'm trying to say is that imho this would be more >>>>>> beneficial in the log then in the debugger visualiser. >>>>>> >>>>>> Cheers, John >>>>>> >>>>>> On 19/09/2010, at 9:47, Krzysztof Koźmic <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I've been working on a new addition for Windsor 2.5.1 in its debugger >>>>>> views support. >>>>>> The goal is to detect and report Singletons depending on Transients or >>>>>> PerWebRequest components (directly or indirectly) and report it. >>>>>> >>>>>> Here's how it looks like in action: >>>>>> <VS_live.png> >>>>>> >>>>>> I call it "Potential Lifestyle Mismatches", because there are some >>>>>> cases when what it reports is valid case. >>>>>> At the top level menu I show the number of such dependencies (sounds >>>>>> like the most reasonable thing to me). >>>>>> >>>>>> One level in I show each such (direct or indirect) dependency as >>>>>> "Depender" DependersLifestyle -> "Dependee" DependeesLifestyle >>>>>> Idea was to show enough information here, so that you don't need to go >>>>>> deeper to fix the issue. >>>>>> >>>>>> If you do want to go one level deeper though you get a descriptive >>>>>> message of the issue and list of all components in the dependency chain >>>>>> in >>>>>> question. >>>>>> >>>>>> So you can see that C (singleton) depends on B (singleton) which >>>>>> depends on A (Transient) >>>>>> >>>>>> The description message looks like this: >>>>>> >>>>>> <message.png> >>>>>> >>>>>> >>>>>> *So now I want your feedback here - am I showing the right >>>>>> information, is everything clear and intuitive?* >>>>>> The code is not yet pushed, I need to do some cleanup and testing >>>>>> first, which will take me an hour or two. >>>>>> >>>>>> cheers, >>>>>> Krzysztof >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Castle Project Development List" 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-devel?hl=en. >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Castle Project Development List" 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-devel?hl=en. >>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Castle Project Development List" 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-devel?hl=en. >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Castle Project Development List" 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-devel?hl=en. >>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Castle Project Development List" group. >>>>>> To post to this group, send email to >>>>>> [email protected]. >>>>>> To unsubscribe from this group, send email to >>>>>> [email protected]<castle-project-devel%[email protected]> >>>>>> . >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/group/castle-project-devel?hl=en. >>>>>> >>>>> >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Castle Project Development List" 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-devel?hl=en. >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Castle Project Development List" group. >>>> To post to this group, send email to >>>> [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]<castle-project-devel%[email protected]> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/castle-project-devel?hl=en. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Castle Project Development List" group. >>> To post to this group, send email to >>> [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<castle-project-devel%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/castle-project-devel?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Castle Project Development List" group. >> To post to this group, send email to >> [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<castle-project-devel%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/castle-project-devel?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]<castle-project-devel%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" 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-devel?hl=en.
