You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rakesh Midha <mi...@gmail.com> on 2007/01/05 16:06:53 UTC
ClassLoader, JNDI and Dependency views in console
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.gifto
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.gifto
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.gifto
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.gifthis
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 <me...@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
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Lasantha Ranaweera <la...@opensource.lk>.
Hi Rakesh,
Looks like this is a fantastic idea. It will eliminate most of the user
problems and hope this feature will be pretty soon in G console.
Thanks,
Lasantha
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
> <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
> <ma...@alumni.princeton.edu>> wrote:
>
> Aaron Mulder wrote:
> > http://people.apache.org/~ammulder/classloaders.png
> <http://people.apache.org/%7Eammulder/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
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by "Christopher M. Cardona" <ch...@gmail.com>.
Hi Gianny,
That explains it. Your suggestion fixed the problem.
Thanks,
chris
Gianny Damour wrote:
> Hi Chris,
>
> I also had this problem. If you re-compile OpenEJB, then you should be
> fine. In a few words, ModuleConfigurer.getModuleType has been recently
> added and you are running with a EjbConfigurer which does not define
> this method.
>
> Thanks,
> Gianny
>
>
> On 08/01/2007, at 10:15 PM, Christopher M. Cardona wrote:
>
>> Rakesh,
>>
>> I tried combining your patches last time and I was able to build the
>> server but the it fails on startup with the following error:
>>
>> [*************************> ] 93% 20s Loading
>> org.apache.geronimo...19:29:49,3
>> 12 ERROR [DeploymentFactoryImpl]
>> java.lang.AbstractMethodError
>> at
>> org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initia
>> lize(JMXDeploymentManager.java:83)
>> at
>> org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.<ini
>> t>(LocalDeploymentManager.java:28)
>> at
>> org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl
>> .getDeploymentManager(DeploymentFactoryImpl.java:141)
>> at
>> org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment
>> Manager(DirectoryHotDeployer.java:317)
>> at
>> org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(Direc
>> toryHotDeployer.java:157)
>> at
>> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
>> nstance.java:984)
>> at
>> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
>> (GBeanInstanceState.java:267)
>> ...
>>
>> Not sure if I missed something. I'll give your combined patch a shot
>> and let you know.
>>
>> Best wishes,
>> chris
>>
>> Rakesh Midha wrote:
>>>
>>> Posted combined patch
>>> https://issues.apache.org/jira/secure/attachment/12348488/allviews.patch
>>> in JIRA 2689
>>>
>>> Please review and commit.
>>>
>>> Thanks
>>> Rakesh
>>>
>>> On 1/8/07, *Rakesh Midha* <midha.rakesh@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> Hello All,
>>>
>>> Thanks for quick review,
>>>
>>> Joe, You are right about the difference in two prespectivies, the
>>> debug view - dependencies is to show the hirarchical dependencies
>>> of all components, modules and it also list repository elements,
>>> whereas Config Manager is to list the potential ramifications if a
>>> configuration is removed.
>>>
>>> Another major difference being the Config Manager only shows
>>> serviceparents only, where as this view directly list the direct
>>> dependencies as well as serviceparents.
>>>
>>> Sachin, Prasad, David :
>>> About
>>>
>>> http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html
>>>
>>> it shows the static dependencies of the default server, and
>>> doens't list any customized services, repository elements,
>>> components and configurations deployed on server. The idea is to
>>> show the dependency information for a particular server in its
>>> console.
>>>
>>> I hope it clear all the points discussed here.
>>>
>>> Chris, As you suggested I will create a single patch for all three
>>> and post it in one of the JIRA. (Will inform once it is done).
>>>
>>> Thanks
>>> Rakesh
>>>
>>>
>>>
>>> On 1/5/07, *Christopher M. Cardona* <chris.m.cardona@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> Hi Rakesh,
>>>
>>> Thanks for the patches. I haven't looked at the source too but
>>> the pix
>>> looks good. It would be nice if you can create a combined
>>> patch for the
>>> 3 jiras so people who wanted to check out the new debug views
>>> can use
>>> this as another option.
>>>
>>> Best wishes,
>>> chris
>>>
>>> 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-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
>>>
>>>
>>> <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
>>>
>>>
>>> <https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gif>
>>>
>>> > <
>>>
>>> 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
>>> <ma...@alumni.princeton.edu>
>>> > <mailto: meara@alumni.princeton.edu
>>> <ma...@alumni.princeton.edu>>> wrote:
>>> >
>>> > Aaron Mulder wrote:
>>> > > http://people.apache.org/~ammulder/classloaders.png
>>> <http://people.apache.org/%7Eammulder/classloaders.png>
>>> > < http://people.apache.org/%7Eammulder/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
>>> >
>>> >
>>>
>>>
>>>
>>
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Rakesh Midha <mi...@gmail.com>.
Thanks Gianny
I didn't notice that I have recompiled openEJB, otherwise I would have
mentioned it in the comments. Thanks a lot, that saves my time :-)
Thanks
Rakesh
On 1/8/07, Gianny Damour <gi...@optusnet.com.au> wrote:
>
> Hi Chris,
>
> I also had this problem. If you re-compile OpenEJB, then you should
> be fine. In a few words, ModuleConfigurer.getModuleType has been
> recently added and you are running with a EjbConfigurer which does
> not define this method.
>
> Thanks,
> Gianny
>
>
> On 08/01/2007, at 10:15 PM, Christopher M. Cardona wrote:
>
> > Rakesh,
> >
> > I tried combining your patches last time and I was able to build
> > the server but the it fails on startup with the following error:
> >
> > [*************************> ] 93% 20s Loading
> > org.apache.geronimo...19:29:49,3
> > 12 ERROR [DeploymentFactoryImpl]
> > java.lang.AbstractMethodError
> > at
> > org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initia
> > lize(JMXDeploymentManager.java:83)
> > at
> > org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.<ini
> > t>(LocalDeploymentManager.java:28)
> > at
> > org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl
> > .getDeploymentManager(DeploymentFactoryImpl.java:141)
> > at
> > org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment
> > Manager(DirectoryHotDeployer.java:317)
> > at
> > org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(Direc
> > toryHotDeployer.java:157)
> > at
> > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
> > nstance.java:984)
> > at
> > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
> > (GBeanInstanceState.java:267)
> > ...
> >
> > Not sure if I missed something. I'll give your combined patch a
> > shot and let you know.
> >
> > Best wishes,
> > chris
> >
> > Rakesh Midha wrote:
> >>
> >> Posted combined patch https://issues.apache.org/jira/secure/
> >> attachment/12348488/allviews.patch in JIRA 2689
> >>
> >> Please review and commit.
> >>
> >> Thanks
> >> Rakesh
> >>
> >> On 1/8/07, *Rakesh Midha* <midha.rakesh@gmail.com
> >> <ma...@gmail.com>> wrote:
> >>
> >> Hello All,
> >>
> >> Thanks for quick review,
> >>
> >> Joe, You are right about the difference in two prespectivies, the
> >> debug view - dependencies is to show the hirarchical dependencies
> >> of all components, modules and it also list repository elements,
> >> whereas Config Manager is to list the potential ramifications
> >> if a
> >> configuration is removed.
> >>
> >> Another major difference being the Config Manager only shows
> >> serviceparents only, where as this view directly list the direct
> >> dependencies as well as serviceparents.
> >>
> >> Sachin, Prasad, David :
> >> About
> >> http://geronimo.apache.org/maven/server/modules/geronimo-
> >> webservices-builder/dependencies.html
> >> it shows the static dependencies of the default server, and
> >> doens't list any customized services, repository elements,
> >> components and configurations deployed on server. The idea is to
> >> show the dependency information for a particular server in its
> >> console.
> >>
> >> I hope it clear all the points discussed here.
> >>
> >> Chris, As you suggested I will create a single patch for all
> >> three
> >> and post it in one of the JIRA. (Will inform once it is done).
> >>
> >> Thanks
> >> Rakesh
> >>
> >>
> >>
> >> On 1/5/07, *Christopher M. Cardona* <chris.m.cardona@gmail.com
> >> <ma...@gmail.com>> wrote:
> >>
> >> Hi Rakesh,
> >>
> >> Thanks for the patches. I haven't looked at the source too
> >> but
> >> the pix
> >> looks good. It would be nice if you can create a combined
> >> patch for the
> >> 3 jiras so people who wanted to check out the new debug views
> >> can use
> >> this as another option.
> >>
> >> Best wishes,
> >> chris
> >>
> >> 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-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
> >> <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
> >> <https://issues.apache.org/jira/secure/attachment/
> >> 12348329/12348329_navigation.gif>
> >> > <
> >> 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
> >> <ma...@alumni.princeton.edu>
> >> > <mailto: meara@alumni.princeton.edu
> >> <ma...@alumni.princeton.edu>>> wrote:
> >> >
> >> > Aaron Mulder wrote:
> >> > > http://people.apache.org/~ammulder/classloaders.png
> >> <http://people.apache.org/%7Eammulder/classloaders.png>
> >> > < http://people.apache.org/%7Eammulder/
> >> 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
> >> >
> >> >
> >>
> >>
> >>
> >
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Gianny Damour <gi...@optusnet.com.au>.
Hi Chris,
I also had this problem. If you re-compile OpenEJB, then you should
be fine. In a few words, ModuleConfigurer.getModuleType has been
recently added and you are running with a EjbConfigurer which does
not define this method.
Thanks,
Gianny
On 08/01/2007, at 10:15 PM, Christopher M. Cardona wrote:
> Rakesh,
>
> I tried combining your patches last time and I was able to build
> the server but the it fails on startup with the following error:
>
> [*************************> ] 93% 20s Loading
> org.apache.geronimo...19:29:49,3
> 12 ERROR [DeploymentFactoryImpl]
> java.lang.AbstractMethodError
> at
> org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initia
> lize(JMXDeploymentManager.java:83)
> at
> org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.<ini
> t>(LocalDeploymentManager.java:28)
> at
> org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl
> .getDeploymentManager(DeploymentFactoryImpl.java:141)
> at
> org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment
> Manager(DirectoryHotDeployer.java:317)
> at
> org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(Direc
> toryHotDeployer.java:157)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
> nstance.java:984)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
> (GBeanInstanceState.java:267)
> ...
>
> Not sure if I missed something. I'll give your combined patch a
> shot and let you know.
>
> Best wishes,
> chris
>
> Rakesh Midha wrote:
>>
>> Posted combined patch https://issues.apache.org/jira/secure/
>> attachment/12348488/allviews.patch in JIRA 2689
>>
>> Please review and commit.
>>
>> Thanks
>> Rakesh
>>
>> On 1/8/07, *Rakesh Midha* <midha.rakesh@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> Hello All,
>>
>> Thanks for quick review,
>>
>> Joe, You are right about the difference in two prespectivies, the
>> debug view - dependencies is to show the hirarchical dependencies
>> of all components, modules and it also list repository elements,
>> whereas Config Manager is to list the potential ramifications
>> if a
>> configuration is removed.
>>
>> Another major difference being the Config Manager only shows
>> serviceparents only, where as this view directly list the direct
>> dependencies as well as serviceparents.
>>
>> Sachin, Prasad, David :
>> About
>> http://geronimo.apache.org/maven/server/modules/geronimo-
>> webservices-builder/dependencies.html
>> it shows the static dependencies of the default server, and
>> doens't list any customized services, repository elements,
>> components and configurations deployed on server. The idea is to
>> show the dependency information for a particular server in its
>> console.
>>
>> I hope it clear all the points discussed here.
>>
>> Chris, As you suggested I will create a single patch for all
>> three
>> and post it in one of the JIRA. (Will inform once it is done).
>>
>> Thanks
>> Rakesh
>>
>>
>>
>> On 1/5/07, *Christopher M. Cardona* <chris.m.cardona@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> Hi Rakesh,
>>
>> Thanks for the patches. I haven't looked at the source too
>> but
>> the pix
>> looks good. It would be nice if you can create a combined
>> patch for the
>> 3 jiras so people who wanted to check out the new debug views
>> can use
>> this as another option.
>>
>> Best wishes,
>> chris
>>
>> 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-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
>> <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
>> <https://issues.apache.org/jira/secure/attachment/
>> 12348329/12348329_navigation.gif>
>> > <
>> 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
>> <ma...@alumni.princeton.edu>
>> > <mailto: meara@alumni.princeton.edu
>> <ma...@alumni.princeton.edu>>> wrote:
>> >
>> > Aaron Mulder wrote:
>> > > http://people.apache.org/~ammulder/classloaders.png
>> <http://people.apache.org/%7Eammulder/classloaders.png>
>> > < http://people.apache.org/%7Eammulder/
>> 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
>> >
>> >
>>
>>
>>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Rakesh Midha <mi...@gmail.com>.
Hello
I got the Classloader tree size reduced by 90% using the manual links in
dojo tree, for all the classloaders which occurs multiple times. These links
are loaded only when parent node is expanded.
>From user perspective this will not make any difference, but internally all
the dojo functionality are changed.
This should take care of OutOfMemory and StackOverflow excception we were
getting.
Earlier the size of StringTree for dojo tree children was 6542173 chars, and
not it is reduced to 665019 chars for my Geronimo server. This is
imporvement is visible is tree loading, now it is much quicker.
I attached classloaderViewLinks.patch in
http://issues.apache.org/jira/browse/GERONIMO-2690, Please review and
commit.
Thanks
Rakesh
On 1/12/07, Paul McMahan <pa...@gmail.com> wrote:
>
> It seems there is some confusion about the difference between a
> Geronimo plugin and a view that "plugs in" to the admin console. This
> is probably due to the fact that we haven't really established the
> terminology and best practices behind these new concepts yet. To
> further complicate the issue we've also alluded to future capabilities
> that we want to add to the admin console to make it more "pluggable".
> This has made it very difficult to keep the conversation on track.
>
> In hindsight I think it was unwise for me to bring all this up in the
> context of a patch submission, a bit premature. Plugins and their
> relationship to the admin console is a pretty heavyweight concept and
> probably deserves to be discussed and documented via a wiki page.
> I'll go start writing something up asap to help get that discussion
> underway.
>
> So as I indicated earlier I'm +1 on committing the patch as-is and
> then factoring out the views from the admin console that should be
> implemented as plugins, if we decide that's the right way to go.
>
> Best wishes,
> Paul
>
> On 1/12/07, Vamsavardhana Reddy <c1...@gmail.com> wrote:
> > I don't know if I understand your comments about ca-helper app
> correctly.
> > The purpose of the ca-helper app is to enable users submit certificate
> > requests from web browsers (currently, from browsers that support KEYGEN
> > tag), download and install issued certificates into web
> browsers. Access to
> > the ca-helper application should not be controlled by "geronimo-admin"
> realm
> > and also the application exports certificates with appropriate mime type
> for
> > user certs and ca cert. ca-helper is not exactly the one that plugs in
> to
> > Geronimo Console and becomes the CA portlet. ca-helper app and CA
> portlet
> > have no common functionality.
> >
> > Vamsi
> >
> >
> > On 1/11/07, Paul McMahan <pa...@gmail.com> wrote:
> > > On 1/10/07, Kevan Miller <ke...@gmail.com> wrote:
> > > >
> > > > Paul,
> > > > Are you suggesting that we should start architecting the console to
> > > > be more pluggable? Or suggesting that Rakesh rewrite these viewers?
> > >
> > > We've talked about architecting the console to be more pluggable and
> > > I'm definitely in favor of that. But until that effort gets underway
> > > we still have the capability to make UIs pluggable into Geronimo by
> > > implementing them as standalone webapps. ca-helper is a good example
> > > of this approach. So really my question was whether or not Rakesh
> > > would consider wrappering the viewers as webapps that can then be
> > > installed as Geronimo plugins instead of integrating them directly
> > > into the console as portlets. If that's not going to work out then
> > > I'm fine with Donald's suggestion of integrating in their current form
> > > and making them into plugins later. The viewers are definitely a
> > > value contribution to Geronimo and I look forward to seeing them in
> > > our next release.
> > >
> > > Best wishes,
> > > Paul
> > >
> >
> >
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Paul McMahan <pa...@gmail.com>.
It seems there is some confusion about the difference between a
Geronimo plugin and a view that "plugs in" to the admin console. This
is probably due to the fact that we haven't really established the
terminology and best practices behind these new concepts yet. To
further complicate the issue we've also alluded to future capabilities
that we want to add to the admin console to make it more "pluggable".
This has made it very difficult to keep the conversation on track.
In hindsight I think it was unwise for me to bring all this up in the
context of a patch submission, a bit premature. Plugins and their
relationship to the admin console is a pretty heavyweight concept and
probably deserves to be discussed and documented via a wiki page.
I'll go start writing something up asap to help get that discussion
underway.
So as I indicated earlier I'm +1 on committing the patch as-is and
then factoring out the views from the admin console that should be
implemented as plugins, if we decide that's the right way to go.
Best wishes,
Paul
On 1/12/07, Vamsavardhana Reddy <c1...@gmail.com> wrote:
> I don't know if I understand your comments about ca-helper app correctly.
> The purpose of the ca-helper app is to enable users submit certificate
> requests from web browsers (currently, from browsers that support KEYGEN
> tag), download and install issued certificates into web browsers. Access to
> the ca-helper application should not be controlled by "geronimo-admin" realm
> and also the application exports certificates with appropriate mime type for
> user certs and ca cert. ca-helper is not exactly the one that plugs in to
> Geronimo Console and becomes the CA portlet. ca-helper app and CA portlet
> have no common functionality.
>
> Vamsi
>
>
> On 1/11/07, Paul McMahan <pa...@gmail.com> wrote:
> > On 1/10/07, Kevan Miller <ke...@gmail.com> wrote:
> > >
> > > Paul,
> > > Are you suggesting that we should start architecting the console to
> > > be more pluggable? Or suggesting that Rakesh rewrite these viewers?
> >
> > We've talked about architecting the console to be more pluggable and
> > I'm definitely in favor of that. But until that effort gets underway
> > we still have the capability to make UIs pluggable into Geronimo by
> > implementing them as standalone webapps. ca-helper is a good example
> > of this approach. So really my question was whether or not Rakesh
> > would consider wrappering the viewers as webapps that can then be
> > installed as Geronimo plugins instead of integrating them directly
> > into the console as portlets. If that's not going to work out then
> > I'm fine with Donald's suggestion of integrating in their current form
> > and making them into plugins later. The viewers are definitely a
> > value contribution to Geronimo and I look forward to seeing them in
> > our next release.
> >
> > Best wishes,
> > Paul
> >
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
I don't know if I understand your comments about ca-helper app correctly.
The purpose of the ca-helper app is to enable users submit certificate
requests from web browsers (currently, from browsers that support KEYGEN
tag), download and install issued certificates into web browsers. Access to
the ca-helper application should not be controlled by "geronimo-admin" realm
and also the application exports certificates with appropriate mime type for
user certs and ca cert. ca-helper is not exactly the one that plugs in to
Geronimo Console and becomes the CA portlet. ca-helper app and CA portlet
have no common functionality.
Vamsi
On 1/11/07, Paul McMahan <pa...@gmail.com> wrote:
>
> On 1/10/07, Kevan Miller <ke...@gmail.com> wrote:
> >
> > Paul,
> > Are you suggesting that we should start architecting the console to
> > be more pluggable? Or suggesting that Rakesh rewrite these viewers?
>
> We've talked about architecting the console to be more pluggable and
> I'm definitely in favor of that. But until that effort gets underway
> we still have the capability to make UIs pluggable into Geronimo by
> implementing them as standalone webapps. ca-helper is a good example
> of this approach. So really my question was whether or not Rakesh
> would consider wrappering the viewers as webapps that can then be
> installed as Geronimo plugins instead of integrating them directly
> into the console as portlets. If that's not going to work out then
> I'm fine with Donald's suggestion of integrating in their current form
> and making them into plugins later. The viewers are definitely a
> value contribution to Geronimo and I look forward to seeing them in
> our next release.
>
> Best wishes,
> Paul
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Paul McMahan <pa...@gmail.com>.
On 1/10/07, Kevan Miller <ke...@gmail.com> wrote:
>
> Paul,
> Are you suggesting that we should start architecting the console to
> be more pluggable? Or suggesting that Rakesh rewrite these viewers?
We've talked about architecting the console to be more pluggable and
I'm definitely in favor of that. But until that effort gets underway
we still have the capability to make UIs pluggable into Geronimo by
implementing them as standalone webapps. ca-helper is a good example
of this approach. So really my question was whether or not Rakesh
would consider wrappering the viewers as webapps that can then be
installed as Geronimo plugins instead of integrating them directly
into the console as portlets. If that's not going to work out then
I'm fine with Donald's suggestion of integrating in their current form
and making them into plugins later. The viewers are definitely a
value contribution to Geronimo and I look forward to seeing them in
our next release.
Best wishes,
Paul
Re: ClassLoader, JNDI and Dependency views in console
Posted by Rakesh Midha <mi...@gmail.com>.
Hello
Paul, I will definatly provide the this viewer as a plugin, but it may take
some time. :-) kinda stuck in other activities and JIRAs. But definatly do
it.
chris, About Nullpointer, I fixed it in updated patch available in JIRA
yesterday. I had fixed it in inital patch but somehow it went only in
seprate patch and not in combined patch. Anyways its fixed. but we should
consider changing configuration to return null and not String "null" if
attribute is missing.
About memory problem with Classloader, I am looking into it and I think I
have an idea how to improve it. Let me implement it and pass it as another
patch over the existing patch. I think I will be able to give it in a day or
two.
Actually the classloader tree is heavy because a single classloader occures
multiple times. I and thinking if I can load dojo tree in such a way that
such occurances can also be handled lazly. Let me fix it,I hope it will
help.
Thanks
Rakesh
On 1/12/07, Christopher M. Cardona <ch...@gmail.com> wrote:
>
> Kevan Miller wrote:
> > I'd like to commit what we have ATM and start addressing these issues
> > (memory, ejb jar, plugability) as bug fixes/enhancements. Anybody feel
> > strongly otherwise?
> >
> > --kevan
> >
> My only worry right now is the Classloader Viewer but I'm ok checking it
> in as is. If nobody complains I'll go ahead and commit the patches
> tomorrow night. This will give us another day for people to voice out
> any concerns they have and perhaps Rakesh can squeeze in a few fixes,
> enhancements, etc. ;-)
>
> Best wishes,
> chris
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Paul McMahan <pa...@gmail.com>.
On 1/11/07, Kevan Miller <ke...@gmail.com> wrote:
> I'd like to commit what we have ATM and start addressing these issues
> (memory, ejb jar, plugability) as bug fixes/enhancements. Anybody
> feel strongly otherwise?
+1
Re: ClassLoader, JNDI and Dependency views in console
Posted by "Christopher M. Cardona" <ch...@gmail.com>.
Kevan Miller wrote:
> I'd like to commit what we have ATM and start addressing these issues
> (memory, ejb jar, plugability) as bug fixes/enhancements. Anybody feel
> strongly otherwise?
>
> --kevan
>
My only worry right now is the Classloader Viewer but I'm ok checking it
in as is. If nobody complains I’ll go ahead and commit the patches
tomorrow night. This will give us another day for people to voice out
any concerns they have and perhaps Rakesh can squeeze in a few fixes,
enhancements, etc. ;-)
Best wishes,
chris
Re: ClassLoader, JNDI and Dependency views in console
Posted by Kevan Miller <ke...@gmail.com>.
On Jan 11, 2007, at 6:08 PM, Christopher M. Cardona wrote:
> Rakesh Midha wrote:
>> Hello Chris,
>>
>> Is there some specific scenerio where you are getting java heap
>> space error.
>>
>> What I am guessing is that there can be a scenerio where
>> classloaders are cyclic. Is it possible, that
>> Classloader C1 is a parent of Classloader C2
>> Classloader C2 is a parent of Classloader C3
>> Classloader C3 is a parent of Classloader C1
>>
> As David Jencks pointed out this is not allowed. I was wondering if
> our implementation enforces this. There are no specific steps to
> replicate the problem but I usually get it after reloading
> Classloader viewer portlet and doing searches a couple of times. So
> I’m guessing something is not being garbage collected or there’s a
> memory leak somewhere. I'll try to rebuild and see if it makes any
> difference.
It doesn't look like the problem is a memory leak. If you bump your
max heap a bit, I don't think you'll see the problem (e.g. export
JAVA_OPTS=-Xmx96m). The ClassLoader seems to be quite memory hungry.
I haven't looked to see what's going on, but would hope we could trim
things down a bit and be a little more efficient...
>
> BTW, I found another problem with the JNDI viewer portlet. After
> deploying a standalone ejb jar I get a NullPointerException when
> viewing the portlet. My guess is you forgot to consider the case
> where an ejb module is deployed and it’s not inside an ear file
> resulting to a null J2EE application.
Thanks for pointing this out.
Safari isn't working very well with these views. I get "Maximum call
stack exceeded" errors in the Javascript console. However, things
work ok (provided the server has enough memory) from Firefox and IE...
I'd like to commit what we have ATM and start addressing these issues
(memory, ejb jar, plugability) as bug fixes/enhancements. Anybody
feel strongly otherwise?
--kevan
Re: ClassLoader, JNDI and Dependency views in console
Posted by "Christopher M. Cardona" <ch...@gmail.com>.
Rakesh Midha wrote:
> Hello Chris,
>
> Is there some specific scenerio where you are getting java heap space
> error.
>
> What I am guessing is that there can be a scenerio where classloaders
> are cyclic. Is it possible, that
> Classloader C1 is a parent of Classloader C2
> Classloader C2 is a parent of Classloader C3
> Classloader C3 is a parent of Classloader C1
>
As David Jencks pointed out this is not allowed. I was wondering if our
implementation enforces this. There are no specific steps to replicate
the problem but I usually get it after reloading Classloader viewer
portlet and doing searches a couple of times. So I’m guessing something
is not being garbage collected or there’s a memory leak somewhere. I'll
try to rebuild and see if it makes any difference.
BTW, I found another problem with the JNDI viewer portlet. After
deploying a standalone ejb jar I get a NullPointerException when viewing
the portlet. My guess is you forgot to consider the case where an ejb
module is deployed and it’s not inside an ear file resulting to a null
J2EE application.
Best wishes,
chris
> If it is a possible, I need to figure out a way to know it and make
> changes in tree, else it will continue filling the tree in cyclic order.
>
> Anyone please let me know if the above scenerio is allowed or not. (If
> it is allowed how is classes loaded, it will continue looking for
> class in cyclic order forever and never load it.)
>
> Thanks
> Rakesh
>
> On 1/11/07, *Rakesh Midha* <midha.rakesh@gmail.com
> <ma...@gmail.com>> wrote:
>
> Oh I didnt see the JavaHeap space error about, let me check it out.
> thanks
> Rakesh
>
>
> On 1/11/07, * Christopher M. Cardona* < chris.m.cardona@gmail.com
> <ma...@gmail.com>> wrote:
>
> Kevan,
>
> FYI, I updated
> https://issues.apache.org/jira/browse/GERONIMO-2689 to
> include a patch that will fix the javascript error. You should
> be able
> to view the new portlets at least. Please let me know if you
> still get
> problems.
>
> Best wishes,
> chris
>
> Kevan Miller wrote:
> >
> > On Jan 10, 2007, at 2:37 PM, Christopher M. Cardona wrote:
> >
> >> Hi Rakesh,
> >>
> >> I was able to run the new portlets using trunk rev494034 but
> needed
> >> to change all view.jsps because I get javascript errors
> related to
> >> your calls to dojo.require(). The console uses Dojo 0.4.1
> right now
> >> and I'm guessing you used a different version during
> development.
> >> Some widget names changed in 0.4.1.
> >>
> >> I'm getting a different problem this time using the ClassLoader
> >> viewer. I get javax.servlet.ServletException: Java heap space:
> >
> > I've seen this error, also. None of the views were working
> for me.
> > Wasn't sure if it was a Safari issue or something else.
> Rakesh, can
> > you take a look at these issues (javascript errors and memory
> > consumption by ClassLoader viewer)?
> >
> > Paul,
> > Are you suggesting that we should start architecting the
> console to be
> > more pluggable? Or suggesting that Rakesh rewrite these viewers?
> >
> > --kevan
> >
>
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by David Jencks <da...@yahoo.com>.
On Jan 11, 2007, at 2:39 AM, Rakesh Midha wrote:
> Hello Chris,
>
> Is there some specific scenerio where you are getting java heap
> space error.
>
> What I am guessing is that there can be a scenerio where
> classloaders are cyclic. Is it possible, that
> Classloader C1 is a parent of Classloader C2
> Classloader C2 is a parent of Classloader C3
> Classloader C3 is a parent of Classloader C1
That's definitely not allowed. The classloaders form a directed
acyclic graph.
thanks
david jencks
>
> If it is a possible, I need to figure out a way to know it and make
> changes in tree, else it will continue filling the tree in cyclic
> order.
>
> Anyone please let me know if the above scenerio is allowed or not.
> (If it is allowed how is classes loaded, it will continue looking
> for class in cyclic order forever and never load it.)
>
> Thanks
> Rakesh
>
> On 1/11/07, Rakesh Midha <mi...@gmail.com> wrote:
> Oh I didnt see the JavaHeap space error about, let me check it out.
> thanks
> Rakesh
>
>
> On 1/11/07, Christopher M. Cardona < chris.m.cardona@gmail.com> wrote:
> Kevan,
>
> FYI, I updated https://issues.apache.org/jira/browse/GERONIMO-2689 to
> include a patch that will fix the javascript error. You should be able
> to view the new portlets at least. Please let me know if you still get
> problems.
>
> Best wishes,
> chris
>
> Kevan Miller wrote:
> >
> > On Jan 10, 2007, at 2:37 PM, Christopher M. Cardona wrote:
> >
> >> Hi Rakesh,
> >>
> >> I was able to run the new portlets using trunk rev494034 but needed
> >> to change all view.jsps because I get javascript errors related to
> >> your calls to dojo.require(). The console uses Dojo 0.4.1 right now
> >> and I'm guessing you used a different version during development.
> >> Some widget names changed in 0.4.1.
> >>
> >> I'm getting a different problem this time using the ClassLoader
> >> viewer. I get javax.servlet.ServletException: Java heap space:
> >
> > I've seen this error, also. None of the views were working for me.
> > Wasn't sure if it was a Safari issue or something else. Rakesh, can
> > you take a look at these issues (javascript errors and memory
> > consumption by ClassLoader viewer)?
> >
> > Paul,
> > Are you suggesting that we should start architecting the console
> to be
> > more pluggable? Or suggesting that Rakesh rewrite these viewers?
> >
> > --kevan
> >
>
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Rakesh Midha <mi...@gmail.com>.
Hello Chris,
Is there some specific scenerio where you are getting java heap space error.
What I am guessing is that there can be a scenerio where classloaders are
cyclic. Is it possible, that
Classloader C1 is a parent of Classloader C2
Classloader C2 is a parent of Classloader C3
Classloader C3 is a parent of Classloader C1
If it is a possible, I need to figure out a way to know it and make changes
in tree, else it will continue filling the tree in cyclic order.
Anyone please let me know if the above scenerio is allowed or not. (If it is
allowed how is classes loaded, it will continue looking for class in cyclic
order forever and never load it.)
Thanks
Rakesh
On 1/11/07, Rakesh Midha <mi...@gmail.com> wrote:
>
> Oh I didnt see the JavaHeap space error about, let me check it out.
> thanks
> Rakesh
>
> On 1/11/07, Christopher M. Cardona < chris.m.cardona@gmail.com> wrote:
> >
> > Kevan,
> >
> > FYI, I updated https://issues.apache.org/jira/browse/GERONIMO-2689 to
> > include a patch that will fix the javascript error. You should be able
> > to view the new portlets at least. Please let me know if you still get
> > problems.
> >
> > Best wishes,
> > chris
> >
> > Kevan Miller wrote:
> > >
> > > On Jan 10, 2007, at 2:37 PM, Christopher M. Cardona wrote:
> > >
> > >> Hi Rakesh,
> > >>
> > >> I was able to run the new portlets using trunk rev494034 but needed
> > >> to change all view.jsps because I get javascript errors related to
> > >> your calls to dojo.require(). The console uses Dojo 0.4.1 right now
> > >> and I'm guessing you used a different version during development.
> > >> Some widget names changed in 0.4.1.
> > >>
> > >> I'm getting a different problem this time using the ClassLoader
> > >> viewer. I get javax.servlet.ServletException: Java heap space:
> > >
> > > I've seen this error, also. None of the views were working for me.
> > > Wasn't sure if it was a Safari issue or something else. Rakesh, can
> > > you take a look at these issues (javascript errors and memory
> > > consumption by ClassLoader viewer)?
> > >
> > > Paul,
> > > Are you suggesting that we should start architecting the console to be
> > > more pluggable? Or suggesting that Rakesh rewrite these viewers?
> > >
> > > --kevan
> > >
> >
> >
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Rakesh Midha <mi...@gmail.com>.
Oh I didnt see the JavaHeap space error about, let me check it out.
thanks
Rakesh
On 1/11/07, Christopher M. Cardona <ch...@gmail.com> wrote:
>
> Kevan,
>
> FYI, I updated https://issues.apache.org/jira/browse/GERONIMO-2689 to
> include a patch that will fix the javascript error. You should be able
> to view the new portlets at least. Please let me know if you still get
> problems.
>
> Best wishes,
> chris
>
> Kevan Miller wrote:
> >
> > On Jan 10, 2007, at 2:37 PM, Christopher M. Cardona wrote:
> >
> >> Hi Rakesh,
> >>
> >> I was able to run the new portlets using trunk rev494034 but needed
> >> to change all view.jsps because I get javascript errors related to
> >> your calls to dojo.require(). The console uses Dojo 0.4.1 right now
> >> and I'm guessing you used a different version during development.
> >> Some widget names changed in 0.4.1.
> >>
> >> I'm getting a different problem this time using the ClassLoader
> >> viewer. I get javax.servlet.ServletException: Java heap space:
> >
> > I've seen this error, also. None of the views were working for me.
> > Wasn't sure if it was a Safari issue or something else. Rakesh, can
> > you take a look at these issues (javascript errors and memory
> > consumption by ClassLoader viewer)?
> >
> > Paul,
> > Are you suggesting that we should start architecting the console to be
> > more pluggable? Or suggesting that Rakesh rewrite these viewers?
> >
> > --kevan
> >
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by "Christopher M. Cardona" <ch...@gmail.com>.
Kevan,
FYI, I updated https://issues.apache.org/jira/browse/GERONIMO-2689 to
include a patch that will fix the javascript error. You should be able
to view the new portlets at least. Please let me know if you still get
problems.
Best wishes,
chris
Kevan Miller wrote:
>
> On Jan 10, 2007, at 2:37 PM, Christopher M. Cardona wrote:
>
>> Hi Rakesh,
>>
>> I was able to run the new portlets using trunk rev494034 but needed
>> to change all view.jsps because I get javascript errors related to
>> your calls to dojo.require(). The console uses Dojo 0.4.1 right now
>> and I'm guessing you used a different version during development.
>> Some widget names changed in 0.4.1.
>>
>> I'm getting a different problem this time using the ClassLoader
>> viewer. I get javax.servlet.ServletException: Java heap space:
>
> I've seen this error, also. None of the views were working for me.
> Wasn't sure if it was a Safari issue or something else. Rakesh, can
> you take a look at these issues (javascript errors and memory
> consumption by ClassLoader viewer)?
>
> Paul,
> Are you suggesting that we should start architecting the console to be
> more pluggable? Or suggesting that Rakesh rewrite these viewers?
>
> --kevan
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Kevan Miller <ke...@gmail.com>.
On Jan 10, 2007, at 2:37 PM, Christopher M. Cardona wrote:
> Hi Rakesh,
>
> I was able to run the new portlets using trunk rev494034 but needed
> to change all view.jsps because I get javascript errors related to
> your calls to dojo.require(). The console uses Dojo 0.4.1 right now
> and I'm guessing you used a different version during development.
> Some widget names changed in 0.4.1.
>
> I'm getting a different problem this time using the ClassLoader
> viewer. I get javax.servlet.ServletException: Java heap space:
I've seen this error, also. None of the views were working for me.
Wasn't sure if it was a Safari issue or something else. Rakesh, can
you take a look at these issues (javascript errors and memory
consumption by ClassLoader viewer)?
Paul,
Are you suggesting that we should start architecting the console to
be more pluggable? Or suggesting that Rakesh rewrite these viewers?
--kevan
Re: ClassLoader, JNDI and Dependency views in console
Posted by "Christopher M. Cardona" <ch...@gmail.com>.
Hi Rakesh,
I was able to run the new portlets using trunk rev494034 but needed to
change all view.jsps because I get javascript errors related to your
calls to dojo.require(). The console uses Dojo 0.4.1 right now and I'm
guessing you used a different version during development. Some widget
names changed in 0.4.1.
I'm getting a different problem this time using the ClassLoader viewer.
I get javax.servlet.ServletException: Java heap space:
16:39:38,000 ERROR [PortletFragment] Error in Portlet
javax.portlet.PortletException
at
org.apache.pluto.core.impl.PortletRequestDispatcherImpl.include(Portl
etRequestDispatcherImpl.java:76)
at
org.apache.geronimo.console.classloaderview.ClassLoaderViewPortlet.do
View(ClassLoaderViewPortlet.java:64)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218
)
at
org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:683)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:585)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:505)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke
rImpl.java:120)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvoke
rImpl.java:73)
at
org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerI
mpl.java:119)
at
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPo
rtlet(PortletContainerWrapperImpl.java:70)
at
org.apache.pluto.portalImpl.aggregation.PortletFragment.service(Portl
etFragment.java:168)
at
jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFrag
ment_jsp.java:70)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:683)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:585)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:505)
at
org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(Abst
ractFragment.java:112)
at
jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_j
sp.java:67)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:683)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:585)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:505)
at
org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(Abst
ractFragment.java:112)
at
jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment
_jsp.java:71)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:683)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:585)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:505)
at
org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(Abst
ractFragment.java:112)
at
jsp.WEB_002dINF.aggregation.RootFragment_jsp._jspService(RootFragment
_jsp.java:109)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:683)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:585)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:505)
at
org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(Abst
ractFragment.java:112)
at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:254)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:228)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
bjectValve.java:56)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
torBase.java:525)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
invoke(GeronimoStandardContext.java:329)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
nimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
542)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:212)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:818)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ss(Http11Protocol.java:624)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
5)
at java.lang.Thread.run(Thread.java:595)
Caused by: javax.servlet.ServletException: Java heap space
at
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageC
ontextImpl.java:855)
at
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageCon
textImpl.java:784)
at
org.apache.jsp.WEB_002dINF.view.classloaderview.view_jsp._jspService(
view_jsp.java:273)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper
.java:390)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
20)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:683)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:585)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:505)
at
org.apache.pluto.core.impl.PortletRequestDispatcherImpl.include(Portl
etRequestDispatcherImpl.java:65)
... 74 more
Nested Exception is
javax.servlet.ServletException: Java heap space
at
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageC
ontextImpl.java:855)
at
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageCon
textImpl.java:784)
at
org.apache.jsp.WEB_002dINF.view.classloaderview.view_jsp._jspService(
view_jsp.java:273)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper
.java:390)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
20)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:683)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:585)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:505)
at
org.apache.pluto.core.impl.PortletRequestDispatcherImpl.include(Portl
etRequestDispatcherImpl.java:65)
at
org.apache.geronimo.console.classloaderview.ClassLoaderViewPortlet.do
View(ClassLoaderViewPortlet.java:64)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218
)
at
org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:683)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:585)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:505)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke
rImpl.java:120)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvoke
rImpl.java:73)
at
org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerI
mpl.java:119)
at
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPo
rtlet(PortletContainerWrapperImpl.java:70)
at
org.apache.pluto.portalImpl.aggregation.PortletFragment.service(Portl
etFragment.java:168)
at
jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFrag
ment_jsp.java:70)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:683)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:585)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:505)
at
org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(Abst
ractFragment.java:112)
at
jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_j
sp.java:67)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:683)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:585)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:505)
at
org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(Abst
ractFragment.java:112)
at
jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment
_jsp.java:71)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:683)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:585)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:505)
at
org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(Abst
ractFragment.java:112)
at
jsp.WEB_002dINF.aggregation.RootFragment_jsp._jspService(RootFragment
_jsp.java:109)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:683)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD
ispatcher.java:585)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis
patcher.java:505)
at
org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(Abst
ractFragment.java:112)
at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:254)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:228)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
bjectValve.java:56)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
torBase.java:525)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
invoke(GeronimoStandardContext.java:329)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
nimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
542)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:212)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:818)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ss(Http11Protocol.java:624)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
5)
at java.lang.Thread.run(Thread.java:595)
Have you seen this error? Didn't try debugging but it might be related
to how you build the tree nodes.
Best wishes,
chris
Rakesh Midha wrote:
> I am not sure what this problem is, please let me know what version of
> geronimo you are using and I will try it and let you know.
>
> Thanks
> Rakesh
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Rakesh Midha <mi...@gmail.com>.
I am not sure what this problem is, please let me know what version of
geronimo you are using and I will try it and let you know.
Thanks
Rakesh
On 1/8/07, Christopher M. Cardona <ch...@gmail.com> wrote:
>
> Rakesh,
>
> I tried combining your patches last time and I was able to build the
> server but the it fails on startup with the following error:
>
> [*************************> ] 93% 20s Loading
> org.apache.geronimo...19:29:49,3
> 12 ERROR [DeploymentFactoryImpl]
> java.lang.AbstractMethodError
> at
> org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initia
> lize(JMXDeploymentManager.java:83)
> at
> org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.<ini
> t>(LocalDeploymentManager.java:28)
> at
> org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl
> .getDeploymentManager(DeploymentFactoryImpl.java:141)
> at
> org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment
> Manager(DirectoryHotDeployer.java:317)
> at
> org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(Direc
> toryHotDeployer.java:157)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
> nstance.java:984)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
> (GBeanInstanceState.java:267)
> ...
>
> Not sure if I missed something. I'll give your combined patch a shot and
> let you know.
>
> Best wishes,
> chris
>
> Rakesh Midha wrote:
> >
> > Posted combined patch
> > https://issues.apache.org/jira/secure/attachment/12348488/allviews.patch
> > in JIRA 2689
> >
> > Please review and commit.
> >
> > Thanks
> > Rakesh
> >
> > On 1/8/07, *Rakesh Midha* <midha.rakesh@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > Hello All,
> >
> > Thanks for quick review,
> >
> > Joe, You are right about the difference in two prespectivies, the
> > debug view - dependencies is to show the hirarchical dependencies
> > of all components, modules and it also list repository elements,
> > whereas Config Manager is to list the potential ramifications if a
> > configuration is removed.
> >
> > Another major difference being the Config Manager only shows
> > serviceparents only, where as this view directly list the direct
> > dependencies as well as serviceparents.
> >
> > Sachin, Prasad, David :
> > About
> >
> http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html
> > it shows the static dependencies of the default server, and
> > doens't list any customized services, repository elements,
> > components and configurations deployed on server. The idea is to
> > show the dependency information for a particular server in its
> > console.
> >
> > I hope it clear all the points discussed here.
> >
> > Chris, As you suggested I will create a single patch for all three
> > and post it in one of the JIRA. (Will inform once it is done).
> >
> > Thanks
> > Rakesh
> >
> >
> >
> > On 1/5/07, *Christopher M. Cardona* <chris.m.cardona@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > Hi Rakesh,
> >
> > Thanks for the patches. I haven't looked at the source too but
> > the pix
> > looks good. It would be nice if you can create a combined
> > patch for the
> > 3 jiras so people who wanted to check out the new debug views
> > can use
> > this as another option.
> >
> > Best wishes,
> > chris
> >
> > 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-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
> > <
> 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
> > <
> https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gif
> >
> > > <
> >
> 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
> > <ma...@alumni.princeton.edu>
> > > <mailto: meara@alumni.princeton.edu
> > <ma...@alumni.princeton.edu>>> wrote:
> > >
> > > Aaron Mulder wrote:
> > > > http://people.apache.org/~ammulder/classloaders.png
> > <http://people.apache.org/%7Eammulder/classloaders.png>
> > > < http://people.apache.org/%7Eammulder/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
> > >
> > >
> >
> >
> >
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by "Christopher M. Cardona" <ch...@gmail.com>.
Rakesh,
I tried combining your patches last time and I was able to build the
server but the it fails on startup with the following error:
[*************************> ] 93% 20s Loading
org.apache.geronimo...19:29:49,3
12 ERROR [DeploymentFactoryImpl]
java.lang.AbstractMethodError
at
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initia
lize(JMXDeploymentManager.java:83)
at
org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.<ini
t>(LocalDeploymentManager.java:28)
at
org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl
.getDeploymentManager(DeploymentFactoryImpl.java:141)
at
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment
Manager(DirectoryHotDeployer.java:317)
at
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(Direc
toryHotDeployer.java:157)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
nstance.java:984)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
(GBeanInstanceState.java:267)
...
Not sure if I missed something. I'll give your combined patch a shot and
let you know.
Best wishes,
chris
Rakesh Midha wrote:
>
> Posted combined patch
> https://issues.apache.org/jira/secure/attachment/12348488/allviews.patch
> in JIRA 2689
>
> Please review and commit.
>
> Thanks
> Rakesh
>
> On 1/8/07, *Rakesh Midha* <midha.rakesh@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hello All,
>
> Thanks for quick review,
>
> Joe, You are right about the difference in two prespectivies, the
> debug view - dependencies is to show the hirarchical dependencies
> of all components, modules and it also list repository elements,
> whereas Config Manager is to list the potential ramifications if a
> configuration is removed.
>
> Another major difference being the Config Manager only shows
> serviceparents only, where as this view directly list the direct
> dependencies as well as serviceparents.
>
> Sachin, Prasad, David :
> About
> http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html
> it shows the static dependencies of the default server, and
> doens't list any customized services, repository elements,
> components and configurations deployed on server. The idea is to
> show the dependency information for a particular server in its
> console.
>
> I hope it clear all the points discussed here.
>
> Chris, As you suggested I will create a single patch for all three
> and post it in one of the JIRA. (Will inform once it is done).
>
> Thanks
> Rakesh
>
>
>
> On 1/5/07, *Christopher M. Cardona* <chris.m.cardona@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi Rakesh,
>
> Thanks for the patches. I haven't looked at the source too but
> the pix
> looks good. It would be nice if you can create a combined
> patch for the
> 3 jiras so people who wanted to check out the new debug views
> can use
> this as another option.
>
> Best wishes,
> chris
>
> 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-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
> <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
> <https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gif>
> > <
> 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
> <ma...@alumni.princeton.edu>
> > <mailto: meara@alumni.princeton.edu
> <ma...@alumni.princeton.edu>>> wrote:
> >
> > Aaron Mulder wrote:
> > > http://people.apache.org/~ammulder/classloaders.png
> <http://people.apache.org/%7Eammulder/classloaders.png>
> > < http://people.apache.org/%7Eammulder/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
> >
> >
>
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Rakesh Midha <mi...@gmail.com>.
Posted combined patch
https://issues.apache.org/jira/secure/attachment/12348488/allviews.patch in
JIRA 2689
Please review and commit.
Thanks
Rakesh
On 1/8/07, Rakesh Midha <mi...@gmail.com> wrote:
>
> Hello All,
>
> Thanks for quick review,
>
> Joe, You are right about the difference in two prespectivies, the debug
> view - dependencies is to show the hirarchical dependencies of all
> components, modules and it also list repository elements, whereas Config
> Manager is to list the potential ramifications if a configuration is
> removed.
>
> Another major difference being the Config Manager only shows
> serviceparents only, where as this view directly list the direct
> dependencies as well as serviceparents.
>
> Sachin, Prasad, David :
> About
> http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html
> it shows the static dependencies of the default server, and doens't list
> any customized services, repository elements, components and configurations
> deployed on server. The idea is to show the dependency information for a
> particular server in its console.
>
> I hope it clear all the points discussed here.
>
> Chris, As you suggested I will create a single patch for all three and
> post it in one of the JIRA. (Will inform once it is done).
>
> Thanks
> Rakesh
>
>
> On 1/5/07, Christopher M. Cardona <ch...@gmail.com> wrote:
> >
> > Hi Rakesh,
> >
> > Thanks for the patches. I haven't looked at the source too but the pix
> > looks good. It would be nice if you can create a combined patch for the
> > 3 jiras so people who wanted to check out the new debug views can use
> > this as another option.
> >
> > Best wishes,
> > chris
> >
> > 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
> > > <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
> > > <mailto:meara@alumni.princeton.edu >> wrote:
> > >
> > > Aaron Mulder wrote:
> > > > http://people.apache.org/~ammulder/classloaders.png<http://people.apache.org/%7Eammulder/classloaders.png>
> > > < http://people.apache.org/%7Eammulder/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
> > >
> > >
> >
> >
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Rakesh Midha <mi...@gmail.com>.
Hello All,
Thanks for quick review,
Joe, You are right about the difference in two prespectivies, the debug view
- dependencies is to show the hirarchical dependencies of all components,
modules and it also list repository elements, whereas Config Manager is to
list the potential ramifications if a configuration is removed.
Another major difference being the Config Manager only shows serviceparents
only, where as this view directly list the direct dependencies as well as
serviceparents.
Sachin, Prasad, David :
About
http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html
it shows the static dependencies of the default server, and doens't list any
customized services, repository elements, components and configurations
deployed on server. The idea is to show the dependency information for a
particular server in its console.
I hope it clear all the points discussed here.
Chris, As you suggested I will create a single patch for all three and post
it in one of the JIRA. (Will inform once it is done).
Thanks
Rakesh
On 1/5/07, Christopher M. Cardona <ch...@gmail.com> wrote:
>
> Hi Rakesh,
>
> Thanks for the patches. I haven't looked at the source too but the pix
> looks good. It would be nice if you can create a combined patch for the
> 3 jiras so people who wanted to check out the new debug views can use
> this as another option.
>
> Best wishes,
> chris
>
> 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
> > <
> 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
> > <ma...@alumni.princeton.edu>> wrote:
> >
> > Aaron Mulder wrote:
> > > http://people.apache.org/~ammulder/classloaders.png
> > <http://people.apache.org/%7Eammulder/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
> >
> >
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by "Christopher M. Cardona" <ch...@gmail.com>.
Hi Rakesh,
Thanks for the patches. I haven't looked at the source too but the pix
looks good. It would be nice if you can create a combined patch for the
3 jiras so people who wanted to check out the new debug views can use
this as another option.
Best wishes,
chris
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
> <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
> <ma...@alumni.princeton.edu>> wrote:
>
> Aaron Mulder wrote:
> > http://people.apache.org/~ammulder/classloaders.png
> <http://people.apache.org/%7Eammulder/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
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Sachin Patel <sp...@gmail.com>.
Ignore my comment, I overlooked the search field in the image. :)
On 1/5/07, Sachin Patel <sp...@gmail.com> wrote:
>
> Nice screenshots! One thought would be to have a filter field, which could
> be used to dynamically hide certain packages from view, or to search for
> certain items.
> 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.gifto 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.gifto 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.gifto 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 <me...@alumni.princeton.edu> wrote:
> >
> > Aaron Mulder wrote:
> > > http://people.apache.org/~ammulder/classloaders.png<http://people.apache.org/%7Eammulder/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
> >
>
>
>
> -sachin
>
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Sachin Patel <sp...@gmail.com>.
Nice screenshots! One thought would be to have a filter field, which
could be used to dynamically hide certain packages from view, or to
search for certain items.
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 <me...@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
>
-sachin
Re: ClassLoader, JNDI and Dependency views in console
Posted by Paul McMahan <pa...@gmail.com>.
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 <dr...@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 <mi...@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 <me...@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
> >> >
> >>
> >>
> >
> >
>
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Donald Woods <dr...@yahoo.com>.
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 <mi...@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 <me...@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
>> >
>>
>>
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Paul McMahan <pa...@gmail.com>.
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 <mi...@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 <me...@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
> >
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by David Jencks <da...@yahoo.com>.
p.s. I didn't see the openejb remote jndi implementation shown in
the jndi viewer, although I might have just missed it. Would it be
possible to add it as well? It's possible that openejb3 may be doing
this differently, so it might be a good idea to ask about that.
thanks
david jencks
On Jan 5, 2007, at 10:20 AM, David Jencks wrote:
> 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 <me...@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
>>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Joe Bohn <jo...@earthlink.net>.
Prasad Kashyap wrote:
> Comments inline
>
> Cheers
> Prasad
>
> On 1/5/07, David Jencks <da...@yahoo.com> wrote:
>
>> I like the pictures, but haven't had time to look at the implementations.
>
>
> Ditto
>
>>
>> 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?
>
>
> The only other place I can think of another dependency viewer is in
> the generated site documentation of a module at build time.
> Example:
> http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html
>
>
> Are you thinking of a different one in the server too ?
Actually, I think David is thinking of the dependencies that are listed
in the configuration views (such as WARs, EARs, etc...) where the
dependencies are listed to communicate the potential ramifications if a
configuration is removed.
>
>>
>> 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
>>
>>
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by Prasad Kashyap <go...@gmail.com>.
Comments inline
Cheers
Prasad
On 1/5/07, David Jencks <da...@yahoo.com> wrote:
> I like the pictures, but haven't had time to look at the implementations.
Ditto
>
> 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?
The only other place I can think of another dependency viewer is in
the generated site documentation of a module at build time.
Example: http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html
Are you thinking of a different one in the server too ?
>
> 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
>
>
Re: ClassLoader, JNDI and Dependency views in console
Posted by David Jencks <da...@yahoo.com>.
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 <me...@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
>