[
https://issues.apache.org/jira/browse/CXF-6787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15156815#comment-15156815
]
Sergey Beryozkin commented on CXF-6787:
---------------------------------------
We can't test WADLgenerator at startup - because we do not have a request
message either at that point, hence we don't have UriInfo, and emulating it all
to get some WADL generated only to check if this provider is usable seems wrong
to me to be honest.
IMHO the right solution is not to include it in common but recommend the users
who expect WADL be supported to include it in their web apps, as opposed to CXF
trying to fix various CL-related container issues at the code level.
That said, I'm also going to update the code - if the current message is null
then simply 'return'.
> 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)
