SolvingClassLoaderProblems - Revision history

Tredmond: /* Debugging Class Loader Problems */

2009-08-24T00:42:14Z

‎Debugging Class Loader Problems

Tredmond: /* Debugging Class Loader Problems */

2009-08-24T00:41:46Z

‎Debugging Class Loader Problems

Tredmond: /* Swing Based Visualization of OSGi Class Loading */

2009-08-13T15:42:41Z

‎Swing Based Visualization of OSGi Class Loading

Tredmond: /* Swing Based Visualization of OSGi Class Loading */

2009-08-13T15:38:05Z

‎Swing Based Visualization of OSGi Class Loading

Tredmond: /* Swing Based Visualization of OSGi Class Loading */

2009-08-13T15:34:31Z

‎Swing Based Visualization of OSGi Class Loading

Tredmond: /* Swing Based Visualization of OSGi Class Loading */

2009-08-13T15:33:06Z

‎Swing Based Visualization of OSGi Class Loading

Tredmond at 15:21, August 13, 2009

2009-08-13T15:21:25Z

Tredmond at 01:30, December 15, 2007

2007-12-15T01:30:11Z

Tredmond at 15:42, December 14, 2007

2007-12-14T15:42:13Z

Tredmond at 19:29, December 10, 2007

2007-12-10T19:29:55Z

@@ Line 1: / Line 1: @@
 == Debugging Class Loader Problems ==
