On 2/13/07, Rakesh Midha <[EMAIL PROTECTED]> wrote:
As Jarek said, I had discussion with him before on it.
Well, The only concern I have is, additing too many redundent view will make
console uninteresting. I think we need to be careful.
How about this? Instead of adding new view, we add a check or button in
existing view "Show inverse tree". Clicking or checking this will inverse
the tree in same view.
That's exactly what I had in mind when I mentioned toggling between
the two types of views (inverse versus standard classloader
hierarchy). sorry for not being clear about that. My suggestion was
to make the toggle button sensitive to the currently selected node in
the classloader tree. e.g. when the user selects a node and then
toggles to the alternate view they see the treepaths containing the
selected node already expanded and highlighted.
Technically, having inverse tree is not a hard work. I can take this task
and get it done.
Thanks
Rakesh
On 2/12/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
> Sounds useful. It would be great if the user could select a node and
> easily toggle between the two types of views. When that node appears
> in multiple places the tree could already have those paths expanded
> and the nodes highlighted.
>
> Best wishes,
> Paul
>
> On 2/12/07, Jarek Gawor < [EMAIL PROTECTED]> wrote:
> > I was talking to Rakesh about adding additional classloader view to
> > the Geronimo Console and we are wondering if people have any
> > comments/thoughts about it. The current view show the tree starting
> > with the system classloader and ends with child classloaders. Example:
> >
> > A
> > - B
> > - F
> > - C
> > - F
> >
> > In this case, A is a parent to B and C classloaders. And B, C are
> > parent classloaders to F.
> >
> > Now, because Geronimo supports multi parent classloaders sometimes
> > these child classloaders can appear in multiple places in the tree
> > (e.g. F). So I proposed kind of inverse view of the classloaders. For
> > example, for a given child classloader, I would like to see the parent
> > classloaders as child nodes of the tree. Given the example above the
> > tree would now look like:
> >
> > B
> > - A
> >
> > C
> > - A
> >
> > F
> > - B
> > - C
> >
> > Would other people find this useful? (I know I would :))
> >
> > Thanks,
> > Jarek
> >
>
