[
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