-Note - since the first writing of this document - we have added [SolvingClassLoaderProblems#Swing_Based_Visualization_of_OSGi_Class_Loading [a swing based  version]] of this tool.  While it does not generate all the information of the servlet based tool, it is easier to get working and it is more compelling and fun.  I also figure  that the graphical tool might be useful as an educational tool for discussing OSGi class loading.  I will add some discussion of the swing based tool after the servlet based discussion.
+Note - since the first writing of this document - we have added [[SolvingClassLoaderProblems#Swing_Based_Visualization_of_OSGi_Class_Loading|a swing based  version]] of this tool.  While it does not generate all the information of the servlet based tool, it is easier to get working and it is more compelling and fun.  I also figure  that the graphical tool might be useful as an educational tool for discussing OSGi class loading.  I will add some discussion of the swing based tool after the servlet based discussion.
 === Servlet Based Debug ===

@@ Line 1: / Line 1: @@
 == Debugging Class Loader Problems ==
-Note - since the first writing of this document - we have added a swing based portion of this tool.  While it does not generate all the information of the servlet based tool, it is easier to get working and it is more compelling and fun.  I also figure  that the graphical tool might be useful as an educational tool for discussing OSGi class loading.  I will add some discussion of the swing based tool after the servlet based discussion.
+Note - since the first writing of this document - we have added [SolvingClassLoaderProblems#Swing_Based_Visualization_of_OSGi_Class_Loading [a swing based  version]] of this tool.  While it does not generate all the information of the servlet based tool, it is easier to get working and it is more compelling and fun.  I also figure  that the graphical tool might be useful as an educational tool for discussing OSGi class loading.  I will add some discussion of the swing based tool after the servlet based discussion.
 === Servlet Based Debug ===

@@ Line 86: / Line 86: @@
 === Swing Based Visualization of OSGi Class Loading ===
-If you only want the swing visualization then the installation of this bundle is even easier than described above.  The only thing that needs to be added is the org.protege.osgi.debug bundle itself.
+If you only want the swing visualization then the installation of this bundle is even easier than described above.  The only thing that needs to be added is the org.protege.osgi.debug bundle itself.  This tool is made possible by the [http://jung.sourceforge.net/ Jung Group] who have made it extremely easy to display graphs in swing.
 Here is a recently generated visualization generated on a freshly built copy of protege4.

← Older revision		Revision as of 15:38, August 13, 2009
Line 100:		Line 100:
	[[File:ClassLoadingDebug02.png]]		[[File:ClassLoadingDebug02.png]]

−	The class being displayed is org.example.conflict.Util. There are two incompatible versions of this class and the PluginBundle is choosing which class to use based on its version. This example is discussed in more detail [[Embedding_OSGi\|here]].	+	The class being displayed is org.example.conflict.Util. There are two incompatible versions of this class and the PluginBundle is choosing which class to use based on its version. This example is discussed in more detail [[Embedding_OSGi\|here]]. Note that the system bundle is providing a class which was not obtained through boot delegation. This example was intended to show how OSGi will be embedded in a larger host application. In this case, it will be typical for classes from the host application to be made visible in this way.

@@ Line 92: / Line 92: @@
 [[File:ClassLoadingDebug01.png]]
-Don't be dismayed if on your OSGi society the initial graph looks too complex.  When you restrict attention to a class or package the presentation will significantly simplify.
+Don't be dismayed if the initial graph looks too complex when it first comes up on your OSGi society.  When you restrict attention to a class or package the presentation will significantly simplify.
 The vertices of the graph denote OSGi bundles.  This visualization is showing which bundles can load the EditorKit class.  The red vertices represent bundles that cannot load the class.  The blue vertex is the bundle that provides the class for the OSGi environment.  Often, but not always, having two blue vertices for an important class represents a problem because it means that there are two incompatible versions of the same class.  The green vertices indicate bundles that can load the class but have not provided the class themselves.  The highlighted edges represent ''wires'' which are connections allowing the provider of a class to provide the class definition to the consumer of the class.  When a vertex is green but there is no wire leading to it, it means that the bundle is loading the class through boot delegation.

← Older revision		Revision as of 15:33, August 13, 2009
Line 94:		Line 94:
	Don't be dismayed if on your OSGi society the initial graph looks too complex. When you restrict attention to a class or package the presentation will significantly simplify.		Don't be dismayed if on your OSGi society the initial graph looks too complex. When you restrict attention to a class or package the presentation will significantly simplify.

−	The vertices of the graph denote OSGi bundles. This visualization is showing which bundles can load the EditorKit class. The red vertices represent bundles that cannot load the class. The blue vertex is the bundle that provides the class for the OSGi environment. Often, but not always, having two blue vertices for an important class represents a problem because it means that there are two incompatible versions of the same class. The green vertices indicate bundles that can load the class but have not provided the class themselves. The highlighted edges represent ''wires'' which are connections allowing the provider of a class to provide the class definition to the consumer of the class.	+	The vertices of the graph denote OSGi bundles. This visualization is showing which bundles can load the EditorKit class. The red vertices represent bundles that cannot load the class. The blue vertex is the bundle that provides the class for the OSGi environment. Often, but not always, having two blue vertices for an important class represents a problem because it means that there are two incompatible versions of the same class. The green vertices indicate bundles that can load the class but have not provided the class themselves. The highlighted edges represent ''wires'' which are connections allowing the provider of a class to provide the class definition to the consumer of the class. When a vertex is green but there is no wire leading to it, it means that the bundle is loading the class through boot delegation.
		+
		+	Here is another example where I added the debug bundle to an OSGi society that I used to demonstrate how OSGi can resolve jar library conflicts.
		+
		+	[[File:ClassLoadingDebug02.png]]
		+
		+	The class being displayed is org.example.conflict.Util. There are two incompatible versions of this class and the PluginBundle is choosing which class to use based on its version. This example is discussed in more detail [[Embedding_OSGi\|here]].

@@ Line 1: / Line 1: @@
 I will describe how to debug class loader exceptions (if they cannot be easily figured out and they are giving you a headache).  Before starting, an important tip is the fact that class loader problems are often masked.  I usually have a good suspicion when this is the problem but it doesn't help that we don't know.  If you are not seeing a ClassNotFoundException or some like, put a breakpoint for ClassNotFoundException (which is what the class loader throws) and see what it turns up.  For example, consider the apple.* line in the bootdelegation configuration.  This line was inserted to fix a situation where the tree view did not come up properly.  The two exceptions that showed up were:
 <pre>
@@ Line 77: / Line 83: @@
 </center>
 then so should the org.semanticweb.owlapi  bundle.

@@ Line 1: / Line 1: @@
-I will describe how to debug class loader exceptions (if they cannot be easily figured out and they are giving you a headache).  Before starting, an important tip is the fact that class loader problems are often masked.  I usually have a good suspicion when this is the problem but it doesn't help that we don't know.  If you are not seeing a ClassNotFoundException or some like, put a breakpoint for ClassNotFoundException (which is what the class loader throws) and see what it turns up.  Ok now for my example.
+I will describe how to debug class loader exceptions (if they cannot be easily figured out and they are giving you a headache).  Before starting, an important tip is the fact that class loader problems are often masked.  I usually have a good suspicion when this is the problem but it doesn't help that we don't know.  If you are not seeing a ClassNotFoundException or some like, put a breakpoint for ClassNotFoundException (which is what the class loader throws) and see what it turns up.  For example, consider the apple.* line in the bootdelegation configuration.  This line was inserted to fix a situation where the tree view did not come up properly.  The two exceptions that showed up were:
 So I recently saw the following exception:
@@ Line 19: / Line 29: @@
 In this case the exception was caused by a trivial stupid typo in the org.protege.common manifest but I was confused at the time and did not figure this out.  So the first item of confusion here might be the question of which class loader is causing the problem.  One might somehow think that this is being caused by the class loader for the org.protege.editor.owl bundle because, in some vague and undefined sense, this sequence of events seemed to be triggered in that bundle.  But this is not how class loaders work.   Actually the class loader that got into trouble (before delegation is taken into account) is the class loader for the org.coode.xml.XMLWriterImp class.  This class loader is the org.semanticweb.owlapi bundle.
-This should have been enough for me to figure out what happened because (at this time) the org.semanticweb.owlapi bundle imported the package org.apache.commons.lang and the org.protege.common bundle exportedthe package org.apache.commons.lang package.  There were very few things that could go wrong at this point but I didn't see it and I began to doubt my reasoning.
+This should have been enough for me to figure out what happened because (at this time) the org.semanticweb.owlapi bundle imported the package org.apache.commons.lang and the org.protege.common bundle exported the package org.apache.commons.lang package.  There were very few things that could go wrong at this point but I didn't see it and I began to doubt my reasoning.
 To solve these types of problems I have created a bundle providing some servlets that debug class loading issues.  The source for this bundle can be

← Older revision		Revision as of 15:42, December 14, 2007
Line 1:		Line 1:
−	I will describe how to debug class loader exceptions (if they cannot be easily figured out and they are giving you a headache). So I recently saw the following exception:	+	I will describe how to debug class loader exceptions (if they cannot be easily figured out and they are giving you a headache). Before starting, an important tip is the fact that class loader problems are often masked. I usually have a good suspicion when this is the problem but it doesn't help that we don't know. If you are not seeing a ClassNotFoundException or some like, put a breakpoint for ClassNotFoundException (which is what the class loader throws) and see what it turns up. Ok now for my example.
		+
		+
		+	So I recently saw the following exception:

	<pre>		<pre>

← Older revision		Revision as of 19:29, December 10, 2007
Line 1:		Line 1:
−	In order to apply the techniques of this section the developer will need to have the ability to capture and navigate the output of a run command and must be able to compile a knopflerfish distribution (''ant knopflerfish''). Given this I will describe how to debug class loader exceptions (if they cannot be easily figured out and they are giving you a headache). So I recently saw the following exception:	+	I will describe how to debug class loader exceptions (if they cannot be easily figured out and they are giving you a headache). So I recently saw the following exception:

	<pre>		<pre>