[
https://issues.apache.org/jira/browse/OWB-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Moritz Bechler updated OWB-931:
-------------------------------
Attachment: OWB-931-v1.patch
A first draft introducing a ClassLoaderService SPI with two methods:
- one to decide in which classloader a proxy for a certain class will be defined
- one to load owb extensions (classes referenced by openwebbeans.properties),
the naming might be a bit unfortunate as this might be confused with CDI
extensions. Not to break current behavior this may return null - I'd rather get
rid of this.
The behaviour should be exactly the same as before.
Quickly grepping through the remaining code I also found AbstractProducer is
generating proxies into the class' classloader, this is also patched.
One minor other issue I noticed: In DefaultOwbFailOverService there is one
instance of Class.forName(String). This is probably also a case for the
extension classloaders/WebBeansUtil.getCurrentClassLoader().
All other relevant classloading stuff I found seems to use
WebBeansUtil.getCurrentClassLoader() (TCCL falling back to the classloader
loading OWB). Most of these could be replaced by ClassLoaderService calls,
possibly distinguising between domain class and owb internal classes.
Romain: Do you have any objection against loading the scope provider through
WebBeansUtil.getCurrentClassLoader()? All other config referenced classes seem
to be loaded this way.
> 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
> Attachments: OWB-931-v1.patch
>
>
> 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)
