使用 cxf 验证 wsdl/schema
我很难让 cxf 验证我的服务为第三方创建的 xml 请求。
我的项目使用maven。这是我的项目结构
主要模块:
+ 子模块1 = 应用程序
+ sub-Module2 = Interfaces
在接口中,src/main/resources 内我有我的 wsdl 和 xsd。 所以,src/main/resources + mywsdl.wsdl。 + myschema.xsd
接口子模块被列为应用程序子模块中的依赖项。 在应用程序子模块内,src/maim/resources 中有一个 cxsf 文件。
<jaxws:client name="{myTargerNameSpaceName}port"
createdFromAPI="true">
<jaxws:properties>
<entry key="schema-validation-enabled" value="true" />
</jaxws:properties>
</jaxws:client>
和:。
<jaxws:endpoint name="{myTargetNameSpaceName}port"
wsdlLocation="/mywsdl.wsdl"
createdFromAPI="true">
<jaxws:properties>
<entry key="schema-validation-enabled" value="true" />
</jaxws:properties>
</jaxws:endpoint>
我尝试将“name=”{myTargetNameSpaceName}port”更改为“name=”{myEndPointName}port”,
但没有铁砧。
我的应用程序有效。但它只是不验证我正在生成的、必须由第三方应用程序使用的 xml。 我希望验证工作正常进行,以便我发送的任何请求都是有效的。
有什么建议吗?
I am having a hard time getting cxf to validate an xml request that my service creates for a 3rd party.
My project uses maven. Here is my project structure
Main Module :
+ Sub-Module1 = Application
+ sub-Module2 = Interfaces
In Interfaces, inside src/main/resources I have my wsdl and xsd.
so, src/main/resources
+ mywsdl.wsdl.
+ myschema.xsd
The interface submodule is listed as a dependency in the Application-sub-module.
inside Application sub-module, there is a cxsf file in src/maim/resources.
<jaxws:client name="{myTargerNameSpaceName}port"
createdFromAPI="true">
<jaxws:properties>
<entry key="schema-validation-enabled" value="true" />
</jaxws:properties>
</jaxws:client>
AND:.
<jaxws:endpoint name="{myTargetNameSpaceName}port"
wsdlLocation="/mywsdl.wsdl"
createdFromAPI="true">
<jaxws:properties>
<entry key="schema-validation-enabled" value="true" />
</jaxws:properties>
</jaxws:endpoint>
I tried changing the "name="{myTargetNameSpaceName}port" to "name="{myEndPointName}port"
But to no anvil.
My application works. But it just do not validate the xml I am producing that has to be consumed by a 3rd party application.
I would like to get the validation working, so that any request that I send would be a valid one.
Any suggestions?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
只需在服务实现类上添加
@org.apache.cxf.annotations.SchemaValidation
注释,模式验证就会起作用。Just add
@org.apache.cxf.annotations.SchemaValidation
annotation on your service implementation class and schema validation will work.首先确保 name 属性的值为 {NAMESPACE}PORT_NAME,其中 NAMESPACE 是您的命名空间 URI,PORT_NAME 是您的 WSDL 端口的名称。在没有看到您的 WSDL 的情况下,我不知道您是否将 WSDL 端口命名为“port”,或者您是否只是给出了一个经过净化的示例。
例如,我的 WSDL 命名空间是“http://example.com/services”,以及我的 WSDL 的名称port 元素是“myPort”,Spring 配置看起来像这样
请参阅 CXF 文档
如果这不能解决您的问题,请尝试查看 wsdl_first 示例代码,升级您的 CXF 版本,和/或将您的问题与测试代码一起发布到 CXF 用户列表。
First ensure that the value of the name attribute is {NAMESPACE}PORT_NAME where NAMESPACE is your namespace URI and PORT_NAME is the name of your WSDL port. Without seeing your WSDL, I don't know if you named your WSDL port "port" or if you are just giving a sanitized example.
For example, my WSDL namespace is "http://example.com/services" and the name of my WSDL port element is "myPort", the Spring configuration would look like this
See "CreatedFromAPI" attribute description in CXF docs
If that doesn't solve your problem, try looking at the wsdl_first example code, upgrading your CXF version, and/or posting your question with test code demonstrating your issue to the CXF user list.
我们有类似的问题。 CXF 2.3.1 为我们解决了传入消息的问题,但没有解决传出消息的问题。
https://issues.apache.org/jira/browse/CXF-3233
我们通过整理消息并在服务器内验证它们,然后再通过 CXF 拦截器链发送出去来解决这个问题。我们使用 org.springframework.xml.validation.XmlValidator 进行验证。
我希望 CXF 的未来版本能够解决这个问题,但这就是我们现在所做的。
We had similar issues. CXF 2.3.1 fixed the issue for us on incoming messages but not outgoing messages.
https://issues.apache.org/jira/browse/CXF-3233
We work around it by marshaling the messages and validating them within the server before sending them out through the CXF interceptor chain. We validate using org.springframework.xml.validation.XmlValidator.
I'm hoping a future version of CXF will solve this but this is what we do for now.