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 (JIRA)" <ji...@apache.org> on 2007/01/04 14:01:28 UTC
[jira] Created: (GERONIMO-2690) New view for all the classloaders
and classes loaded in it
New view for all the classloaders and classes loaded in it
----------------------------------------------------------
Key: GERONIMO-2690
URL: https://issues.apache.org/jira/browse/GERONIMO-2690
Project: Geronimo
Issue Type: Improvement
Security Level: public (Regular issues)
Components: console
Affects Versions: 2.0
Environment: Any
Reporter: Rakesh Midha
Assigned To: Rakesh Midha
Fix For: 2.0
Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2690) New view for all the classloaders
and classes loaded in it
Posted by "Kevan Miller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevan Miller closed GERONIMO-2690.
----------------------------------
Resolution: Fixed
Fix Version/s: (was: 2.0)
2.0-M2
classloaderViewLinks.patch applied. Thanks Rakesh!
Safari is still not able to see these views, but Firefox works well. I'll raise a separate jira.
> New view for all the classloaders and classes loaded in it
> ----------------------------------------------------------
>
> Key: GERONIMO-2690
> URL: https://issues.apache.org/jira/browse/GERONIMO-2690
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
> Affects Versions: 2.0
> Environment: Any
> Reporter: Rakesh Midha
> Assigned To: Kevan Miller
> Fix For: 2.0-M2
>
> Attachments: classloader.gif, classloaderView2690.patch, classloaderViewLinks.patch, common.patch
>
>
> Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
> So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
> I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2690) New view for all the classloaders
and classes loaded in it
Posted by "Rakesh Midha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rakesh Midha updated GERONIMO-2690:
-----------------------------------
Attachment: classloaderViewLinks.patch
> New view for all the classloaders and classes loaded in it
> ----------------------------------------------------------
>
> Key: GERONIMO-2690
> URL: https://issues.apache.org/jira/browse/GERONIMO-2690
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
> Affects Versions: 2.0
> Environment: Any
> Reporter: Rakesh Midha
> Assigned To: Kevan Miller
> Fix For: 2.0
>
> Attachments: classloader.gif, classloaderView2690.patch, classloaderViewLinks.patch, common.patch
>
>
> Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
> So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
> I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2690) New view for all the classloaders
and classes loaded in it
Posted by "Paul McMahan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466575 ]
Paul McMahan commented on GERONIMO-2690:
----------------------------------------
I'm seeing this error when trying to open the classloader viewer that's currently in trunk:
16:33:55,858 ERROR [PortletFragment] Error in Portlet
javax.portlet.PortletException
at org.apache.pluto.core.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:76)
at org.apache.geronimo.console.classloaderview.ClassLoaderViewPortlet.doView(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(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73)
at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119)
at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70)
at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168)
at jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_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(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
at jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.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(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.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(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.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(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.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(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.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(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:329)
at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
at java.lang.Thread.run(Thread.java:613)
Caused by: java.lang.OutOfMemoryError: Java heap space
Nested Exception is
java.lang.OutOfMemoryError: Java heap space
> New view for all the classloaders and classes loaded in it
> ----------------------------------------------------------
>
> Key: GERONIMO-2690
> URL: https://issues.apache.org/jira/browse/GERONIMO-2690
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
> Affects Versions: 2.0
> Environment: Any
> Reporter: Rakesh Midha
> Assigned To: Kevan Miller
> Fix For: 2.0
>
> Attachments: classloader.gif, classloaderView2690.patch, classloaderViewLinks.patch, common.patch
>
>
> Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
> So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
> I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2690) New view for all the classloaders
and classes loaded in it
Posted by "Rakesh Midha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465368 ]
Rakesh Midha commented on GERONIMO-2690:
----------------------------------------
Attached classloaderViewLinks.patch, this patch fixes the OutOfMemory problem with Classloader viewer.
This patch using linking of Dojo Treenodes for classloaders which occurs multiple times in the tree. From the user prespective this will not make any difference but interally the whole StringTree size is reduce.
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 of app 90%, and it is visible is tree loading, now it is much quicker.
Please review and commit.
Thanks
Rakesh
> New view for all the classloaders and classes loaded in it
> ----------------------------------------------------------
>
> Key: GERONIMO-2690
> URL: https://issues.apache.org/jira/browse/GERONIMO-2690
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
> Affects Versions: 2.0
> Environment: Any
> Reporter: Rakesh Midha
> Assigned To: Kevan Miller
> Fix For: 2.0
>
> Attachments: classloader.gif, classloaderView2690.patch, classloaderViewLinks.patch, common.patch
>
>
> Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
> So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
> I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2690) New view for all the classloaders
and classes loaded in it
Posted by "Rakesh Midha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rakesh Midha updated GERONIMO-2690:
-----------------------------------
Description:
Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
was:
Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
Patch Info: [Patch Available]
> New view for all the classloaders and classes loaded in it
> ----------------------------------------------------------
>
> Key: GERONIMO-2690
> URL: https://issues.apache.org/jira/browse/GERONIMO-2690
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
> Affects Versions: 2.0
> Environment: Any
> Reporter: Rakesh Midha
> Assigned To: Rakesh Midha
> Fix For: 2.0
>
> Attachments: classloader.gif, classloaderView2690.patch, common.patch
>
>
> Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
> So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
> I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2690) New view for all the classloaders
and classes loaded in it
Posted by "Rakesh Midha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rakesh Midha updated GERONIMO-2690:
-----------------------------------
Attachment: classloaderViewLinks.patch
> New view for all the classloaders and classes loaded in it
> ----------------------------------------------------------
>
> Key: GERONIMO-2690
> URL: https://issues.apache.org/jira/browse/GERONIMO-2690
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
> Affects Versions: 2.0
> Environment: Any
> Reporter: Rakesh Midha
> Assigned To: Kevan Miller
> Fix For: 2.0
>
> Attachments: classloader.gif, classloaderView2690.patch, classloaderViewLinks.patch, common.patch
>
>
> Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
> So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
> I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2690) New view for all the classloaders
and classes loaded in it
Posted by "Rakesh Midha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rakesh Midha updated GERONIMO-2690:
-----------------------------------
Attachment: classloader.gif
classloaderView2690.patch
common.patch
> New view for all the classloaders and classes loaded in it
> ----------------------------------------------------------
>
> Key: GERONIMO-2690
> URL: https://issues.apache.org/jira/browse/GERONIMO-2690
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
> Affects Versions: 2.0
> Environment: Any
> Reporter: Rakesh Midha
> Assigned To: Rakesh Midha
> Fix For: 2.0
>
> Attachments: classloader.gif, classloaderView2690.patch, common.patch
>
>
> Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
> So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
> I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2690) New view for all the classloaders
and classes loaded in it
Posted by "Rakesh Midha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rakesh Midha updated GERONIMO-2690:
-----------------------------------
Attachment: (was: classloaderViewLinks.patch)
> New view for all the classloaders and classes loaded in it
> ----------------------------------------------------------
>
> Key: GERONIMO-2690
> URL: https://issues.apache.org/jira/browse/GERONIMO-2690
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
> Affects Versions: 2.0
> Environment: Any
> Reporter: Rakesh Midha
> Assigned To: Kevan Miller
> Fix For: 2.0
>
> Attachments: classloader.gif, classloaderView2690.patch, classloaderViewLinks.patch, common.patch
>
>
> Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
> So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
> I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2690) New view for all the classloaders
and classes loaded in it
Posted by "Kevan Miller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevan Miller reassigned GERONIMO-2690:
--------------------------------------
Assignee: Kevan Miller (was: Rakesh Midha)
> New view for all the classloaders and classes loaded in it
> ----------------------------------------------------------
>
> Key: GERONIMO-2690
> URL: https://issues.apache.org/jira/browse/GERONIMO-2690
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
> Affects Versions: 2.0
> Environment: Any
> Reporter: Rakesh Midha
> Assigned To: Kevan Miller
> Fix For: 2.0
>
> Attachments: classloader.gif, classloaderView2690.patch, common.patch
>
>
> Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
> So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
> I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2690) New view for all the classloaders
and classes loaded in it
Posted by "Rakesh Midha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462425 ]
Rakesh Midha commented on GERONIMO-2690:
----------------------------------------
Attached is the common.patch and classloaderview2690.patch which implements classloaderViewer console view.
The classloader.gif file shows how this view will look.
This view shows all the classloaders and its classes/interfaces in hierarchical fashion in which they are loaded. To facilitate locating of class of interest the tree view can be searched.
Tha approach used to keep track of all the class loaders and its parent/childrens is by keeping a registry of classloaders. This is done by uusing ClassloaderRegistry class which keeps WeakReference of all the loaded class loaders. As we are using WeakReferences this registry does not hinder Garbage colection if the classloader is destroyed somewhere else.
All the class loaders in Geronimo ie. ConfigurationClassLoader and MultiParentClassLoader are responsible for registering and unregistring of classloaders in registry. (if we forget to unregister, weak reference as well as destroy method takes care of GC).
The classloader tree grows like anything, so we are using dojo tree nodes lazly loaded. To load dojo tree nodes lazily, the StringTree instances are converted to JSON string, and setChildren is called to lazy loading of childrens on expension.
To use the patches first apply common.patch which adds StringTree.java and TreeDocIcon.css
and than apply classloaderView2690.patch. The common patch is also used in JIRA 2689 and 2691.
Few points which are worth noticing here :
1. The tree grows like anything and may take some time to intial loading ( for me it is taking 15 secs for full geronimo server for tomcat).
2. Classloader registry is introduced which some people may not like.
3. Please notice addClasses method in ClassLoaderViewPortlet.java, it does something which seem like illigal. It gets names of classes and interfaces from private Vector of Classloader class. This is the only way in which all the classes and interfaces names are available. I have tried this on Sun and IBM JDK and it works fine on it. Sometime later if these JDK's changes the name or type of variable "classes" in Classloader.java class this functaionality may not work.
Thanks
> New view for all the classloaders and classes loaded in it
> ----------------------------------------------------------
>
> Key: GERONIMO-2690
> URL: https://issues.apache.org/jira/browse/GERONIMO-2690
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
> Affects Versions: 2.0
> Environment: Any
> Reporter: Rakesh Midha
> Assigned To: Rakesh Midha
> Fix For: 2.0
>
> Attachments: classloader.gif, classloaderView2690.patch, common.patch
>
>
> Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
> So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
> I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2690) New view for all the classloaders
and classes loaded in it
Posted by "Kevan Miller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466599 ]
Kevan Miller commented on GERONIMO-2690:
----------------------------------------
This problem was noted in the discussion regarding this patch.
Rakesh has posted a patch which reduces the amount of memory required by this viewer. I'll look at applying the patch prior to the m2 branch. In the meantime, you can bump your servers heap, if you want to work-around...
> New view for all the classloaders and classes loaded in it
> ----------------------------------------------------------
>
> Key: GERONIMO-2690
> URL: https://issues.apache.org/jira/browse/GERONIMO-2690
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
> Affects Versions: 2.0
> Environment: Any
> Reporter: Rakesh Midha
> Assigned To: Kevan Miller
> Fix For: 2.0
>
> Attachments: classloader.gif, classloaderView2690.patch, classloaderViewLinks.patch, common.patch
>
>
> Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
> So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
> I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2690) New view for all the classloaders
and classes loaded in it
Posted by "Rakesh Midha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMO-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465370 ]
Rakesh Midha commented on GERONIMO-2690:
----------------------------------------
Oh I missed to give some important points for the patch.
Please note:
1. The links are marked by "link::', so any class or classloader starting with "link::" may not work properly, but I don't think we will have any classloader, class or interface name starting with 'link::'
2. For dojo tree link loading 'afterExpand' event is used, ideally 'beforeExpand' should be used, but 'beforeExpand' event is never published in current dojo version.
3. All the methods in ClassLoaderRegistry are synchronized for thread avoiding concurent modification.
Thanks
Rakesh
> New view for all the classloaders and classes loaded in it
> ----------------------------------------------------------
>
> Key: GERONIMO-2690
> URL: https://issues.apache.org/jira/browse/GERONIMO-2690
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: console
> Affects Versions: 2.0
> Environment: Any
> Reporter: Rakesh Midha
> Assigned To: Kevan Miller
> Fix For: 2.0
>
> Attachments: classloader.gif, classloaderView2690.patch, classloaderViewLinks.patch, common.patch
>
>
> Looking into the classloader problems and knowing which classsloader loaded which class has always been a big problem in app servers.
> So many times we hit ClassNotFoundException and wonder why is it happening when the classes are available in my module. It may be because those classes are loaded by some other classloader.
> I think it would be nice if we can add a view in console which shows are the classloaders and the classes they loaded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira