[
https://issues.apache.org/jira/browse/CXF-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152657#comment-15152657
]
Romain Manni-Bucau commented on CXF-6787:
-----------------------------------------
if you have:
{code}
common.loader
| |
web1 web2
{code}
if common loader has CXF and web1/WEB-INF/lib has cxf but the description
module then web1 will be able to load the class but its classloader will be
upper the web1 where cxf bus and rs modules for instance will be loaded so the
wadlgenerator will not work.
A quick fix for my case (tomcat/tomee) is to check
wadlgenerator.getClassLoader() != JAXRSUtils.getClassLoader().getParent() but I
guess it would be easier to check it trying to call it or anything else.
Side note: a workaround is to add to web1 the description jar but this is not a
real solution, more a workaround
> not sufficient WadlGenerator presence detection
> -----------------------------------------------
>
> Key: CXF-6787
> URL: https://issues.apache.org/jira/browse/CXF-6787
> Project: CXF
> Issue Type: Bug
> Affects Versions: 3.0.3, 3.1.4
> Reporter: Romain Manni-Bucau
>
> org.apache.cxf.jaxrs.provider.ServerProviderFactory#createWadlGenerator do a
> loadClass to check WadlGenerator is there but if it is there in a upper
> classloader and cxf in a lower classloader then it will get instantiated but
> will not work (cause JAXRSUtil.currentmessage() will be loaded in both
> classloaders and will not be shared if the lower classloader is a webapp one).
> Would be great to check once loaded the instance is actually usable before
> adding it.
> This pattern is used in few other places - I suspect management part as well
> since I got the issue too - but this one broke archiva in tomee for instance.
> Side note: reported the versions I tested with but I guess most of CXF
> versions are affected
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
