Rony G. Flatscher 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".
...
That sounds to me very much like the situation I encountered with the
classpath change for OOo 2.3. If you're using any classes in
com.sun.star.script.framework.* then that is the problem. Classes in
com.sun.star.script.provider.* are OK. That is why you see
org.ifcx.oo.scripting.framework.* classes in G4OO which are simply
copied & refactored from OOo.
http://ifcx.svn.sourceforge.net/viewvc/ifcx/GroovyForOpenOffice/trunk/src/org/ifcx/oo/scripting/framework/
Something I just learned that I do regard as a bug (or at least
critically needed enhancement) is that although the OOo 2.3 classpath
change did move the OOo implementation classes out of the extensions'
classpath, all extensions are in the same classpath (same URLClassLoader
actually). That is even worse that having OOo classes visible since it
is totally unpredicatable and uncontrollable what extensions users might
install. But as I say, that is probably unrelated to your issue.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
