[
https://issues.jboss.org/browse/JBWS-3628?page=com.atlassian.jira.plugin....
]
Alessio Soldano commented on JBWS-3628:
---------------------------------------
Rebecca,
again, please do not stick to this specific JMS endpoint scenario. If a property expansion
capability is to be provided, that will have to be a generic solution applying to any (or
at least to a defined set of) elements of a provided wsdl contract.
Perhaps we can process the provided wsdl, expand the property references and then have CXF
work on the modified wsdl?
The testing automation can be dealt with; the WFLY management model allows setting system
properties; we might need to expand the org.jboss.wsf.spi.deployer.Deployer /
org.jboss.as.webservices.deployer.RemoteDeployer for that, but I'd rather have a valid
plan for addressing this jira before working on the test automation. Thanks!
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
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>
<soapjms:jndiURL>$MY_URL</soapjms:jndiURL>
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
(v6.2.3#6260)