[
https://issues.apache.org/jira/browse/OWB-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896581#comment-13896581
]
Moritz Bechler commented on OWB-931:
------------------------------------
So about loading the provider class? I should have opened two tickets for this.
I think the point here is that the current situtation is a hack (probably
resulting from EE environments where the core-impl is residing in the container
and extensions may reside in the EAR, so basically this tries to fetch the EAR
classloader) and conceptually wrong (the bean classes classloader is explicitly
used while the bean class does and should not have any dependency on the scope
provider impl).
Actually, the proper solution would be to load the scope provider using the
classloader through which the properties file defining it was loaded, but that
may be asking too much ;)
I'm aware of these issues and spend a lot of time working around them. All I'm
asking for right now is a solution which relieves me from unneccesarily
maintaining forked code. Im sure this will also benefit other projects working
towards EE in OSGI solutions.
> 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)
