I like the pictures, but haven't had time to look at the
implementations.
I think some of the dependency viewer info is already available
somewhere else where we show the parents and children of each
configuration. Am I misled on this? Would it make any sense to
think about combining the views somehow?
I think these views would be very useful. Lets put them in and if
someone finds implementation problems we'll fix them (note I haven't
had time to look at how this was done :-)
thanks
david jencks
On Jan 5, 2007, at 10:06 AM, Rakesh Midha wrote:
Hello
First of all I am sorry for being missing from the list for last
few days, actually I have been trying to get this work item done. I
kinda liked the idea of having ClassLoader, JNDI and Dependency
views in console.
We have discussed this before in dev list, please read the
discussion below.
I got this thing working, so I created three JIRA's, Please have a
look at https://issues.apache.org/jira/browse/GERONIMO-2689
https://issues.apache.org/jira/browse/GERONIMO-2690
https://issues.apache.org/jira/browse/GERONIMO-2691
These three JIRA's adds 3 view in console which shows
1. JNDIView
This view shows all the JNDI names binded in various componet
contexts as well as Global context. Have a look at https://
issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gif
to get idea of what it will show. As we can see it shows JNDI names
for which are available at each component context level. For
details of how this is implemented please have a look at comments
of this JIRA.
2. ClassloaderView
This view shows all the classloaders and classes/interfaces loaded
by that classloader in heirarchical fashion. Have a look at https://
issues.apache.org/jira/secure/attachment/
12348333/12348333_classloader.gif to get idea of what it will show.
As we can see it shows classes and interfaces for all the
classloaders and its child classloaders. For details of how this is
implemented please have a look at comments of this JIRA.
3. DependencyView
This view shows all the components and repository items and its
dependencies in hierarchical fashion in which they are loaded. To
facilitate locating of items of interest the tree view can be
searched.. Have a look at https://issues.apache.org/jira/secure/
attachment/12348336/12348336_dependency.gif to get idea of what it
will show. As we can see it shows dependencies for each component.
For details of how this is implemented please have a look at
comments of this JIRA.
This is a request that please try these patches and let me know
your comments on it. I think I liked it and these views will
definatly be useful for debugging purpose, and from my expierance I
can tell that all these views are trying to facilitate solving of
problems which are difficult to tackle otherwise.
Also notice that we may like to add another section in navigation
for debug views as shown in https://issues.apache.org/jira/secure/
attachment/12348329/12348329_navigation.gif this is not implemented
for now but we may do it once we agree to put the above views in
console.
Thanks in advance, please do have a look and comment.
Rakesh
On 7/20/06, Erin Mulder <[EMAIL PROTECTED]> wrote:
Aaron Mulder wrote:
> http://people.apache.org/~ammulder/classloaders.png
>
> However, I'm not sure how useful it will be -- it'll show you
> dependencies at the class loader level, but it won't tell you which
> class loaders hold a particular class or which class loader you're
> actually getting at some point when an error is uncovered.
Also, it still needs arrows. :)
Right now, the code for that graph produces SVG. It would be great to
make it interactive so that you could drag the nodes around, click
on a
node to load a div that shows which classes are loaded in it, and
maybe
even collapse certain branches. At JavaOne, I got a few simple
JavaScript behaviors working with the graph prototype, but I'm not
sure
how complex it would be to add full-out drag and drop.
Perhaps you can throw the code into the sandbox so other people can
check it out and build on it? If I recall correctly, I was careful to
make sure that all of its dependencies have Apache-compatible
licenses,
(which was actually quite difficult).
Alternatively, someone could create and share a non-ASF-hosted plugin
that makes use of one of the many LGPL graph libraries out there.
Cheers,
Erin
