Hi Jim,
running a macro which gets dispatched as a macro via the OOo 2.4.1
Java bridge (the Java scripting framework of OOo) will be aborted, if
the Java support (Apache BSF, cf. <http://jakarta.apache.org/bsf>)
creates dynamically an event adapter. Running the same program via
URE succeeds!
The Apache BSF employs its own class loader (extending
java.lang.ClassLoader) for caching the dynamically created event
adapter classes (done in
org.apache.bsf.util.event.generator.AdapterClassLoader).
Unfortunately, when dispatched by OOo 2.4.1 as a macro invoking
ClassLoader.defineClass() causes an (uncatchable!) abend. (Running
the same code via URE works as expected.)
What causes this surprising behaviour, and even more important, how
can one come by it! (Support for dynamic languages is dependent on
being able to create Java classes on the fly from time to time.)
The likely cause is some code that is loaded by a parent classloader
trying to find the class in the generator's classloader.
The usual solution is to use the thread context classloader.
Yes. However, it *is* using the context thread loader (just double
checked).
If the same script is run from outside of OpenOffice, i.e. using the
plain Java class loaders, everything works fine and as expected!
So therefore I speculate, that this behaviour has to do with the OOo
custom class loader in effect ("sun.misc.Launcher$AppClassLoader"), when
running the script via OOo's scripting framework: the problem occurs
when a class object should be created from a byte array using super's
"/defineClass(String n|ame, byte[] b, int off, int len)|/ ".
The "name" of the class to be defined in this case is:
"org/apache/bsf/util/event/adapters/com_sun_star_awt_XActionAdapter".
---
*Strangely*, there is *no* catchable exception thrown (at the Java
side), the invocation just seems to stop without any further notice!
However, coming back to JNI-code an exception on the Java side is
noticed where the "getMessage()" returns the string
"com/sun/star/awt/XActionListener".
You should be very careful to do any changing of the
contextClassLoader in a try-finally block so that you don't expose the
OOo code that calls your to a strange classloader.
Right, looking over the code, so it should.
P.S.: Ad Beta 3.0, Dev300m21: currently I am not able to add the
scripting package (same package can be added to 2.4). Were there any
changes to the OOo scripting framework for OOo 3.0 which one needs to
take into account? If so, where would that be documented?
I've successfully run GroovyForOpenOffice and IFCX Wings on OOo 3.0
Beta m20 without changes from those needed for OOo 2.3 (which did
break extensions that access the Scripting Framework Java API).
Are you able to get your GroovyForOpenOffice scripts dispatched as
macros from OOo 2.4.x or 3.0 Beta m20? I.e. choosing
"Extras->Macros->Run" or the like?
If so, how do you dynamically define classes? Could you send me the
respective code or let me know where it could be downloaded from?
I recently posted to an old thread of yours on that issue:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00794.html
Yes, I saw that post and I agree.
The only significant problem I'm having with OOo 3.0 is on PPC OS X
where anything with Swing hangs the whole application.
Regards,
---rony
