由于之前用的是Xfire，发现有些不稳定，并且由于业务的不多接入扩大，所以今天考了同时在项目中放入CXF2.6.0，确实有些包冲突，目前调整的话，Xfire服务器端可以和CXF共用新版本的xmlschema.jar，但在客户端Xfire只能用xmlschema.jar的旧版本；同时需要加入neethi.jar包。
在经过列子测试中
接口类：com.service.ISaveLove.java;
业务类：com.service.spring.SaveLoveImpl.java;
方法：public String saveLove(String love);
结果发现，总是提示
No operation was found with the name {http://spring.service.com/}saveLove
后来从博客中得到一定灵感，来源博客为 http://lost-alien.iteye.com/blog/1175859
发现楼主所描述的问题很类似，楼主所描述的：
{http://impl.service.ws.mywebapp.com/}
targetNamespace="http://service.ws.mywebapp.com/"
脑子闪过一下：
估计到http://service.ws.mywebapp.com/是接口类所在路径，
而http://impl.service.ws.mywebapp.com/应该是业务类所在位置，
CXF默认取的是接口类所在路径作为命名空间，Xfire确实不加入这个可以正确访问，也是由于命名空间正好是对的；
果然，经过测试：把接口类和业务类放在同一个路径下时，就能测试通过了，回过头去查了一下CXF自带的测试列子，里面也是把接口类和业务类放在同一个路径下（也是为了偷懒）；其实按照楼主的做法还是比较科学，在业务类的文件头部同时加入@WebService(targetNamespace = "http://service.com/",
endpointInterface = "com..service.ISaveLove")
能明确定义命名空间所在位置。
后来回过头来看发布报文，在没有加入targetNamespace参数时，如果接口类和业务类不在同一个路径下，Webservice是能正常启动，但是看到的文档描述中，函数参数描述都是
<soap:body use="literal" />
很明显发布的wsdl文档是错误的；如果接口类和业务类在同一个路径，那参数描述应该是
<xsd:element minOccurs="0" name="arg0" type="xsd:string" />
以上做为日志记下，希望能对来访博友有用！