RE: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)

[Tom Jordahl]

I have read the complete thread and I know I am chiming in a little
late.

One common exception type generated for each Schema element is clearly
the optimal mapping for Java.

If I declare method1 and method2 to throw the same exception in the
server side, I expect WSDL2Java (or whatever wrong name you guys picked
:-) to generate a single Exception on the client side for this service.

The exceptions should be named after the element types.  Axis 1.x did it
this way, and Axis2 should too.


Tom Jordahl
Adobe Server Development 

-Original Message-
From: Glen Daniels [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 11, 2007 5:54 PM
To: Axis-Dev
Subject: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)

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):

http://ns";>
   
 ...
   

...

   

...

   
   
   


   
   
   


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]

Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)

[Dennis Sosnoski]

Amila Suriarachchi wrote:



On 6/12/07, *Dennis Sosnoski* <[EMAIL PROTECTED] 
> wrote:


...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:

  

  

  
  ...

  

  

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.


I'm only talking about the case where there's no content for the Fault 
element. If there's no content, there's no reason to have a message data 
object class for that Fault.


 - Dennis

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)

[Amila Suriarachchi]

On 6/12/07, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:


Amila Suriarachchi wrote:
>
>
> On 6/12/07, *Dennis Sosnoski* <[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:

  

  

  
  ...

  

  

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.

Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)

[Dennis Sosnoski]

Amila Suriarachchi wrote:



On 6/12/07, *Dennis Sosnoski* <[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;
   }

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:

 

   
 
   
 
 ...

 
   
 

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.


 - 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]

Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)

[Amila Suriarachchi]

On 6/12/07, Dennis Sosnoski <[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.

   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?

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.


 - 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]
> > 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):
> >
> > http://ns ">
> >
> >  ...
> >
> > 
> > ...
> > 
> >
> > 
> > ...
> > 
> >
> >
> >
> > 
> > 
> >
> >
> >
> > 
> >
> > 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).
> 

Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)

[Peter Danielsen]

In my case, I was using the HTTP binding of WSDL2 and one operation
had several faults with the same type.  The way to distinguish them
was by looking at the HTTP status code, as specified in the 
section.  In the patch I submitted there were different classes for
each fault and those classes were wrappers for the "typed" data.  I
made a distinction between the fault and its type.  The fault became
the exception and the type was the data contained in the exception.
If another operation had the same faults, they'd use the same
generated classes, so there weren't a lot of nearly identical looking
classes being generated.

Hope this helps,

Peter

On 6/11/07, Dennis Sosnoski <[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:

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]
> > 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):
> >
> > http://ns ">
> >
> >  ...
> >
> > 
> > ...
> > 
> >
> > 
> > ...
> > 
> >
> >
> >
> > 
> > 
> >
> >
> >
> > 
> >
> > 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)
> >

Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)

[Dennis Sosnoski]

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] 
> 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):
>
> http://ns ">
>
>  ...
>
> 
> ...
> 
>
> 
> ...
> 
>
>
>
> 
> 
>
>
>
> 
>
> 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 appre

Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)

[Amila Suriarachchi]

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):
>
> http://ns";>
>
>  ...
>
> 
> ...
> 
>
> 
> ...
> 
>
>
>
> 
> 
>
>
>
> 
>
> 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.

Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)

[Peter Danielsen]

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):

http://ns";>
   
 ...
   

...

   

...

   
   
   


   
   
   


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]