You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bsf-dev@jakarta.apache.org by "Rony G. Flatscher (JIRA)" <ji...@apache.org> on 2008/07/04 17:17:32 UTC
[jira] Created: (BSF-21) AdapterClassLoader: does not attempt to
use current Thread's context class loader, if ...
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: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org
[jira] Updated: (BSF-21) AdapterClassLoader: does not attempt to
use current Thread's context class loader, if ...
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BSF-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb updated BSF-21:
--------------------
Fix Version/s: (was: BSF-2.4)
> 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
>
> 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: bsf-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bsf-dev-help@jakarta.apache.org