Hi there,
Waiting a little bit more and giving maybe one more helpful information,
before filing an issue:
* loading classes dynamically works (e.g. using Class.forName(...));
assuming that Jim White's posting meant this kind of dynamic
loading of a Java class;
* *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".
[The dynamically created bytecode supplied to
defineClass(...) should be used for creating a class named
"org/apache/bsf/util/event/adapters/com_sun_star_awt_XActionAdapter"
(that implements all XActionListener event methods), which
package name maps into the existing BSF name space.]
Looking through the code in ScriptProviderForooRexx and
ScriptSourceModel there seems to be no reason, why a class loader mix-up
should be assumed (there is no setting of the Thread's context class
loader which could come into its way). Again, dynamically loading any
class works without problems in either scenario (and I am pretty sure
that the dynamic creation of adapter classes worked in pre 2.3 OOo!), on
the fly creation of a class from a dynamically created bytecode array
goes unexplicably out to lunch.
Before filing an issue (this situation is quite inhibiting, to say the
least, giving the importance of event handling), I would like to check
out whatever those in the know think that I should check out something
different.
As it stands now, I think that the method "defineClass(name, byte[],
start, len)" of the OOo custom class loader named
"sun.misc.Launcher$AppClassLoader" is the culprit. (Also, it seems
strange to me, that there is no Java-catchable exception thrown by it.)
Regards,
---rony
Rony G. Flatscher wrote:
Hi Jim,
If so, how do you dynamically define classes?
Are you using dynamic loading via a byte array of bytecodes? And if so
in Java 1.1. form?
Could you send me the respective code or let me know where it could
be downloaded from?
Thank you very much for those hints and pointers! (Though, will take
me a while to dig into and digest it.)
Regards,
---rony
