Axiom
  1. Axiom
  2. AXIOM-180

SOAP11FaultCodeImpl contains SOAP 1.2 local name

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      AXIOM 1.0, JDK 1.5

      Description

      The class org.apache.axiom.soap.impl.llom.soap11.SOAP11FaultCodeImpl does not override the localname of its parent org.apache.axiom.soap.impl.llom.SOAPFaultCodeImpl. Since this parent class contains the SOAP 1.2 specific SOAP12Constants.SOAP_FAULT_CODE_LOCAL_NAME as localname, the localname is of the SOAP 1.1 subclass is not set correctly.

      Oviously, this code should be in org.apache.axiom.soap.impl.llom.soap12.SOAP12FaultCodeImpl, and not in the non-version specific superclass. In general, there seems to be a lot of defaulting to SOAP 1.2-specific stuff in the org.apache.axiom.soap.impl.llom package. This should be moved to the version-specific subclasses.

      The errors become clear when obtaining an XMLStreamReader from the fault code, and reading from that. Serializing to an outputstream does work correctly, since the serialize methods are properly overridden.

      1. Tester.java
        1.0 kB
        Arjen Poutsma

        Issue Links

          Activity

          Hide
          Eran Chinthaka added a comment -

          I'd prefer if you could raise this issue in the mailing list so that answering for each and every point would have been easier.

          About SOAP classes packaging :
          Let me explain the rationale behind the current Fault implementation. It was by design we made SOAP 1.2 as the visible api. As you all know there are some differences between SOAP 1.1 and SOAP 1.2. We selected the second option.
          What that means is our prime api is SOAP 1.2 ish. So its correct to have them in o.a.a.soap.impl.llom.

          About SOAP fault name not being overriden :
          If both the names are the same I didn't see any reason behind overriding it un-necessarily. Perhaps we might change the name a bit.

          Show
          Eran Chinthaka added a comment - I'd prefer if you could raise this issue in the mailing list so that answering for each and every point would have been easier. About SOAP classes packaging : Let me explain the rationale behind the current Fault implementation. It was by design we made SOAP 1.2 as the visible api. As you all know there are some differences between SOAP 1.1 and SOAP 1.2. We selected the second option. What that means is our prime api is SOAP 1.2 ish. So its correct to have them in o.a.a.soap.impl.llom. About SOAP fault name not being overriden : If both the names are the same I didn't see any reason behind overriding it un-necessarily. Perhaps we might change the name a bit.
          Hide
          Arjen Poutsma added a comment -

          The attached sample program clarifies the issue. When writing a SOAP 11 SOAPFaultCode with serialize(), it outputs the correct XML. However, when I read from it using a XMLStreamReader, the SOAP 1.2 local names are returned.

          Show
          Arjen Poutsma added a comment - The attached sample program clarifies the issue. When writing a SOAP 11 SOAPFaultCode with serialize(), it outputs the correct XML. However, when I read from it using a XMLStreamReader, the SOAP 1.2 local names are returned.
          Hide
          Eran Chinthaka added a comment -

          I'm still not convinced that this is a bug.

          I repeat, we treat all the SOAP messages as SOAP 1.2 messages inside the model. Once we feed SOAP 1.1 message in to the model, its SOAP 1.2 after that. You only see the difference when you serialize.
          For example, you can write a service implementation only thinking about SOAP 1.2. If your service implementation is StAX based, still our model works. But when we serialize, the only catch is you have to use Axiom serializer. This decision was intentional and thus this is a feature, not a bug.

          Show
          Eran Chinthaka added a comment - I'm still not convinced that this is a bug. I repeat, we treat all the SOAP messages as SOAP 1.2 messages inside the model. Once we feed SOAP 1.1 message in to the model, its SOAP 1.2 after that. You only see the difference when you serialize. For example, you can write a service implementation only thinking about SOAP 1.2. If your service implementation is StAX based, still our model works. But when we serialize, the only catch is you have to use Axiom serializer. This decision was intentional and thus this is a feature, not a bug.
          Hide
          Glen Daniels added a comment -

          IMHO, this is indeed a bug.

          It's fine to use the SOAP 1.2 APIs when thinking about services at the "abstract" level (i.e. OM). I do not think it is OK to actually return incorrect XML when using getXMLStreamReader() on a SOAP11 envelope. What gets output from serialize() should always be the same as what you get from the XMLStreamReader, regardless of whether the OM was generated programatically or read in from a stream.

          Make sense?

          Show
          Glen Daniels added a comment - IMHO, this is indeed a bug. It's fine to use the SOAP 1.2 APIs when thinking about services at the "abstract" level (i.e. OM). I do not think it is OK to actually return incorrect XML when using getXMLStreamReader() on a SOAP11 envelope. What gets output from serialize() should always be the same as what you get from the XMLStreamReader, regardless of whether the OM was generated programatically or read in from a stream. Make sense?

            People

            • Assignee:
              Eran Chinthaka
              Reporter:
              Arjen Poutsma
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development