On 6/12/07, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:
Amila Suriarachchi wrote:
>
>
> On 6/12/07, *Dennis Sosnoski* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> I think it would be much cleaner to fix the code generation
> handling, so
> that the same exception can be used by multiple methods. Why
> complicate
> the interface with multiple classes for the same data?
>
> So my response to Glen's questions would be that the message name
> should
> be based on just the Exception type, and the generated exception
class
> should just use the message name. If this were done correctly it
would
> also eliminate the need to have a data object for each
> Fault/Exception
> class, which I think is one of the more awkward parts of the current
> Axis2 API - you need to use constructs like:
>
>
> As I understood here you are suggesting to use one message for the
> same exception classes in
> java2wsdl.
Yes.
>
> AddDuplicateFaultException fault = new
> AddDuplicateFaultException("Duplicate book");
> fault.setFaultMessage(new AddDuplicateFaultData());
> throw fault;
>
> where you have to first create the exception, then create a data
> object
> and set it on the exception, and only then throw the exception.
> This is
> a very counterintuitive way of doing things (especially when
> there's no
> actual data associated with the exception/fault),
>
>
> What you are suggesting here? Adding the detail message to the
> constructor?
I'm showing what's required by the current generated code. If there is a
meaningful message data object it would certainly be useful to have a
constructor that takes that object as a parameter, but the main problem
is that the message data object is always required by the current code.
>
> but if you forget to
> set the required message object you'll get a NPE when Axis2 tries to
> convert the exception to a fault.
>
>
> I think this is an Axis2 bug since Detail element is optional.
Sounds good to me. But here's the current message receiver code
generated for ADB (the others are essentially the same, as I remember):
} catch (AddDuplicateFaultException e) {
msgContext.setProperty(org.apache.axis2.Constants.FAULT_NAME,
"addDuplicate");
org.apache.axis2.AxisFault f = createAxisFault(e);
f.setDetail(toOM(e.getFaultMessage(), false));
throw f;
}
yes, this is a bug and we have to add a null check . I'll do this.
Note that the message data object has to be present and non-null for
this code to work (the toOM call, in particular). The client-side code
also requires a message data object to be present. The Fault element
name is used to determine the type of exception to be generated, but
then the element is also passed to the fromOM method to create the
associated message data object. So the current requirement of a unique
message data object for each exception type is built into the code
generation on both client and server sides. This should be changed so
that there doesn't need to be a message data object type for faults with
no content (corresponding to an exception that only provides an error
message), which in WSDL terms would be:
<element name="empty">
<complexType>
<sequence/>
</complexType>
</element>
...
<wsdl:message name="emptyFault">
<wsdl:part element="wns:empty" name="fault"/>
</wsdl:message>
Right now, this creates an "Empty" class as the message data object for
the generated exception class. Instead, we should just have the
Fault/Exception class.
why you want to remove the faultmessage property. In this way we loose the
element detial
given in the message. And also then user will not be able to send the fault
message (as describe in the wsdl) if he required as well.
- Dennis
--
Dennis M. Sosnoski
SOA and Web Services in Java
Axis2 Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Amila Suriarachchi,
WSO2 Inc.
