(this issue might be related to issue 80100 and mail thread
http://www.mail-archive.com/dev@api.openoffice.org/msg07637.html)

Highlights
--------------------------------

- Observation: OpenOffice.org uses parent class loader
(sun.misc.Launcher$AppClassLoader) as current thread's context class loader.
- Problem 1: This breaks the definition of context class loader:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#getContextClassLoader()
- Problem 2: It also breaks compatibility with major Java libraries such as
Springframework, TrueZip and JGoodies
- Solution: OpenOffice.org should assign extension class loader
(com.sun.star.lib.unoloader.UnoClassLoader) as current thread's context class
loader.

A more detailed description of the problem follows.

Summary
--------------------------------

To make sure everybody (including myself) is clear on the issue here is a little
history. OpenOffice.org 2.4 introduced a new class loader architecture. In the
new architecture each extension gets its own class loader and all extensions
share a parent class loader.

The shared parent class loader (sun.misc.Launcher$AppClassLoader) provides
access to standard JRE classes, standard OpenOffice.org libraries (UNO) and the
libraries specified in the class path of the active JRE (Tools => Options... =>
OpenOffice.org => Java => Class Path...).

The extension-local class loader (com.sun.star.lib.unoloader.UnoClassLoader)
provides access to extension classes and libraries bundled with the extension.

All this makes sense, as the new architecture helps avoid collisions among
different versions of the same libraries bundled by different extensions, and
provides a means to hot deploy/undeploy extensions. Tomcat and other application
servers, for example, use this approach, only for them an extension is a J2EE
application.

The problem
--------------------------------

At certain point in time an extension might want to load a class path resource
(icons, Swing look'n'feel, property file, etc). Usually that resource is bundled
with the extension and therefore must be loaded by the extension-local class loader.

The extension starts by acquiring an instance of a class loader. There are
several ways to get a class loader, but two of them stand out:

1. someClass.getClassLoader() - this class loader is the one that loaded the
class object someClass. If someClass belongs to the extension and the resource
is in the same bundle (usually even the same JAR) as someClass, then the class
loader acquired through this method will succeed in finding that resource.

2. Thread.currentThread().getContextClassLoader() - this class loader "is
provided by the creator of the thread for use by code running in this thread
when loading classes and resources", see
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#getContextClassLoader().
According to this definition, this method should also succeed in loading the
resources. But! Read on...

The issue
--------------------------------

Let's take a look at threads running in Java-based extensions. Every extension
has one or more entry points that are called by OpenOffice.org through UNO API.
These could be methods of XAsyncJob, XModifyListener, etc. Let's call them
callbacks. Because it is OpenOffice.org that calls into callbacks it is
OpenOffice.org process that creates the threads. Thus, OpenOffice.org is "the
creator" in the description above.

Now, as it turns out the context class loader set by OpenOffice.org is the
parent class loader (sun.misc.Launcher$AppClassLoader). Consequently, any
attempt to load an extension-specific resource using that class loader fail.

At first sight the solution is simple. Let's all use the first method and avoid
the second one. Well, turns out it's not simple at all. Many popular Java
libraries, such as Springframework, TrueZip and JGoodies use the second method
to load their resources. So we cannot bundle them with the extension. We have to
put them in the parent classpath to make sure they get loaded by the parent
class loader. But that defeats the whole purpose of the OXT extensions. The idea
was that one should be able to bundle their UNO code and dependent libraries
into a single OXT file and install it in OOo.

But wait there is another solution. Why don't we set our own context class
loader in every callback method. This actually works. However, the problematic
point here is "every callback method". How many callbacks can an extension have?
Does a developer have to remember to reload the context class loader in every
listener, every async job? This is not a clean solution. In fact it's plain
ugly. Right now for me, this is a temporary workaround.

Proposed fix
--------------------------------

I think that OpenOffice.org should set the extension-specific class loader
(UnoClassLoader) in all threads that call into the extension code. This is what
Tomcat (and I'm sure GlassFish, JBoss, Jetty) does (only they call it
WebAppClassLoader), and this is what makes Springframework and others work well
in those environments.

Thanks,

Yegor