[
https://issues.apache.org/jira/browse/CXF-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13209307#comment-13209307
]
Glen Mazza commented on CXF-4115:
---------------------------------
Rather than "Expected behavior is to get back some undefined value, e.g. null,
to indicate the requested operation could not be determined" I think it should
be "Expected behavior is to get back some undefined value, e.g. null, to
indicate framework making no effort to match the incoming request with a
specific SEI operation." If you're using a Provider-based service, the
framework should be throwing all SOAP requests to it, so the algorithm it uses
to match SOAP request to specific SEI operations (when using SEI-based
services) should never have been activated anyway.
Or maybe not. The difference in approach here is with Provider it is still
possible for the CXF framework to try to match the SOAP request to a specific
wsdl:operation (even though there's no corresponding unique method in a
Provider implementation to be called as a result), which would allow Provider
implementations that ability to base business logic off of a populated
MessageContext.WSDL_OPERATION instead of parsing the SOAP request to determine
the functionality that needs to be called. A case can be made for this but as
I linked to in the superceding bug CXF-4108, Metro does not offer this so such
functionality would break portability, and this algorithm activation for
incoming calls to the Provider would cause some (probably minor) performance
hit.
> The operation property of the MessageContext may return wrong value if
> erroneous request is sent
> ------------------------------------------------------------------------------------------------
>
> Key: CXF-4115
> URL: https://issues.apache.org/jira/browse/CXF-4115
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
> Affects Versions: 2.5.2
> Reporter: Zsolt Beothy-Elo
> Attachments: jaxws_dispatch_provider.zip, request.txt
>
>
> Send a random request to a Provider based service. Retrieving the operation
> property from the MessageContext within the invoke method always returns an
> operation defined in the attached wsdl even if the the rquest is completely
> unrelated, e.g. unknown SOAPAction, payload not matching any schema in the
> WSDL.
> Expected behavior is to get back some undefined value, e.g. null, to indicate
> the requested operation could not be determined.
> Attached is the slightly modified jaxws_dispatch_provider sample. The changes
> were basically made in demo.hwDispatch.server.GreeterSoapMessageProvider:
> {code:title=GreeterSoapMessageProvider.java}
> @WebServiceProvider(portName = "SoapPort1", serviceName = "SOAPService1",
> targetNamespace =
> "http://apache.org/hello_world_soap_http";,
> wsdlLocation = "wsdl/hello_world.wsdl")
> @ServiceMode(value = Service.Mode.MESSAGE)
> public class GreeterSoapMessageProvider implements Provider<SOAPMessage> {
> @Resource
> private WebServiceContext context;
> public SOAPMessage invoke(SOAPMessage request) {
> QName opName = (QName)
> context.getMessageContext().get(MessageContext.WSDL_OPERATION);
> System.out.println("Incoming Client Request as a SOAPMessage calling
> operation " + opName);
> ...
> {code}
> If sending the request attached in the output of the console is:
> {{monospaced}}Incoming Client Request as a SOAPMessage calling operation
> {http://apache.org/hello_world_soap_http}greetMe{{monospaced}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
