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 Jarek Gawor <ga...@mcs.anl.gov> on 2004/09/03 07:06:07 UTC
RE: WS-I testing: warnings about faultcode
> -----Original Message-----
> From: Ias [mailto:iasandcb@hotmail.com]
> Sent: Monday, August 30, 2004 6:27 PM
> To: axis-dev@ws.apache.org
> Subject: RE: WS-I testing: warnings about faultcode
>
>
> > I was running the WS-I BP validation tools against the wire
> > messages produced by Axis on our software. Two assertion
> > warnings related to faultcode were raised:
> >
> > WSI1031: A soap:Fault element makes use of the SOAP 1.1 dot
> notation.
> >
> > WSI1302: The soap:faultcode value in the soap:Fault element
> > of the response message is not one of: VersionMismatch,
> > MustUnderstand, Client, Server, or is not qualified by a namespace.
> >
> > The faultcode of the fault was (which is generated by default
> > by Axis):
> >
> > <faultcode>soapenv:Server.generalException</faultcode>
> >
> > I'm wondering what people think about fixing this in Axis
> > since it is a minor issue and it does not cause the
> > validation to fail.
>
> Thanks for raising up the issue. Here's my ideas on it:
>
> The one approach is changing
>
> public static final String FAULT_SERVER_GENERAL =
>
> "Server.generalException";
>
> public static final String FAULT_SERVER_USER =
>
> "Server.userException";
>
> in Constants to
>
> public static final String FAULT_SERVER_GENERAL =
> "Server";
>
> public static final String FAULT_SERVER_USER =
> "Server";
>
> i.e. making no difference between general exceptions and user
> exceptions. This approach is fairly simple :-)
>
> The other approach is related to AxisFault's
> setFaultCodeAsString, which simply makes the namespace of a
> give fault code the URI of the SOAP envelope containing the
> fault. First, we need to change those constants above to
>
> public static final String FAULT_SERVER_GENERAL =
>
> "ServerGeneralException";
>
> public static final String FAULT_SERVER_USER =
>
> "ServerUserException";
>
>
> , then change
>
> public void setFaultCodeAsString(String code) {
> SOAPConstants soapConstants =
> MessageContext.getCurrentContext() == null ?
>
> SOAPConstants.SOAP11_CONSTANTS :
>
> MessageContext.getCurrentContext().getSOAPConstants();
>
> faultCode = new QName(soapConstants.getEnvelopeURI(), code);
> }
>
> to
>
> public void setFaultCodeAsString(String code) {
> SOAPConstants soapConstants =
> MessageContext.getCurrentContext() == null ?
>
> SOAPConstants.SOAP11_CONSTANTS :
>
> MessageContext.getCurrentContext().getSOAPConstants();
>
> if (code.equals("VersionMismatch") ||
> code.equals("MustUnderstand") ||
> code.equals("Client") ||
> code.equals("Server")) {
> faultCode = new QName(soapConstants.getEnvelopeURI(), code);
> } else {
> faultCode = new QName(Constants.NS_URI_AXIS, code);
> }
>
> I think adopting both ideas could be better for clear and
> safe server fault codes.
I like the combination of two. I would suggest changing the
FAULT_SERVER_GENERAL to "Server" and FAULT_SERVER_USER to
"ServerUserException" and adopting the suggested setFaultCodeAsString()
method.
I'll go ahead and make the changes if there are no objections to these
modifications.
Jarek
Re: WS-I testing: warnings about faultcode
Posted by Davanum Srinivas <da...@gmail.com>.
+1 - go for it.
-- dims
On Fri, 3 Sep 2004 01:06:07 -0400, Jarek Gawor <ga...@mcs.anl.gov> wrote:
>
>
> > -----Original Message-----
> > From: Ias [mailto:iasandcb@hotmail.com]
> > Sent: Monday, August 30, 2004 6:27 PM
> > To: axis-dev@ws.apache.org
> > Subject: RE: WS-I testing: warnings about faultcode
> >
> >
> > > I was running the WS-I BP validation tools against the wire
> > > messages produced by Axis on our software. Two assertion
> > > warnings related to faultcode were raised:
> > >
> > > WSI1031: A soap:Fault element makes use of the SOAP 1.1 dot
> > notation.
> > >
> > > WSI1302: The soap:faultcode value in the soap:Fault element
> > > of the response message is not one of: VersionMismatch,
> > > MustUnderstand, Client, Server, or is not qualified by a namespace.
> > >
> > > The faultcode of the fault was (which is generated by default
> > > by Axis):
> > >
> > > <faultcode>soapenv:Server.generalException</faultcode>
> > >
> > > I'm wondering what people think about fixing this in Axis
> > > since it is a minor issue and it does not cause the
> > > validation to fail.
> >
> > Thanks for raising up the issue. Here's my ideas on it:
> >
> > The one approach is changing
> >
> > public static final String FAULT_SERVER_GENERAL =
> >
> > "Server.generalException";
> >
> > public static final String FAULT_SERVER_USER =
> >
> > "Server.userException";
> >
> > in Constants to
> >
> > public static final String FAULT_SERVER_GENERAL =
> > "Server";
> >
> > public static final String FAULT_SERVER_USER =
> > "Server";
> >
> > i.e. making no difference between general exceptions and user
> > exceptions. This approach is fairly simple :-)
> >
> > The other approach is related to AxisFault's
> > setFaultCodeAsString, which simply makes the namespace of a
> > give fault code the URI of the SOAP envelope containing the
> > fault. First, we need to change those constants above to
> >
> > public static final String FAULT_SERVER_GENERAL =
> >
> > "ServerGeneralException";
> >
> > public static final String FAULT_SERVER_USER =
> >
> > "ServerUserException";
> >
> >
> > , then change
> >
> > public void setFaultCodeAsString(String code) {
> > SOAPConstants soapConstants =
> > MessageContext.getCurrentContext() == null ?
> >
> > SOAPConstants.SOAP11_CONSTANTS :
> >
> > MessageContext.getCurrentContext().getSOAPConstants();
> >
> > faultCode = new QName(soapConstants.getEnvelopeURI(), code);
> > }
> >
> > to
> >
> > public void setFaultCodeAsString(String code) {
> > SOAPConstants soapConstants =
> > MessageContext.getCurrentContext() == null ?
> >
> > SOAPConstants.SOAP11_CONSTANTS :
> >
> > MessageContext.getCurrentContext().getSOAPConstants();
> >
> > if (code.equals("VersionMismatch") ||
> > code.equals("MustUnderstand") ||
> > code.equals("Client") ||
> > code.equals("Server")) {
> > faultCode = new QName(soapConstants.getEnvelopeURI(), code);
> > } else {
> > faultCode = new QName(Constants.NS_URI_AXIS, code);
> > }
> >
> > I think adopting both ideas could be better for clear and
> > safe server fault codes.
>
> I like the combination of two. I would suggest changing the
> FAULT_SERVER_GENERAL to "Server" and FAULT_SERVER_USER to
> "ServerUserException" and adopting the suggested setFaultCodeAsString()
> method.
> I'll go ahead and make the changes if there are no objections to these
> modifications.
>
> Jarek
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: WS-I testing: warnings about faultcode
Posted by Steve Loughran <st...@apache.org>.
Nelson Minar wrote:
>>Well, strict adherence to standards is fine, but which standards?
>
>
> Speaking as a user, it's clear that BP 1.1 is the target to hit this
> month. SOAP 1.2 maybe some day.
agreed. SOAP1.2 is next month :)
>
>>While I agree with you about switches for every little thing, I do
>>think a single "wsi.bp-compliance" flag might be a good idea, both
>>for Axis 1.X and 2.0.
>
>
> If you do go this route it should be the default behaviour,
> particularly for clients. In my practical experience interop is worse
> than it was three years ago. But WS-I seems to be the only way out of
> the weeds.
we should make it a number, not a bool, for future evolution.
RE: WS-I testing: warnings about faultcode
Posted by Nelson Minar <ne...@monkey.org>.
>Well, strict adherence to standards is fine, but which standards?
Speaking as a user, it's clear that BP 1.1 is the target to hit this
month. SOAP 1.2 maybe some day.
>Strict adherence to SOAP 1.1 (or 1.2 for that matter) certainly
>allows, for instance, SOAP encoding, which is in conflict with strict
>adherence to WS-I BP.
I don't believe WS-I explicitly forbids a web services engine from
supporting SOAP encoding. It just doesn't address it - if you publish
a SOAP encoded service then WS-I isn't going to have anything to say
about how it should work, and that service isn't going to be WS-I
compliant. The underlying engine (Axis) may still be fully BP 1.1.
>While I agree with you about switches for every little thing, I do
>think a single "wsi.bp-compliance" flag might be a good idea, both
>for Axis 1.X and 2.0.
If you do go this route it should be the default behaviour,
particularly for clients. In my practical experience interop is worse
than it was three years ago. But WS-I seems to be the only way out of
the weeds.
RE: WS-I testing: warnings about faultcode
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Sanjiva!
> > My preference is to leave things as they are. If these
> changes do get
> made,
> > please confirm sure that we're correctly setting the codes
> in SOAP 1.2
> > - note that SOAP 1.2 ONLY allows a specific set of top-level fault
> > codes (VersionMismatch, MustUnderstand,
> DataEncodingUnknown, Sender, Receiver).
>
> IMO strict adherance to standards is critical for open source
> projects.
> That means our personal feelings about how overbearing WS-I
> was is not important .. if they say that's what we gotta do, then ...
>
> An alternate is to of course introduce yet another knob to
> say whether to turn this on or not. I don't like making
> everything configurable like
> that: it makes the system complicated and slower.
Well, strict adherence to standards is fine, but which standards? Strict
adherence to SOAP 1.1 (or 1.2 for that matter) certainly allows, for
instance, SOAP encoding, which is in conflict with strict adherence to WS-I
BP.
While I agree with you about switches for every little thing, I do think a
single "wsi.bp-compliance" flag might be a good idea, both for Axis 1.X and
2.0. We will *always* do our best to comply with things like SOAP/WSDL.
We'll additionally limit our behaviour and check WS-I compliance when (and
only when) the flag is on.
--Glen
Re: WS-I testing: warnings about faultcode
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
"Glen Daniels" <gl...@thoughtcraft.com> writes:
>
> Personally, I think WS-I was a little overbearing (as it was in a lot of
> cases, IMHO) when it disallowed the dot notation.
Personally, I agree too.
> My preference is to leave things as they are. If these changes do get
made,
> please confirm sure that we're correctly setting the codes in SOAP 1.2 -
> note that SOAP 1.2 ONLY allows a specific set of top-level fault codes
> (VersionMismatch, MustUnderstand, DataEncodingUnknown, Sender, Receiver).
IMO strict adherance to standards is critical for open source projects.
That means our personal feelings about how overbearing WS-I was is
not important .. if they say that's what we gotta do, then ...
An alternate is to of course introduce yet another knob to say whether
to turn this on or not. I don't like making everything configurable like
that: it makes the system complicated and slower.
Sanjiva.
RE: WS-I testing: warnings about faultcode
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi folks:
Personally, I think WS-I was a little overbearing (as it was in a lot of
cases, IMHO) when it disallowed the dot notation. The dot notation for SOAP
1.1 allows, to some extent, the same kind of fault code layering that SOAP
1.2 does. You can know, even if you don't understand what a
"generalException" is, that the fault was caused by the Server. This is
useful, for instance, when you want to figure out if resending the message
might have a chance of succeeding - if you see a "Client" fault, you know
that you did something wrong, and don't bother resending without changes.
If you see a "Server" fault, though, you might wait a while and try
again....
My preference is to leave things as they are. If these changes do get made,
please confirm sure that we're correctly setting the codes in SOAP 1.2 -
note that SOAP 1.2 ONLY allows a specific set of top-level fault codes
(VersionMismatch, MustUnderstand, DataEncodingUnknown, Sender, Receiver).
--Glen
> -----Original Message-----
> From: Ias [mailto:iasandcb@hotmail.com]
> Sent: Friday, September 03, 2004 4:50 AM
> To: axis-dev@ws.apache.org
> Subject: RE: WS-I testing: warnings about faultcode
>
> I'm +1 for your way :-)
>
> Regards,
>
> Ias
>
> > -----Original Message-----
> > From: Jarek Gawor [mailto:gawor@mcs.anl.gov]
> > Sent: Friday, September 03, 2004 6:06 AM
> > To: axis-dev@ws.apache.org
> > Subject: RE: WS-I testing: warnings about faultcode
> >
> > > -----Original Message-----
> > > From: Ias [mailto:iasandcb@hotmail.com]
> > > Sent: Monday, August 30, 2004 6:27 PM
> > > To: axis-dev@ws.apache.org
> > > Subject: RE: WS-I testing: warnings about faultcode
> > >
> > >
> > > > I was running the WS-I BP validation tools against the
> > wire messages
> > > > produced by Axis on our software. Two assertion warnings
> > related to
> > > > faultcode were raised:
> > > >
> > > > WSI1031: A soap:Fault element makes use of the SOAP 1.1 dot
> > > notation.
> > > >
> > > > WSI1302: The soap:faultcode value in the soap:Fault
> > element of the
> > > > response message is not one of: VersionMismatch,
> MustUnderstand,
> > > > Client, Server, or is not qualified by a namespace.
> > > >
> > > > The faultcode of the fault was (which is generated by default by
> > > > Axis):
> > > >
> > > > <faultcode>soapenv:Server.generalException</faultcode>
> > > >
> > > > I'm wondering what people think about fixing this in Axis
> > since it
> > > > is a minor issue and it does not cause the validation to fail.
> > >
> > > Thanks for raising up the issue. Here's my ideas on it:
> > >
> > > The one approach is changing
> > >
> > > public static final String FAULT_SERVER_GENERAL =
> > >
> > > "Server.generalException";
> > >
> > > public static final String FAULT_SERVER_USER =
> > >
> > > "Server.userException";
> > >
> > > in Constants to
> > >
> > > public static final String FAULT_SERVER_GENERAL =
> > > "Server";
> > >
> > > public static final String FAULT_SERVER_USER =
> > > "Server";
> > >
> > > i.e. making no difference between general exceptions and user
> > > exceptions. This approach is fairly simple :-)
> > >
> > > The other approach is related to AxisFault's
> setFaultCodeAsString,
> > > which simply makes the namespace of a give fault code the
> > URI of the
> > > SOAP envelope containing the fault. First, we need to
> change those
> > > constants above to
> > >
> > > public static final String FAULT_SERVER_GENERAL =
> > >
> > > "ServerGeneralException";
> > >
> > > public static final String FAULT_SERVER_USER =
> > >
> > > "ServerUserException";
> > >
> > >
> > > , then change
> > >
> > > public void setFaultCodeAsString(String code) {
> > > SOAPConstants soapConstants =
> > > MessageContext.getCurrentContext() == null ?
> > >
> > > SOAPConstants.SOAP11_CONSTANTS :
> > >
> > > MessageContext.getCurrentContext().getSOAPConstants();
> > >
> > > faultCode = new
> QName(soapConstants.getEnvelopeURI(), code);
> > > }
> > >
> > > to
> > >
> > > public void setFaultCodeAsString(String code) {
> > > SOAPConstants soapConstants =
> > > MessageContext.getCurrentContext() == null ?
> > >
> > > SOAPConstants.SOAP11_CONSTANTS :
> > >
> > > MessageContext.getCurrentContext().getSOAPConstants();
> > >
> > > if (code.equals("VersionMismatch") ||
> > > code.equals("MustUnderstand") ||
> > > code.equals("Client") ||
> > > code.equals("Server")) {
> > > faultCode = new QName(soapConstants.getEnvelopeURI(), code);
> > > } else {
> > > faultCode = new QName(Constants.NS_URI_AXIS, code);
> > > }
> > >
> > > I think adopting both ideas could be better for clear and
> > safe server
> > > fault codes.
> >
> > I like the combination of two. I would suggest changing the
> > FAULT_SERVER_GENERAL to "Server" and FAULT_SERVER_USER to
> > "ServerUserException" and adopting the suggested
> > setFaultCodeAsString() method.
> > I'll go ahead and make the changes if there are no
> objections to these
> > modifications.
> >
> > Jarek
> >
> >
> >
> >
>
>
RE: WS-I testing: warnings about faultcode
Posted by Ias <ia...@hotmail.com>.
I'm +1 for your way :-)
Regards,
Ias
> -----Original Message-----
> From: Jarek Gawor [mailto:gawor@mcs.anl.gov]
> Sent: Friday, September 03, 2004 6:06 AM
> To: axis-dev@ws.apache.org
> Subject: RE: WS-I testing: warnings about faultcode
>
> > -----Original Message-----
> > From: Ias [mailto:iasandcb@hotmail.com]
> > Sent: Monday, August 30, 2004 6:27 PM
> > To: axis-dev@ws.apache.org
> > Subject: RE: WS-I testing: warnings about faultcode
> >
> >
> > > I was running the WS-I BP validation tools against the
> wire messages
> > > produced by Axis on our software. Two assertion warnings
> related to
> > > faultcode were raised:
> > >
> > > WSI1031: A soap:Fault element makes use of the SOAP 1.1 dot
> > notation.
> > >
> > > WSI1302: The soap:faultcode value in the soap:Fault
> element of the
> > > response message is not one of: VersionMismatch, MustUnderstand,
> > > Client, Server, or is not qualified by a namespace.
> > >
> > > The faultcode of the fault was (which is generated by default by
> > > Axis):
> > >
> > > <faultcode>soapenv:Server.generalException</faultcode>
> > >
> > > I'm wondering what people think about fixing this in Axis
> since it
> > > is a minor issue and it does not cause the validation to fail.
> >
> > Thanks for raising up the issue. Here's my ideas on it:
> >
> > The one approach is changing
> >
> > public static final String FAULT_SERVER_GENERAL =
> >
> > "Server.generalException";
> >
> > public static final String FAULT_SERVER_USER =
> >
> > "Server.userException";
> >
> > in Constants to
> >
> > public static final String FAULT_SERVER_GENERAL =
> > "Server";
> >
> > public static final String FAULT_SERVER_USER =
> > "Server";
> >
> > i.e. making no difference between general exceptions and user
> > exceptions. This approach is fairly simple :-)
> >
> > The other approach is related to AxisFault's setFaultCodeAsString,
> > which simply makes the namespace of a give fault code the
> URI of the
> > SOAP envelope containing the fault. First, we need to change those
> > constants above to
> >
> > public static final String FAULT_SERVER_GENERAL =
> >
> > "ServerGeneralException";
> >
> > public static final String FAULT_SERVER_USER =
> >
> > "ServerUserException";
> >
> >
> > , then change
> >
> > public void setFaultCodeAsString(String code) {
> > SOAPConstants soapConstants =
> > MessageContext.getCurrentContext() == null ?
> >
> > SOAPConstants.SOAP11_CONSTANTS :
> >
> > MessageContext.getCurrentContext().getSOAPConstants();
> >
> > faultCode = new QName(soapConstants.getEnvelopeURI(), code);
> > }
> >
> > to
> >
> > public void setFaultCodeAsString(String code) {
> > SOAPConstants soapConstants =
> > MessageContext.getCurrentContext() == null ?
> >
> > SOAPConstants.SOAP11_CONSTANTS :
> >
> > MessageContext.getCurrentContext().getSOAPConstants();
> >
> > if (code.equals("VersionMismatch") ||
> > code.equals("MustUnderstand") ||
> > code.equals("Client") ||
> > code.equals("Server")) {
> > faultCode = new QName(soapConstants.getEnvelopeURI(), code);
> > } else {
> > faultCode = new QName(Constants.NS_URI_AXIS, code);
> > }
> >
> > I think adopting both ideas could be better for clear and
> safe server
> > fault codes.
>
> I like the combination of two. I would suggest changing the
> FAULT_SERVER_GENERAL to "Server" and FAULT_SERVER_USER to
> "ServerUserException" and adopting the suggested
> setFaultCodeAsString() method.
> I'll go ahead and make the changes if there are no objections
> to these modifications.
>
> Jarek
>
>
>
>