Stephan Bergmann pisze:
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.]
Well, as many XML libraries (DOM parsers, JAXB etc.) use it to load the
classes, there should be an example how to do use it. The bad thing is
that due to the way object-oriented libraries work, you might even be
completely unaware that somewhere down there, there is a buried call to
JAXB. For this reason it's hard to say where exactly you need to set the
context classloader...
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.
OK, you're right, you simply need to load resources in a non-recommended
way (without using getResource()) to avoid any problems. As long as
there is more documentation (preferably on the wiki) about Java
classpath and classloaders in extensions, I think we could live with the
change quite happily :)
So we need a small snippet of the code on the wiki.
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.
Yes, this didn't work if old != null on Mac OS X Leopard JVM 1.5. I
don't own any Mac so I couldn't test it in detail, and buying an
outdated machine just to test why its software doesn't work seems a bit
crazy to me.
Regards
Marcin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
