On 08/12/08 01:35, Rony G. Flatscher wrote:
Hi there,
starting with OOo 2.4 the OOo Java ClassLoader strategies got changed.
What are the current rules for OOo 2.4 and OOo 3.x ClassLoaders?
(Maybe together with a simple explanation of the problems that have been
intended to be solved by those changes. But also, why would the
CLASSPATH setting not be honored by OOo, whereas the PATH setting -
thankfully! - is honored?)
Knowing them would really alleviate a lot of developing problems, where
one loses really tons of time/resources to a) figure out that a class
loader problem may be in effect and b) trying to find possible solutions.
The rules are really simple (also see
<http://blogs.sun.com/GullFOSS/entry/is_your_java_extension_ready>):
- The root application class loader of the VM knows virtually no jars.
- The Java UNO environment uses one underlying class loader (child of
the root application class loader, loading the Java UNO runtime classes
and the classes that represent UNO types---also see the discussion of
the UNO-Type-Path manifest entry in the Developer Guide), and a
dedicated class loader (child of the one underlying class loader) per
Java UNO component (i.e., jar).
- Native code that starts Java code needs to create appropriate class
loaders manually.
- A jar that depends on additional classes needs to make sure they are
found (e.g., with a Class-Path manifest entry).
- Java code that instantiates classes from names needs to make sure it
does so relative to an appropriate class loader (e.g., by setting a
context class loader).
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
