AdapterClassLoader: does not attempt to use current Thread's context class
loader, if ...
-----------------------------------------------------------------------------------------
Key: BSF-21
URL: https://issues.apache.org/jira/browse/BSF-21
Project: BSF
Issue Type: Bug
Affects Versions: BSF-2.4
Reporter: Rony G. Flatscher
Assignee: Rony G. Flatscher
Fix For: BSF-2.4
When creating dynamically an event adapter in
org.apache.bsf.util.event.generator.EventAdapterGenerator, an instance of the
caching
org.apache.bsf.util.event.generator.AdapterClassLoader is created and saved in
a static variable.
If a listener class has been supplied to EventAdapterGenerator and the class
has been constructed dynamically, then AdapterClassLoader is used to
define/load the class.
Unfortunately, if OpenOffice.org is dispatching macros via BSF which need to
have BSF create a new event adapter, then this fails with OpenOffice.org,
starting with their version 2.3 (introduced fall 2007). The reason being that
the OpenOffice.org defining class loader does not load any OpenOffice classes!
Rather it becomes necessary with OpenOffice to set the current thread's context
class loader to one of OpenOffice which resolves the OpenOffice classes. For
BSF to be able to support this behaviour, it becomes necessary to try out the
current thread's context class loader as well, otherwise the OpenOffice event
type cannot be found when defining the dynamically class, causing an *error*
(not an exception) which will kill the thread by default.
A possible solution in the AdapterClassLoader for "defineClass" and
"getLoadedClass" is to also attempt to use the thread's context class loader.
This can be done by creating an inner class loader class for which instances a
parent class loader is set to the thread's class loader.
Have a local working version of this scheme, which I would apply after working
through the current issues (next week, as I will be able to plan one, two days
for tackling and resolving the reported BSF issues).
---rony
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
