Rony G. Flatscher wrote:
Stephan Bergmann wrote:
...
* *creating a class on the fly* by creating the necessary
byte codes
saved in a byte array with the ClassLoader's
/|defineClass(String
name, byte[] b, int off, int len)| /
o works, if using URE to access OOo (i.e. script
invoked from
outside OOo),
o goes out to lunch (no Java catchable exceptions!),
if the
same script is dispatched via OOo, i.e. the OOo
ScriptingFramework.
The only information that can be gathered from the
JNI/C++
code is a Throwable message (/|getMessage()|/) of
"com/sun/star/awt/XActionListener". This information
seems
to come from the defineClass(...) invocation of the OOo
class loader named "sun.misc.Launcher$AppClassLoader".
...
Changed the JNI code to get the exception type and it is:
"java.lang.NoClassDefFoundError: com/sun/star/awt/XActionListener".
Not sure how your code looks like exactly; how do you obtain the
class loader at which you call defineClass?
O.K.: the BSF framework will be used to create an event adapter
dynamically. Evenutally this uses
org.apache.bsf.util.event.generator.EventAdapterGenerator
(generates the byte code according to the supplied argument
"listener type" class object in a static method
makeEventAdapterClass()) in which the class loader gets created:
public static AdapterClassLoader ldr = new AdapterClassLoader();
(The org.apache.bsf.util.event.generator.AdapterClassLoader
extends ClassLoader.)
If that AdapterClassLoader has no connection to the
com.sun.star.lib.unoloader.UnoClassLoader, how is it supposed to be
able to resolve Java classes that represent UNO types? (As you
noted, it sometimes can work, a little, by accident, if for example
the application class loader loads jurt.jar and ridl.jar; but even
then it will fail for additional UNO types, that are for example
brought in by OOo extensions.)
[...]
My interest is to find a solution, which allows BSF to remain generic
(and not making parts of it dependent on OOo custom class loader
schemes), but being also able to be usable if deployed from OOo.
So, if you have an idea on how one can reliably (and stably for the
future) come over this situation, I would appreciate it and implement
it in BSF, hopefully solving this issue once and forever.
From what you write, it looks to me that what is needed is to allow
clients of BSF to control which class loader is used as the parent
class loader of AdapterClassLoader instances.
Will have to look into it. However, there is another question beforehand
for which I would request an answer: for unknown reasons this class not
found exception cannot be caught from the Java side (JRE 1.6.0_06). If
it was, it became possible to react accordingly in that class loader.
Is this an issue with the OOo class loader that should be reported in
order to get it fixed or is this working as designed (and if so, what
would be the reasoning for it)?
No idea why your code cannot catch the java.lang.NoClassDefFoundError
(note that it derives from java.lang.Error, not from
java.lang.Exception). If the JNI-UNO bridge is in between the throw and
catch sides, note that it will convert the Java NoClassDefFoundError
into a UNO RuntimeException (I think).
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
