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:
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), 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.
- 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
Amila Suriarachchi wrote:
good point. so this shows that we have to use the
1) approach for the wsdl2java. i.e we have to generate a sperate class
for each and every message.
I'll go through your patch.
Amila.
On 6/11/07, *Peter Danielsen* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Glen,
Another relevant JIRA to consider in this discussion is 2702 which
covers another WSDL2Java problem case: when an operation has multiple
faults of the same type. It's based on my experience with WSDL2. I
included a test WSDL2 file and a patch in the JIRA. Keith Chapman
annotated the JIRA to say it's also a problem with WSDL1. It would be
great to get this resolved soon.
Please include this in your discussion.
Peter
On 6/11/07, Glen Daniels <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
> Hi folks!
>
> We're here at the hackathon, and these two issues came up:
>
> https://issues.apache.org/jira/browse/AXIS2-2778
> https://issues.apache.org/jira/browse/AXIS2-2792
<https://issues.apache.org/jira/browse/AXIS2-2792>
>
> They both revolve around how to map faults to/from WSDL, and
we'd like
> some input. Consider starting with the following class:
>
> package ns;
> class Service {
> void method1(void) throws CustomException {};
> void method2(void) throws CustomException {};
> }
>
> You'll end up with a WSDL that looks like (paraphrased):
>
> <schema targetNamespace="http://ns <http://ns>">
> <element name="CustomException">
> ...
> </element>
> </schema>
> ...
> <message name="{MSG}">
> <element name="ns:CustomException"/>
> </message>
> ...
> <operation name="method1">
> <input/>
> <output>
> <fault message="{MSG}"/>
> </operation>
> <operation name="method2">
> <input/>
> <output>
> <fault message="{MSG}"/>
> </operation>
>
> I've left MSG as a variable because that's the real question
here. In
> particular, should MSG be based on a) just the Exception type (i.e.
> "CustomException"), or b) the method (i.e. "method1Fault"). If
we go
> with (a), then we would generate only ONE message for both of
the above
> operations' faults and share it. If we go with (b) we would
generate
> TWO separate messages in the WSDL, both referring to the same
element.
>
>
>
> Now the second part revolves around how to behave when running
WSDL2Java
> from WSDL. Should we generate:
>
> 1)
> class {MSG} extends RemoteException {
> }
>
> (i.e. use the message name regardless, meaning we'd generate
multiple
> exception types for multiple messages sharing an element)
>
> or
>
> 2)
> class CustomException extends RemoteException {
> }
>
> (i.e. use the element type regardless of message name)
>
> Currently, for Java2WSDL we use approach (b), generating message
names
> based on the method name. For WSDL2Java we use approach (1),
generating
> fault types based on the message name. If multiple messages
share the
> same element, we'll all have them use the same fault class
(based on the
> message name, not the element name).
>
> The current approach is somewhat inconsistent and confusing. We
should
> EITHER have WSDL2Java generate one fault per message (if the
faults are
> named after message names), letting the Java classes be
different even
> though the elements are the same, OR have it dig in to the
element and
> name the faults after the element types, and sharing the fault type
> among any operation that uses that element in a fault message.
>
> Thoughts and comments appreciated.
>
> Thanks,
> --Glen
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
--
Amila Suriarachchi,
WSO2 Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
