org.xml.sax.SAXException: Bad types

This article talks about one of the important SAX exceptions we encounter while building/invoking SOAP web services.

To understand why this error happens in the first place,the person has to have knowledge about WSDL binding styles.Please refer to any online documents to understand WSDL binding styles.

May be there are many reasons why we see this error, but I am going to discuss here one of the main causes that brings this error.

rpc/encoded style web service invocation is one of the reasons for this error.

Let's see what is the significance of RPC style web services.

Sample rpc/encoded style WSDL:

<message name="SumMethodReqMsg">
    <part name="x" type="xsd:int"/>
    <part name="y" type="xsd:float"/>

</message>

<message name="ResultRespMsg">

     <part name="result" type="xsd:float"/>

</message>

<portType name="Port">

    <operation name="sumMethod">

        <input message="SumMethodReqMsg"/>

        <output message="ResultRespMsg"/>

    </operation>

</portType>

<binding .../> 

rpc/literal WSDL to SOAP request message translation:
Below  format is  how message looks like on the wire.
<soap:envelope>
    <soap:body>
        <sumMethod>
            <x xsi:type="xsd:int">2</x>
            <y xsi:type="xsd:float">7.0</y>
        </sumMethod>
    </soap:body>
</soap:envelope>

If you clearly observe above, there is something different form how document/literal style service  composes SOAP message.

Well, here are the differences.

• Here operation name appears in the message,this is not true for document/literal style web service.
• The type encoding info (such as "xsi:type="xsd:int" and "xsi:type="xsd:float").We can not see this information on  document/literal web services.

Here catch is, when we pass on input request to rpc/literal service, we tend to ignore declarations like "xsi:type="xsd:int" and "xsi:type="xsd:float" on input elements.

but above type information is mandatory for rpc style web service invocations.

Put a transform activity before invoke and make sure above type formation is passed on to service as part of request.

If issue still persists,then pass below name space nodes also.

xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

Now request becomes

<soap:envelope>
    <soap:body>
        <sumMethod>
            <x xsi:type="xsd:int"xmlns:xsd="http://www.w3.org/2001/XMLSchema"   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">2</x>
            <y xsi:type="xsd:float"xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">7.0</y>
        </sumMethod>
    </soap:body>
</soap:envelope>

Now I hope issue will be resolved.

Error deploying the composite ORABPEL-01010 Process Generation Failed.- deploy.lock (No such file or directory)

I have come across above said exception while I was deploying SOA 11.1.1.5 composite to Weblogic through Jdeveloper.

When I analyzed the issue what I understood  was, this error must be something to do with environment.

The probable reasons are listed down from most relevant to least.

Deployment utility has to create some temporary files  during deployment and for that we need sufficient space on server.These temporary files will be deleted later by same utility.

• Disk space issue
• OS file descriptor issue

Disk space issue:

1. Check your server mounted disk space using df command for Unix/Linux OS(For windows use different method)
2. If you find less space then add more space or clean up unnecessary files like logs
3. Now try deployment again(server restart not necessary)

OS file descriptor issue :

1. Check maximum number of files allowed to be open using ulimit -n command
2. If required, increase it.This depends upon type of shell we use.

You may use sysctl
 or
other ways:

In tcsh
limit descriptors 65535

In bash
ulimit -n 65535

Please talk to your admin to perform this activity.