Rony G. Flatscher wrote:
Stephan Bergmann wrote:
Rony G. Flatscher wrote:
Stephan Bergmann wrote:
Rony G. Flatscher wrote:
Hi Jim,
...
* *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.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
