This deployer can load the cxf descriptor file (eg. cxf/jbossws-cxf.xml) in CXF to start jms trasnport . and resposible for started endpoints registration.It is also mainly for jave first web service in CXF stack . For the requirment to enable a service both with servlet transport and jms transport , and provide wsdl query via servlet transport , we can remain the current deployment approach.

The point here is that we need to deploy cxf jms endpoint independently from the http endpoint, which might not even be provided. For this reason we need a mean of processing the jbossws-cxf.xml at deplyo time, instead of when initializing the CXFServletExt we have (that extends the CXF servlet). Basically we need a correct integration point for jms transport.So, Richard is right in saying that adding a new deployer might not be a viable solution as it will break the current container integration.A proposal for doing this might then be to add another deployment aspect for doing what Jim originally though about doing in the new deployer (parsing the jbossws-cxf.xml, installing the jms only endpoint, start the cxf bus, etc.) and leave the generated webapp there just to serve wsdl requests (in case of jms only endpoints of course).

Looked at the current deployment code again , it seems adding another DA can not make this work : if there is no web.xml , the WSTypeDeployer will not generate a Deployment type for the jms endpoint . Then the WSDeploymentAspectDeployer will not trigger the DAs to process this ws deployment. So creating another DeploymentType for the jms endpoint can make this work , but it is kind of deployment type concept violation.