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.
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).
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.
I would stop supporting such broken Java 1.5 but as Apple didn't release
a decent Java 1.6 (meaning 32-bit Java), I cannot. I mean under OOo,
even if you have Java 1.6 on a Mac, you still get only JVM 1.5, as OOo
is 32-bit. My only hope is that SoyLatte (OpenJDK port to Mac) will
start supporting Aqua natively, and then we could dump the buggy Apple
product.
Regards
Marcin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
