[jira] [Comment Edited] (CXF-8176) Apache CXF @Context not class loading.

["Andriy Redko (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-8176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061254#comment-17061254 ] 

Andriy Redko edited comment on CXF-8176 at 3/17/20, 11:26 PM:
--------------------------------------------------------------

Hey [~karlvr1] , my apologies for delay, things got much busier than expected ... Anyway, we don't have the fix for CXF yet, athough problem is understood, however there is a workaround to try out. So basically the idea is to hint Weld to use the ClassLoader from the current thread for the HttpServletRequest (instead of the URLClassLoader). Weld supports that out of the box using Java's service loaders.

1. File *META-INF/services/org.jboss.weld.bootstrap.api.Service*
{noformat}
demo.jaxrs.servlet.ThreadLocalProxyServices {noformat}
2. File *ThreadLocalProxyServices*:
{noformat}
package demo.jaxrs.servlet;

import org.jboss.weld.bean.proxy.util.SimpleProxyServices;

public class ThreadLocalProxyServices extends SimpleProxyServices {
    @Override
    public ClassLoader getClassLoader(Class<?> proxiedBeanType) {
        return Thread.currentThread().getContextClassLoader();
    }
} {noformat}
ThreadLocalProxyServices could be enhanced a bit to deal with *java.servlet.** classes (and minimize the potential side effects) and delegate to the parent otherwise. Is it something helpful for you? Thank you.


was (Author: reta):
Hey [~karlvr1] , my apologies for delay, things got much busier than expected ... Anyway, we don't have the fix for CXF yet, athough problem is understood, however there is a workaround to try out. So basically the idea is to hint Weld to use the ClassLoader from the current thread for the HttpServletRequest (instead the URLClassLoader). Weld supports that out of the box using Java's service loaders.

1. File *META-INF/services/org.jboss.weld.bootstrap.api.Service*
{noformat}
demo.jaxrs.servlet.ThreadLocalProxyServices {noformat}
2. File *ThreadLocalProxyServices*:
{noformat}
package demo.jaxrs.servlet;

import org.jboss.weld.bean.proxy.util.SimpleProxyServices;

public class ThreadLocalProxyServices extends SimpleProxyServices {
    @Override
    public ClassLoader getClassLoader(Class<?> proxiedBeanType) {
        return Thread.currentThread().getContextClassLoader();
    }
} {noformat}
ThreadLocalProxyServices could be enhanced a bit to deal with *java.servlet.** classes (and minimize the potential side effects) and delegate to the parent otherwise. Is it something helpful for you? Thank you.

> Apache CXF @Context not class loading.
> --------------------------------------
>
>                 Key: CXF-8176
>                 URL: https://issues.apache.org/jira/browse/CXF-8176
>             Project: CXF
>          Issue Type: Bug
>          Components: Integration
>    Affects Versions: 3.2.2
>            Reporter: Richard O'Sullivan
>            Priority: Major
>         Attachments: CXF-ContentProducerBean-Fail-to-Load-Stacktrace.txt, cxf-servlet-bug.tar.gz
>
>
> I have a WAR containing cxf-integration-cdi-3.2.1.jar that I deploy to Tomcat V9, successfully. When I deploy a WAR containing cxf-integration-cdi-3.2.7.jar, it fails to deploy because:
> {quote}org.jboss.weld.exceptions.WeldException: WELD-001524: Unable to load proxy class for bean org.apache.cxf.cdi.ContextProducerBean@28c30f4d with class class java.lang.Object using classloader java.net.URLClassLoader@695caf9f
> {quote}
> My WAR includes the Weld v2.4.6 jars.
> Note: The ContextProducerBean class was introduced in CXF v3.2.2. 
> Others on the web, have reported a similar issue:
>  * [https://stackoverflow.com/questions/56905194/class-not-found-in-war-but-is-available]
>  * [https://t.codebug.vip/questions-112783.htm]
>  I'm suspicious that there is no scope modifier on the constructor in the ContextProducerBean class; thus, causing the scope to default to 'package private' and become hidden from Tomcat's class loader. Also, the super class, AbstractCXFBean<Object> does not declare a scope either. The fix might be to add the 'public' modifier to both, just guessing.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)