[
https://issues.apache.org/jira/browse/OWB-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13895502#comment-13895502
]
Mark Struberg commented on OWB-931:
-----------------------------------
I also thought a bit more about it. Having the ClassLoader for our proxies
configurable could make sense for situations where we have CDI beans which are
_outside_ of the EAR classloader, e.g. in a shared container lib.
In this case it does not make sense to create the proxy with the
app-classloader, but it should create it with the EAR-classloader. Otherwise we
would leave the app-classloader with unused proxy classes on an undeployment.
Of course this is only possible if the container does not use CDI internally
itself.
I honestly believe that we already have a pretty low chance of leaving class
mem leaks as we store the created proxy class with our Producer it is used for.
Other libraries (like javassist which we used before doing all the bytecode
ourself) cannot do this, as they don't have a chance to know for which Producer
and InjectionTarget the proxy was meant for. Thus (on de-serialisation) they
will always create a new proxy class :/
> NormalScopeProxyFactory classloader usage
> -----------------------------------------
>
> Key: OWB-931
> URL: https://issues.apache.org/jira/browse/OWB-931
> Project: OpenWebBeans
> Issue Type: Brainstorming
> Components: Core
> Affects Versions: 1.2.0
> Reporter: Moritz Bechler
> Labels: ClassLoader, OSGI
>
> createNormalScopeProxy currently uses the bean class ClassLoader for two
> purposes:
> 1. defining the proxy class
> 2. instantiation of the instance provider.
> In our OSGI/WAB environment this usage does not make much sense:
> 1. the proxy class should be defined in the classloader which most closely
> reflects the CDI context lifecycle, which is the web context TCCL.
> 2. causes trouble with scope providers (e.g OWB's own
> RequestScopedBeanInterceptorHandler) when they are defined in another bundle.
> I don't think there is a proper compatible solution to this (except maybe
> making extensions fragments) but also trying the TCCL makes this much more
> painless to use.
> Is there any explanation for this particular choice of classloaders? Are
> there any reasons not to try TCCL first?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
