Any workaround for ignoring unexpected elements in Apache Axis 1.4?

Question

The problem was asked before "Apache AXIS Ignore/Skip additional element while parsing" in 2012 for Apache Axis 2. Is there no workaround yet for Axis 1.4?

Problem Definition

For instance;

1- We have a soap response definition('ResponseGetCustomerInfo') in our wsdl while development[with Axis 1.4]:

...
  <xs:element name="ResponseGetCustomerInfo">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="ns1:CustomerID"/>
        <xs:element ref="ns1:CustomerUsername"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="CustomerID" type="xs:integer"/>
  <xs:element name="CustomerUsername" type="xs:string"/>
...

2- Is good to see that response is parsable when we get like this:

<?xml version="1.0" encoding="utf-8" ?> 
<soap:Envelope 
    xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <soap:Body>
        <ResponseGetCustomerInfo xmlns="http://tempUri.org/">
            <CustomerID>1</CustomerID>
            <CustomerUsername>raki</CustomerUsername>
        </ResponseGetCustomerInfo>
    </soap:Body>
</soap:Envelope>

3- After some time, our service provider changed the service response and adds new output fields to response and we don't know when or why;

<?xml version="1.0" encoding="utf-8" ?> 
<soap:Envelope 
    xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <soap:Body>
        <ResponseGetCustomerInfo xmlns="http://tempUri.org/">
            <CustomerID>1</CustomerID>
            <CustomerUsername>raki</CustomerUsername>
            <CustomerName>Raki</CustomerName>
            <CustomerSurname>Bandao</CustomerSurname>
        </ResponseGetCustomerInfo>
    </soap:Body>
</soap:Envelope>

4- New response theoretically compatible with older version because of no field neither deleted nor changed. But Axis can not parse the response:

"SAXException: Invalid Element ... "

I don't want to update wsdl and regenerate web service client again. So, Is there any way to skip "Unexpected[newly added] elements" in the response? or any workaround?

I am trying many ways, but could not find any solution yet.

Answer 1

We always go through this hell due to bad vendors writing these services.

So, unfortunately, there's no way out using parameters for WSDL2JAVA, BUT there is a workaround, you'll to re-generate stubs at least once:

1. Replace xs:sequence with xs:all. This allows elements to be returned in any order, and helps fix a lot of cases, as well as generated stub code which makes it easier for step
2. Sorry, but you for each response bean, you go into its class from the generated code (such as ResponseGetCustomerInfo.java), and instead of this:

while(!reader.isStartElement() && !reader.isEndElement())
   reader.next();

if(reader.isStartElement())
// A start element we are not expecting indicates a trailing invalid
// property
throw new org.apache.axis2.databinding.ADBException("Unexpected subelement " + reader.getLocalName());

Have this:

while(!reader.isStartElement() && !reader.isEndElement())
   reader.next();

// if(reader.isStartElement())
// A start element we are not expecting indicates a trailing invalid
// property

// The below is commented, to prevent unexpected result parameters from causing an exception
// (As well as the condition above is removed)
//  throw new org.apache.axis2.databinding.ADBException("Unexpected subelement " + reader.getLocalName());

It's tested and works at least better than no solution.

Answer 2

Not having used Axis 1.4, but after a quick glance at the docs.

You can add a Handler to your code. You should be able even do this without having to recompile it, it that's an issue. A Handler wraps the underlying web service, it's called before the service is invoked, and after it returns. It's sorta like a Servlet Filter, but for Web Services.

The Handler has full access to the SOAP body before it gets sent forward for processing. So you can use this as an opportunity to remove elements that you don't like.

Dig a bit and you'll find you eventually get a DOM element that represents your SOAP body, so you can play primitive DOM games to add/delete nodes, etc. and set that back all within the Handler.

Your service will never see the new nodes in the edit SOAP body.

All that said, you may well be able to even do this using a Servlet Filter as well.

Answer 3

Try using Metro library instead of Axis, it worked for me in October 2014. Please, ignore this suggestion if you must use Axis library.

Using Axis 2 library to create a Java client that calls .NET WCF service (communicating over the Internet securely), we got errors generating Java client class from WSDL. As a workaround, we switched to a different library, Metro 2.3, and we were able to generate Java client that runs without any problems.

One of the important steps to getting a successful secure web service call from Java was configuring client and server certificates.