You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Glen Daniels <gl...@thoughtcraft.com> on 2007/06/11 23:53:44 UTC
[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):
<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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)
Posted by Peter Danielsen <wi...@gmail.com>.
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 <binding>
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 <dm...@sosnoski.com> 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* <wiscal@gmail.com
> > <ma...@gmail.com>> 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 <glen@thoughtcraft.com
> > <ma...@thoughtcraft.com>> 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: axis-dev-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > <ma...@ws.apache.org>
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > <ma...@ws.apache.org>
> >
> >
> >
> >
> > --
> > Amila Suriarachchi,
> > WSO2 Inc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Amila Suriarachchi wrote:
>
>
> On 6/12/07, *Dennis Sosnoski* <dms@sosnoski.com
> <ma...@sosnoski.com>> 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:
>
> <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.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)
Posted by Amila Suriarachchi <am...@gmail.com>.
On 6/12/07, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>
> Amila Suriarachchi wrote:
> >
> >
> > On 6/12/07, *Dennis Sosnoski* <dms@sosnoski.com
> > <ma...@sosnoski.com>> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Amila Suriarachchi wrote:
>
>
> On 6/12/07, *Dennis Sosnoski* <dms@sosnoski.com
> <ma...@sosnoski.com>> 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:
<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.
- 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)
Posted by Amila Suriarachchi <am...@gmail.com>.
On 6/12/07, Dennis Sosnoski <dm...@sosnoski.com> 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* <wiscal@gmail.com
> > <ma...@gmail.com>> 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 <glen@thoughtcraft.com
> > <ma...@thoughtcraft.com>> 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: axis-dev-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > <ma...@ws.apache.org>
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > <ma...@ws.apache.org>
> >
> >
> >
> >
> > --
> > Amila Suriarachchi,
> > WSO2 Inc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
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* <wiscal@gmail.com
> <ma...@gmail.com>> 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 <glen@thoughtcraft.com
> <ma...@thoughtcraft.com>> 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: axis-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> <ma...@ws.apache.org>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)
Posted by Amila Suriarachchi <am...@gmail.com>.
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 <wi...@gmail.com> 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 <gl...@thoughtcraft.com> 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: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)
Posted by Peter Danielsen <wi...@gmail.com>.
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 <gl...@thoughtcraft.com> 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: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
RE: [axis2] WSDL2Java / Java2WSDL and Faults (PLEASE CHIME IN?)
Posted by Tom Jordahl <tj...@adobe.com>.
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:glen@thoughtcraft.com]
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):
<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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org