Differences between revisions 2 and 3
Revision 2 as of 2005-12-09 15:34:04
Size: 3946
Editor: RonReynolds
Revision 3 as of 2009-09-20 22:48:29
Size: 3946
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

Common Axis Exceptions (Java)

What's probably happening here is that you aren't setting the qualified name of the service properly. This means the name can't simply be an unqualified string, the namespace URI must also be included. Usually this means looking at the service's associated WSDL and making sure that the targetNamespace attribute value is used when the QName of the service is constructed

  • Exception: No client transport named 'null' found!

What's probably happening here is that you are forgetting to set the endpoint explicitly. If your endpoint uses the http scheme, this fact needs to be set on the Call object instance using the setTarget Endpoint Address function. For most newbies, you'll be using an http-based service and will need to create a java.net.URL object out of the endpoint first before calling setTarget Endpoint Address .

If you are trying to write your own handler and add it to the deployment descriptor, you may see this exception if you leave out the java namespace prefix on the type attribute value of <handler> element:


  •   <handler name="myHandler" type="java:GenericHandler" /> 

Make sure you don't forget the java prefix. This can be confusing because sometimes the class names get long and one might falsely assume that a qualified java class name goes here instead.

Make sure all directories listed in your  Axis/Tomcat/JDK  environment variables (in that order) do not contain spaces.





  • Exception: invalid xml character &0xC; (or other < 32 decimal char) on AXIS-Client side

Only three characters are allowed below decimal 32 in XML. If you are developing alongside a legacy application (or new one) that sends old ascii characters such as Form Feed / FF / 0xC, Server-side AXIS will not throw an exception. The client will however throw an exception and stop parsing the SOAP message. The solutions for this are:

  1. Parse out and remove those characters yourself on the server side. 
  2. Encode these strings in a Base64Encoding - this is actually pretty easy, just declare get/set methods with byte[] that masks a private String. 
  3. Encode these strings with custom escape-sequences, i.e. <company-name:esc value="0xC">, which your client must decode *after* standard String (de)serialization. 

This is logged because this code in AxisEngine (line 308 in Axis 1.x):

    public SOAPService getService(String name) throws AxisFault
        try {
            return config.getService(new QName(null, name));
        } catch (ConfigurationException e) {
            try {
                return config.getServiceByNamespaceURI(name);
            } catch (ConfigurationException e1) {
                throw new AxisFault(e);

depends on an exception being thrown on the first attempt (line 311) to then try a different method of finding the service (which succeeds if you see no log of the AxisFault on line 316). The log entry is created because a ConfigurationException logs itself (at DEBUG level) on creation (questionable practice, imho). To avoid this misleading log entry you'll want to add this to your log4j.properties file:

log4j.logger.org.apache.axis.ConfigurationException = INFO

FrontPage/Axis/DealingWithCommonExceptions (last edited 2009-09-20 22:48:29 by localhost)