Rony G. Flatscher wrote:
Hi there,
went out and found some infos on Sun's documentation, but still wouldn't
know a solution to the problem. Here's the use case:
* a C/++ program loads and uses a Java class that resides in an
extension jar (copied to .../jre/lib/ext); that Java class is used
to invoke Java classes anywhere on the system using
"Class.forName()" to locate and load the classes (using
"this.getClassLoader()"). In the process that Java class will use
JNI to invoke the ooRexx interpreter (a C++ program) which
executes a supplied Rexx script (using a DLL which is copied to
.../jre/lib/i386). Such Rexx programs are able to call back into
Java using JNI.
o So far it works.
o Now, if a Java class should be located from a
non-bootstrap/non extension directory (using
"Class.forName(string)" ) on behalf of the Rexx script, this
does not work. It seems that in this use case the used
classLoader seems to have no information about additional
Java classes pointed to by the CLASSPATH environment
variable or the appropriate "-Djava.class.path" startup option.
The JNI and Rexx stuff is irrelevant here. Its as simple as this:
AppClassLoader --knows--> UNO classes (via CLASSPATH)
| directly...
|
...and indirectly...
|
v
ExtClassLoader --knows--> your classes (via ext dir)
| directly...
|
...and indirectly...
|
v
BootstrapClassLoader --knows--> java.lang etc. (hardcoded)
directly
If your classes call Class.ForName("someUNOclass", true, ExtClassLoader)
(as they do when they simply call Class.ForName("someUNOclass")), that
wont work. If your classes want to use UNO, they need to be loaded by a
classloader that knows (directly or indirectly) the UNO classes. Hence,
if your classes shall be loaded by ExtClassLoader, the UNO classes would
need to be loaded by ExtClassLoader, too.
Any good book on Java should cover that classloader stuff in detail.
-Stephan
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
