[
https://issues.apache.org/jira/browse/CXF-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978884#action_12978884
]
Glen Mazza commented on CXF-3235:
---------------------------------
Devil's advocate: Since this code is apparently new can't we hold off on adding
the switch and instead put JIRAs in for other implementations to become
compliant with the spec? The problem with adding this flag is that once it's
in there, it will always be in there (with whatever subsequent security or
accuracy risks inherent in shutting off these faults), and I'm not sure that
CXF should worry about obsolete implementations that cannot send the required
JMS properties. (Here I define "obsolete" as not an implementation that
presently does not support the JMS properties but is so inactive that JIRAs to
that particular project would *not* result in the problem being fixed.)
What are the primary nonsupporting implementations you're concerned about right
now that causes you to want to add this flag?
Glen
> Introduce a switch for the soap/jms spec transport to turn of
> SoapJMSInInterceptor
> ----------------------------------------------------------------------------------
>
> Key: CXF-3235
> URL: https://issues.apache.org/jira/browse/CXF-3235
> Project: CXF
> Issue Type: Improvement
> Reporter: Christian Schneider
> Fix For: 2.3.2
>
>
> The soap/jms spec requires several jms properties like SOAPJMS_contentType to
> be set on an incoming message. In case the required properties are not
> present a fault is returned.
> While this is perfectly compliant with the spec it creates interop problems
> with implementations that do not yet follow the spec.
> So I propose to introduce a switch that disables the SoapJMSInInterceptor or
> that turns the faults into warnings. This would allow older clients to
> interoperate with cxf.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
