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.
