Stephan Bergmann 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".
...
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.
Will have to look into it. However, there is another question
beforehand for which I would request an answer: for unknown reasons
this class not found exception cannot be caught from the Java side
(JRE 1.6.0_06). If it was, it became possible to react accordingly in
that class loader.
Is this an issue with the OOo class loader that should be reported in
order to get it fixed or is this working as designed (and if so, what
would be the reasoning for it)?
No idea why your code cannot catch the java.lang.NoClassDefFoundError
(note that it derives from java.lang.Error, not from
java.lang.Exception).
Thank you for stressing that "Error" part!
Although I realized that originally and looked up the documentation for
NoClassDefFoundError I constantly forgot/oversaw to change the catch
statement's filter to that specific Throwable. So that was the reason
for not being able to catch it.
(The information about stopping the thread in case of an error is
ex/implicitly given in the documentation for java.lang.Error, which
serves as the superclass for all error type throwable classes.)
If the JNI-UNO bridge is in between the throw and catch sides, note
that it will convert the Java NoClassDefFoundError into a UNO
RuntimeException (I think).
No, the JNI-UNO bridge was not involved at all.
As the BSFManager is imported and instantiated by the ooRexx supporting
OOo scripting framework
(com.sun.star.script.framework.provider.oorexx.{ScriptProviderForooRexx|ScriptSourceModel})
which is deployed by OOo, I expected that the customized defining class
loader ("sun.misc.Launcher$AppClassLoader") would have been set up
already to see the OOo UNO types.
At the moment I have an experimental version of the
BSF-AdapterClassLoader that in conjunction with the invoking scripting
framework code works. Will have to test and further analyze the impacts
more thoroughly (not wanting to break any existing BSF-deployments, as I
would intend to change the ASF BSF 2.3 accordingly, such that all BSF
2.3 scripting engines could be used as macro languages for OOo).
Thank you for your comments!
---rony
P.S.: There exists a version ASF BSF 3.0 (currently in beta), which is a
total rewrite from scratch matching Java's 6 "javax.script". However,
that package can be deployed on Java 1.3 and up. This means that in
principle it would be possible to add Java 6 style scripting to OOo, if
OOo was taking advantage of BSF 3.0, even if using earlier versions of
Java! If interested, we could talk about this on another thread.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
