CXF
  1. CXF
  2. CXF-3233

JAXB xsd validation working on incoming messages but not outgoing messages

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 2.3.1
    • Fix Version/s: Invalid
    • Component/s: Bus
    • Labels:
      None
    • Environment:

      WebLogic 10.0, WebSphere 6.1

      Description

      Using CXF 2.3.1.

      Generated Java from WSDLs using JAXB.

      Using

      <jaxws:properties>
      <entry key="schema-validation-enabled" value="true" />
      </jaxws:properties>

      in the client configuration.

      My test creates an object that fails this particular requirement of the WSDL:

      <xsd:simpleType name="UUID.Content">
      <xsd:annotation>
      <xsd:documentation xml:lang="EN">
      Universally Unique Identifier
      </xsd:documentation>
      </xsd:annotation>
      <xsd:restriction base="xsd:token">
      <xsd:length value="36" />
      <xsd:pattern
      value="[0-9a-fA-F]

      {8}

      -[0-9a-fA-F]

      {4}-[0-9a-fA-F]{4}

      -[0-9a-fA-F]

      {4}

      -[0-9a-fA-F]

      {12}

      " />
      </xsd:restriction>
      </xsd:simpleType>

      However, the message is marshalled and makes it all the way through the outgoing interceptor chain.

      The WSDL is one-way: input-only.

      wsdlLocation is specified in an annotation in the Impls.

      Interestingly, incoming messages that fail validation of this same constraint are blocked by the interceptor chain during unmarshalling.

      I'm testing on WebLogic. I could also test on WebSphere is needed.

      Other XSD validation failures (such as a missing required element) are being caught by the outgoing marshaller.

      The reason that we upgraded to 2.3.1 from 2.2.6 was that we were seeing similar issues on the inbound messages. In 2.3.1, complete XSD validation occurs for inbound messages but not for outbound ones.

        Activity

        Hide
        Benjamin Shults added a comment -

        I remember there being a problem in prior versions of CXF that may be related to this. I can't find a JIRA for it but if memory serves, certain types in schemas would make CXF use an unmarshaller that didn't do validation even when schema-validation was enabled.

        This JIRA may be related except on the outgoing (marshalling) side.

        Show
        Benjamin Shults added a comment - I remember there being a problem in prior versions of CXF that may be related to this. I can't find a JIRA for it but if memory serves, certain types in schemas would make CXF use an unmarshaller that didn't do validation even when schema-validation was enabled. This JIRA may be related except on the outgoing (marshalling) side.
        Hide
        Freeman Fang added a comment -

        Hi,

        What the exact value you set for UUID.Content?

        I just did a quick test and the outgoing messages validation works for me.
        My schema restriction looks like
        <xsd:simpleType name="MyType">
        <xsd:restriction base="xsd:string">
        <xsd:maxLength value="10" />
        </xsd:restriction>
        </xsd:simpleType>
        Then when I set a string with length 11, then I can see the exception like

        WARNING: Interceptor for

        {http://cxf.apache.org/jaxws/schemavalidation}

        service#

        {http://cxf.apache.org/jaxws/schemavalidation}

        ckR has thrown exception, unwinding now
        org.apache.cxf.interceptor.Fault: Marshalling Error: cvc-maxLength-valid: Value 'thisisffang' with length = '11' is not facet-valid with respect to maxLength '10' for type 'GUIDType'.
        at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:252)
        at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:169)
        at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:110)
        at org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutInterceptor.java:68)
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)
        at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
        at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
        at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
        at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
        at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)

        So you can see the outgoing message validation works as expected.

        Would you please append a whole testcase which I can reproduce the problem?
        As the problem you mentioned is on the client side, so you can just append your whole client side code(with configuration)?
        Btw, I guess your server is deployed in weblogic, but your client is standalone, is it correct?

        Freeman

        Show
        Freeman Fang added a comment - Hi, What the exact value you set for UUID.Content? I just did a quick test and the outgoing messages validation works for me. My schema restriction looks like <xsd:simpleType name="MyType"> <xsd:restriction base="xsd:string"> <xsd:maxLength value="10" /> </xsd:restriction> </xsd:simpleType> Then when I set a string with length 11, then I can see the exception like WARNING: Interceptor for {http://cxf.apache.org/jaxws/schemavalidation} service# {http://cxf.apache.org/jaxws/schemavalidation} ckR has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: Marshalling Error: cvc-maxLength-valid: Value 'thisisffang' with length = '11' is not facet-valid with respect to maxLength '10' for type 'GUIDType'. at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:252) at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:169) at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:110) at org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutInterceptor.java:68) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124) So you can see the outgoing message validation works as expected. Would you please append a whole testcase which I can reproduce the problem? As the problem you mentioned is on the client side, so you can just append your whole client side code(with configuration)? Btw, I guess your server is deployed in weblogic, but your client is standalone, is it correct? Freeman
        Hide
        Benjamin Shults added a comment -

        I took an automatically generated UUID and added the 'z' character to the end. This broke it in two ways: it made it too long and it added an illegal character. ('z' is not allowed anywhere in the value.)

        I have traced this all the way into com.sun.xml.bind.v2.runtime.MarshallerImpl. That class doesn't seem to be doing validation closely enough. It is called from org.apache.cxf.jaxb.JAXBEncoderDecoder.

        Show
        Benjamin Shults added a comment - I took an automatically generated UUID and added the 'z' character to the end. This broke it in two ways: it made it too long and it added an illegal character. ('z' is not allowed anywhere in the value.) I have traced this all the way into com.sun.xml.bind.v2.runtime.MarshallerImpl. That class doesn't seem to be doing validation closely enough. It is called from org.apache.cxf.jaxb.JAXBEncoderDecoder.
        Hide
        Benjamin Shults added a comment -

        The server application is both a client and a server. The WSDLs are similar on both sides in that they share most of their non-top-level types. So, I am testing both inbound and outbound services on the same server.

        I haven't gotten around to testing on WebSphere but I might get to it today. So far, all of my testing of this particular issue has been on WebLogic.

        Show
        Benjamin Shults added a comment - The server application is both a client and a server. The WSDLs are similar on both sides in that they share most of their non-top-level types. So, I am testing both inbound and outbound services on the same server. I haven't gotten around to testing on WebSphere but I might get to it today. So far, all of my testing of this particular issue has been on WebLogic.
        Hide
        Benjamin Shults added a comment - - edited

        I discovered that weblogic uses weblogic.apache.xerces.parsers.SAXParser instead of org.apache.xerces.parsers.SAXParser. I'll test whether forcing weblogic to use the apache class fixes this.

        EDIT: it did not fix this issue. However, forcing weblogic to use org.apache.xerces.parsers.SAXParser does fix validation using Spring Framework classes... not relevant to this bug, though.

        Show
        Benjamin Shults added a comment - - edited I discovered that weblogic uses weblogic.apache.xerces.parsers.SAXParser instead of org.apache.xerces.parsers.SAXParser. I'll test whether forcing weblogic to use the apache class fixes this. EDIT: it did not fix this issue. However, forcing weblogic to use org.apache.xerces.parsers.SAXParser does fix validation using Spring Framework classes... not relevant to this bug, though.
        Hide
        Benjamin Shults added a comment -

        I have confirmed that this is occurring on WebSphere as well.

        Show
        Benjamin Shults added a comment - I have confirmed that this is occurring on WebSphere as well.
        Hide
        Freeman Fang added a comment -

        testcase to verify schemavalidation works for outgoing message
        http://svn.apache.org/viewvc?rev=1058867&view=rev for trunk
        http://svn.apache.org/viewvc?rev=1058872&view=rev for 2.3 branch

        Show
        Freeman Fang added a comment - testcase to verify schemavalidation works for outgoing message http://svn.apache.org/viewvc?rev=1058867&view=rev for trunk http://svn.apache.org/viewvc?rev=1058872&view=rev for 2.3 branch
        Hide
        Freeman Fang added a comment - - edited

        Hi,
        I think the problem you encounter is that your client side somehow build service model from class, but not from the wsdl file, so no chance to load the schema xsds to do the schema validation on client side.

        I don't know how you create client, could you ensure that you specify wsdlLocation for client side? You may need take a look at [1] to get more details.
        You should be able to see some log like
        org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromWSDL
        or
        org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
        which indication how the service model is build from

        If it still doesn't work for you, I do need you provide a whole runnable testcase which I can reproduce it.

        Btw, I just commit a testcase(exactly same restriction as you use) which demostrate the schemavalidation works for outgoing message on client side.
        [1]http://cxf.apache.org/docs/jax-ws-configuration.html

        Freeman

        Show
        Freeman Fang added a comment - - edited Hi, I think the problem you encounter is that your client side somehow build service model from class, but not from the wsdl file, so no chance to load the schema xsds to do the schema validation on client side. I don't know how you create client, could you ensure that you specify wsdlLocation for client side? You may need take a look at [1] to get more details. You should be able to see some log like org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromWSDL or org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass which indication how the service model is build from If it still doesn't work for you, I do need you provide a whole runnable testcase which I can reproduce it. Btw, I just commit a testcase(exactly same restriction as you use) which demostrate the schemavalidation works for outgoing message on client side. [1] http://cxf.apache.org/docs/jax-ws-configuration.html Freeman
        Hide
        Benjamin Shults added a comment -

        Thanks for looking into this.

        We generated our Java code from the WSDLs. We have the wsdlLocation annotation in the client impls.

        It does partial validation: e.g. if any required element is missing, that is caught. This makes me believe that it is finding the WSDLs.

        It is only if one of these trickier validation errors is present it is not caught.

        Did you test on WebLogic 10.0 or WebSphere 6.1?

        Show
        Benjamin Shults added a comment - Thanks for looking into this. We generated our Java code from the WSDLs. We have the wsdlLocation annotation in the client impls. It does partial validation: e.g. if any required element is missing, that is caught. This makes me believe that it is finding the WSDLs. It is only if one of these trickier validation errors is present it is not caught. Did you test on WebLogic 10.0 or WebSphere 6.1?
        Hide
        Freeman Fang added a comment -

        Generate java code from wsdl is build time action, it doesn't mean will build servicemodule from wsdl during runtime.
        Did you check logs for your client side?
        You should see the output like
        org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromWSDL
        or
        org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
        which will tell you how the servicemodel build.

        No, I didn't test it on WebLogic 10.0 or WebSphere 6.1, I don't have those j2ee container at hand and I don't think it's a j2ee container specific problem.

        How you use client side code? And how you specify wsdlLocation annotation?
        If you can append a runnable testcase, I believe it would be very helpful to figure things out.

        Show
        Freeman Fang added a comment - Generate java code from wsdl is build time action, it doesn't mean will build servicemodule from wsdl during runtime. Did you check logs for your client side? You should see the output like org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromWSDL or org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass which will tell you how the servicemodel build. No, I didn't test it on WebLogic 10.0 or WebSphere 6.1, I don't have those j2ee container at hand and I don't think it's a j2ee container specific problem. How you use client side code? And how you specify wsdlLocation annotation? If you can append a runnable testcase, I believe it would be very helpful to figure things out.
        Hide
        Benjamin Shults added a comment -

        It reports that it is built from WSDL.

        Show
        Benjamin Shults added a comment - It reports that it is built from WSDL.
        Hide
        Freeman Fang added a comment -

        Any chance you append a runnable testcase?

        You can remove your business logic and just as small as we can reproduce the issue.

        Thanks

        Show
        Freeman Fang added a comment - Any chance you append a runnable testcase? You can remove your business logic and just as small as we can reproduce the issue. Thanks
        Hide
        Benjamin Shults added a comment -

        I have had several validation-related problems with CXF going back to 2.2. They have all turned out to be server-specific. Even this one had it's behavior change when I forced WebLogic to use Apache's implementation of a Xerces class instead of its own. I'm surprised that you are so confident that this is not server-specific.

        Can you check your test-case on one of the environments I mentioned? WebLogic is the one I have tested against the most.

        Show
        Benjamin Shults added a comment - I have had several validation-related problems with CXF going back to 2.2. They have all turned out to be server-specific. Even this one had it's behavior change when I forced WebLogic to use Apache's implementation of a Xerces class instead of its own. I'm surprised that you are so confident that this is not server-specific. Can you check your test-case on one of the environments I mentioned? WebLogic is the one I have tested against the most.
        Hide
        Daniel Kulp added a comment -

        Since JAXB just uses the javax.xml.validation.* API's that are provided by the JDK, it likely is dependent on the JDK and other libraries that are part of the app server and not something that is within CXF's control. All CXF can do is create the Schema from the validation API's and pass it to JAXB. The tests show that we ARE doing that properly. Beyond that, it's either a bug in JAXB (not calling the API's when needed) or in the validator implementation provided by the app server.

        Since this is outside of CXF's scope, can this be closed?

        Show
        Daniel Kulp added a comment - Since JAXB just uses the javax.xml.validation.* API's that are provided by the JDK, it likely is dependent on the JDK and other libraries that are part of the app server and not something that is within CXF's control. All CXF can do is create the Schema from the validation API's and pass it to JAXB. The tests show that we ARE doing that properly. Beyond that, it's either a bug in JAXB (not calling the API's when needed) or in the validator implementation provided by the app server. Since this is outside of CXF's scope, can this be closed?
        Hide
        Freeman Fang added a comment -

        Hi Dan,

        Yeah, I agree with you.

        And as user just see schema validation only doesn't work on client side, I suspect there MIGHT be something wrong when they configure the client, that's why I ask for the user testcase and hopefully I can find something there....

        Anyway, I'll go ahead to close this issue now.

        Regards
        Freeman

        Show
        Freeman Fang added a comment - Hi Dan, Yeah, I agree with you. And as user just see schema validation only doesn't work on client side, I suspect there MIGHT be something wrong when they configure the client, that's why I ask for the user testcase and hopefully I can find something there.... Anyway, I'll go ahead to close this issue now. Regards Freeman
        Hide
        Freeman Fang added a comment -

        added testcase to prove that CXF ARE doing that properly

        Show
        Freeman Fang added a comment - added testcase to prove that CXF ARE doing that properly

          People

          • Assignee:
            Freeman Fang
            Reporter:
            Benjamin Shults
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development