geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul McMahan" <paulmcma...@gmail.com>
Subject Re: ClassLoader, JNDI and Dependency views in console
Date Wed, 10 Jan 2007 18:01:04 GMT
Just to be clear, I'm not suggesting that the new viewers should be
implemented as plugins to the admin console.  The admin console
currently does not support pluggability, at least not in a very robust
way.   I am suggesting that the viewers be implemented as geronimo
plugins similar to how the ca-helper application was implemented.   It
is a separate webapp that can be installed as a plugin and can be
reached from the admin console's listing of webapps.    My concern is
that the admin console is becoming less focused on administrating the
server and more of a launching point for all sorts of native UIs.  If
we really want to make the admin console more useful then IMHO our
efforts would be better spent on improving the current function, such
as the partially implemented JMS administration portlet for example.
Ironically, I think the plugin administration portlet itself also
really needs some improvement.  :-)

Best wishes,
Paul

On 1/10/07, Donald Woods <drw_web@yahoo.com> wrote:
> UIs look great and I'd like to see them included in the Admin Console
> for 2.0.  If/When we start moving existing Portlets out as plug-ins,
> then at that time we should move this (along with the JMX and LDAP
> portlets) out as an optional plug-in....
>
> -Donald
>
>
>
> Paul McMahan wrote:
> > I think these new UIs look great and are very useful.  I'm in favor of
> > integrating them into Geronimo.  However, I am concerned about how the
> > patch integrates them.  I would very strongly prefer that they be
> > integrated as plugins instead of directly into the admin console.  As
> > a matter of fact I think several of the portlets in the current admin
> > console should eventually be factored out as plugins.  Then, as the
> > admin console moves towards a more plugin-centric approach the user
> > can integrate these UIs directly into the console or keep them as
> > separate webapps.
> >
> > Best wishes,
> > Paul
> >
> >
> > On 1/5/07, Rakesh Midha <midha.rakesh@gmail.com> 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 <meara@alumni.princeton.edu> 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
> >> >
> >>
> >>
> >
> >
>
>
>

Mime
View raw message