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]> 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]> 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 > > 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";> > <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] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Amila Suriarachchi, WSO2 Inc.
