When running Java service or EJB service operations, Java exceptions must be mapped to Web services faults that are declared in the service's WSDL interface. You can declare service operation faults by declaring equivalent Java exceptions in the Java method throws clause, however, the exception type must be supported by the Java-to-WSDL type mappings. The rest of this topic describes requirements for exceptions thrown by Java methods that are exposed in the service interface for a Java or EJB service.
Service interface methods cannot throw any of the following exceptions:
org.apache.axis.AxisFault
Checked exceptions from packages that start with java. or javax.
Checked exceptions with class names that start ArrayOf
Exceptions in the default Java package, that is, exception classes that are not declared to belong to a named package.
If an exception has at least one public constructor, it must have a public default constructor, that is, a public constructor that takes no arguments.
The exception can be a JavaBean (or a class that satisfies all JavaBean requirements except implementing the java.io.Serializable interface). If so, it must have getter and setter methods to translate all instance properties to and from the XML serialized form, and the property datatypes must satisfy the requirements for Java or EJB service input and output parameters. Instance data is serialized to XML by calling each getter method and translating the result to XML. Instance data is deserialized from XML by calling the default constructor and calling each setter method with data translated from XML.
If the exception is not a JavaBean, its public fields must use datatypes that are valid for the Java or EJB service. In this case, instance data is serialized to XML by reading the value of each public field and converting it to XML. Instance data is deserialized from XML by calling the default constructor and setting each public field to the value read from XML.
Example: An exception following the JavaBeans property pattern
This exception might be thrown to indicate an expired customer account. It follows the JavaBeans pattern with methods to get and set a java.util.Calendar property:
package com.mycompany.myorganization; import java.util.GregorianCalendar; import java.util.Calendar; public class AccountExpiredException extends Exception { private java.util.Calendar whenExpired; public java.util.Calendar getExpiryDate() { return whenExpired; } public void setExpiryDate(java.util.Calendar newDate) { whenExpired = newDate; } public AccountExpiredException() { ; } }
Example: An exception with public fields
This exception is similar to the JavaBeans example, but rather than providing property getter and setter methods, it simply has a public field to represent the account expiration date:
package com.mycompany.myorganization; public class ExpiredAccountException extends Exception { public java.util.Calendar whenExpired; public ExpiredAccountException() { ; } }
Send your feedback on this help topic to Sybase Tech Pubs: pubs@sybase.com