[ https://issues.jboss.org/browse/JBWS-3628?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3628: --------------------------------------- OK, I see. So we can't "fool" CXF into using a different location for the wsdl. Btw, I also remember that CXF has a wsdl cache mechanism that is based on the wsdl url, so playing with the wsdl location url might definitely be risky. The idea of running a filter at the time CXF parses the wsdl into the WSDL4J Definition model is interesting; something I've noticed in the patch is that is applies to the JMS wsdl extensibility element only. So we'd need to clarify in advance which elements actually support property expansion and which do not. Something I've been thinking about is why don't we run the filter directly at WSDL4J level? javax.wsdl.factory.WSDLFactory (which is used by CXF to parse the wsdl) lets us have a different implementation of WSDLFactory (see newInstance() and findFactoryImplName() methods). We could have a custom WSDLFactory impl that runs our filters and eventually delegates to the default WSDLFactory impl (or to what would have been resolved before, but that's an impl detail). The filtering could either be performed through pluggable filters as you did in your last patch for cxf, or (better, I think) be StAX / DOM based on the whole document (depends on which readWSDL method flavor is called). The advantage are no need to have changes in CXF and a solution that applies to any component relying on the WSDLReader. -- This message was sent by Atlassian JIRA (v6.2.6#6264)