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 <[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]
> <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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
