Stephan Bergmann wrote:
Rony G. Flatscher wrote:
Stephan Bergmann wrote:
Rony G. Flatscher wrote:
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".
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.)
BSF supplies generic support and has been used for almost ten years in
all sort of deployments including IBM's WebSphere for which originally
BSF got created as an opensource project to allow scripting languages to
be deployed in JSPs. Knowing Java based application servers/J2EE
deployment patterns, you will be probably able to acknowledge that all
kind of complex class loader patterns are in place. BSF has been handed
over to the Apache Software Foundation and has been deployed in quite a
few Java based Apache projects (from ant to Xerces), deploying BSF in
even more challenging environments.
Now, everything has been working fine with this infrastructure, but now
there is one situation, where it seems that the current OOo custom class
loader schemes step in and cause a problem. (AFAICT, it worked up to OOo
2.3.)
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.
Regards,
---rony
P.S.: Of course, I also would like that the OOo class loader schemes
keep the flexibility of Java runtime environments by honoring the
environment variable CLASSPATH, if set.
P.P.S.: Will only be able to get back in the late afternoon due to a
tough schedule of meetings.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
