[
https://issues.apache.org/jira/browse/OWB-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934663#action_12934663
]
David Jencks commented on OWB-496:
----------------------------------
I don't understand your thinking. If you are in an environment where the
thread context classloader is appropriate for creating proxies, why not just
install it on startup? You have no idea what the cause of the exception here
is. Once the classloader provider is replaced, there is no way to get back to
the default one.
Do you have an example where the TCCL is a better choice than the classloader
of the class being proxied?
> Don't replace the ProxyFactory classloaderProvider without the intention to
> do so
> ---------------------------------------------------------------------------------
>
> Key: OWB-496
> URL: https://issues.apache.org/jira/browse/OWB-496
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Context and Scopes
> Affects Versions: 1.1.0
> Reporter: David Jencks
> Assignee: Gurkan Erdogdu
> Fix For: 1.1.0
>
>
> Currently JavassistProxyFactory.getProxyClass() replaces the
> ProxyFactory.classloaderProvider on any exception with a classloaderProvider
> that is very unlikely to work better than the default. Setting the
> classLoaderProvider should be a matter of intentional configuration, not
> flailing around after an unexpected exception.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
