[JBoss JIRA] (JBWS-3628) Add property expansion capability to .wsdl files
by Alessio Soldano (JIRA)
[ 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.
> Add property expansion capability to .wsdl files
> Key: JBWS-3628
> URL: https://issues.jboss.org/browse/JBWS-3628
> Project: JBoss Web Services
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: jbossws-cxf
> Reporter: david.boeren
> Assignee: R Searls
> Priority: Minor
> Fix For: jbossws-cxf-5.0
> Attachments: JBWS-3628-tentative-patch-from-Rebecca.txt
> The customer is doing JMS-based webservices using the following declarations in their wsdl file (referred to using the wsdllocation annotation):
> <soapjms:jndiConnectionFactoryName>myqueue</soapjms:jndiConnectionFactoryName> <soapjms:jndiInitialContextFactory>com.vendor.InitialContextFactory</soapjms:jndiInitialContextFactory>
> The $MY_URL is the url of the messaging server. Since property replacement does not work for wsdl files they need to manually modify this before deploying and package separate versions of their app for each environment. If property expansion worked in the .wsdl this would no longer be necessary.
This message was sent by Atlassian JIRA