[
https://issues.apache.org/jira/browse/OWB-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896435#comment-13896435
]
Moritz Bechler commented on OWB-931:
------------------------------------
These will be loaded by the openwebbeans-impl bundle classloader. I could embed
the JARs in the WAB bundle but that kind of defeats the purpose. Imho, in our
scenario, forcibly defining in the WAB classloader (we use CDI only for JSF) is
the proper solution as the CDI context lifecycle is bound to the WAB's.
I had a quick look at what guice is doing and it is pretty complex: they have
logic in place to detect visibility issues and if that is not an issue they
create a bridge classloader below the target classes classloader into which the
proxy is defined.
Maybe I have some spare time this week and can put together a patch which moves
the classloader selection logic out of NormalScopeProxyFactory and allows
overriding it (one method to override proxy class target and one to provide a
classloader for loading extensions). This might be a good start to tackle both
issues.
> 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)
