[
https://issues.apache.org/jira/browse/CXF-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15156804#comment-15156804
]
Romain Manni-Bucau commented on CXF-6787:
-----------------------------------------
[~sergey_beryozkin] cause it is in tomcat common.loader. As a user you control
WEB-INF/lib but not tomcat/lib. However main issue IMHO is CXF creates a
runtime which doesn't work implicitely in such a case and you get the surprise
at runtime. The workaround is to *add* cxf-rt-rs-service-description in the
webapp to still load WadlGenerator but from the right classloader but would
have been better to have validated it at startup (and if CXf validates it then
it can skip WadlGenerator ;)).
> 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)
