I like it very much. We've had a few times when with various auto-wiring
scenarios some components were missing or behaving strangely and we found
ourselves looking through the Handlers collection and figuring out things
manually.
So the debugger visualizer is great.  Logging will be even great-er but this
would be a large change that needs to be designed thoroughly so lets be
happy with what we get.

As for the solution - I think it would be beneficial to mark the lifestyle
in a visual way to make it distinct. Is there any way to tell the debugger
to present things in italics/bold ? if not, adding square brackets (or % or
^ sign, whatever) can help in making it clearer.



2010/9/19 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.
>



-- 
Ken Egozi.
http://www.kenegozi.com/blog
http://www.delver.com
http://www.musicglue.com
http://www.castleproject.org
http://www.idcc.co.il - הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם

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

Reply via email to