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".
That sounds to me very much like the situation I encountered with the
classpath change for OOo 2.3.
Probably, as I recall that that had worked on earlier versions of OOo!
[Also I think that a set CLASSPATH environment variable must be honored
by the OOo customized class loader (as do any of the customized class
loaders I know of). Cf.
<http://qa.openoffice.org/issues/show_bug.cgi?id=81973> for an issue
which might need more discussion in order to get it moving ahead.]
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.
Hmm, why would that be?
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/
Hmm, that is definiteley something to try out (it's too late now for me,
but will look into it tomorrow evening), but thanks a *lot* for these
hints, Jim!
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.
Hmm, very interesting too, but you are right, it probably has nothing to
do with my issue.
Regards,
---rony
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
