On 06/04/09 12:19, Marcin Miłkowski wrote:
Stephan Bergmann pisze:
On 06/03/09 19:58, Marcin Miłkowski wrote:
Oliver Brinzing pisze:
Hi Marcin,
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
yes this seems to help, classloader was indeed null ...
may i add your solution to issue
http://www.openoffice.org/issues/show_bug.cgi?id=102164 ?
Go ahead, but I wouldn't call this a solution, this is almost a hack.
Setting the context class loader to an appropriate value around code
that uses it is not a hack but rather mandatory coding work. (The
context class loader concept itself is the hack, in my not so humble
opinion.) See
<http://www.openoffice.org/issues/show_bug.cgi?id=102164#desc7> for
what I think happens here.
Well, you cannot always get the proper value thanks to Apple and other
vendors... :(
Anyway, there are many places in Java where developers don't suspect the
context classloader in action (mostly XML-related), so I think this can
break a lot of code, as this is really poorly documented both in JDK and
in OOo API docs (meaning no mention at all). The blog post on gulfoss
also mentions only setting paths in the manifest but this is not enough
to make the extension work. Moreover, you don't know if you should set
the classloader unconditionally (it doesn't work on Mac OSX), or
conditionally, and if the previous classloader should be stored; if the
classloader should be synchronized... etc. No examples, no
documentation, so I'd expect many extensions to stop working.
Yes, as I said, the Java context class loader appears to be a bad hack,
and a poorly documented one. [In short, my understanding is that (a)
the context class loader should always be reset (in an exception-safe
way) to its previous value immediately after making an "external" call
to code that (indirectly) needs it, and (b) thread-synchronization is a
non-issue, as the context class loader is per-thread.]
Just out of curiosity - what performance gains do you expect to have by
not setting the context classloader? I mean if the Java code will set
the context classloader anyway, what is there to gain? (Well, of course,
you could have Java code that doesn't rely on any files, resources, XML
files, but this would be a mere toy).
I do not have numbers, maybe Ocke (on cc) has---he requested the change.
Also, I am not aware that "rely[ing] on any files, resources" triggers
the requirement to set a context class loader, so my understandig is
that there *is* non-trivial Java code that does not need a context class
loader.
One more thing: first check if the classloader is null, because if it
isn't, you will get into trouble (as we did).
Out of curiosity, what kind of trouble did you get into (assuming you
re-set the context class loader to its originally value after calling
the code that used it)?
In such a case the you cannot find any JAXB-related bind classes in Java
1.5 under Mac OS X (Leopard). Don't ask me why, probably the code in
Apple JVM 1.5 is broken somewhere, as it is in many places.
You mean, you have an object O with method M taking N parameters, and
calling O.M(A1,...,AN) requires the context class loader to be set to
class loader C, and
o = /* compute O */;
a1 = /* compute A1 */;
...
aN = /* compute AN */;
ClassLoader c = /* compute C */;
ClassLoader old = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(c);
o.M(a1, ..., aN);
} finally {
Thread.currentThread().setContextClassLoader(old);
}
fails to work? That would indeed appear to be a bug in O.M (or one of
the methods indirectly called) or the JVM itself.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
