jakarta-bsf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] Updated: (BSF-21) AdapterClassLoader: does not attempt to use current Thread's context class loader, if ...
Date Thu, 18 Mar 2010 23:56:27 GMT

     [ 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
> 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

View raw message