← Prev in month
← Prev in thread
Next in thread →
Next in month →
Fw: Fault Messages
Forwarding private comments for basis of references. Rich Thompson ----- Forwarded by Rich Thompson/Watson/IBM on 07/09/2003 03:10 PM ----- Stephan Laertz@IBMDE 05/22/2003 10:36 AM To: David Ward <> cc: Andre Kramer <>, Rich Thompson/Watson/IBM@IBMUS, Richard Jacob/Germany/IBM@IBMDE From: Stephan Laertz/Germany/IBM@IBMDE Subject: Re: Fault MessagesLink The specific codes from the spec do not have a dot in their names. Only the accumulation of spefic code scoped by the top level code. But since this a potential for confusions we could state something like that 2) The SOAP faultcode SHOULD be set to the WSRP specific code scoped by the top level code being raised, namespace qualified to be in the "urn:oasis:names:tc:wsrp:v1:types" namespace. MfG / Best regards, Stephan Laertz -------------------------------------------------------------------------- WebSphere Portal Server Development IBM Deutschland Entwicklung GmbH Schoenaicher Str. 220, 71032 Boeblingen Phone: +49 7031 16-3313 (*120 3313) Email: --------------------------------------------------------------------------- David Ward <> 22.05.2003 16:04 To: Andre Kramer <> cc: Stephan Laertz/Germany/IBM@IBMDE, Richard Jacob/Germany/IBM@IBMDE, Rich Thompson/Watson/IBM@IBMUS Subject: Re: Fault Messages RWould you consider giving a concrete example for 2) e.g. <faultcode xmlns:types="urn:oasis:names:tc:wsrp:v1:types">types:Interface.InvalidCookie</faultcode>? Also, I think the last sentence of 3) is confusing, as the fault "codes" have dots in them, but the WSDL element names don't. Regards Dave Andre Kramer wrote: Yes, I believe that maximizes interoperability. We should still verify this by testing, but here is a recap of the suggested spec errata / enhancements. With JAX-RPC bug fixing, we can relax the "MUST be the only content" and ensure the "fault code SHOULD be set to". Chapter 13 1) P76 / 4 old text: WSDL defines fault codes to be strings using "." as a delimiter to scope the error codes. new text: This spec defines fault codes to be strings using "." as a delimiter to scope the error codes. 2) P74 before table new text: The SOAP faultcode SHOULD be set to the WSRP error code being raised, namespace qualified to be in the "urn:oasis:names:tc:wsrp:v1:types" namespace. 3) P74 after (2) new text: The SOAP fault's detail MUST contain the corresponding namespaced fault element from the WSRP v1 WSDL. In order to maximize interoperability, this element MUST be the only content in the fault detail element. Note that the WSRP WSDL's fault element names are the specific codes from the following table with "Fault" appended. regards, Andre -----Original Message----- From: David Ward [mailto:] Sent: 22 May 2003 14:14 To: Andre Kramer Cc: 'Stephan Laertz'; 'Richard Jacob' Subject: Re: Fault Messages So the detail part is going to be a MUST (must contain the correctly namespaced element and nothing else) and the faultcode part is going to be a SHOULD, meaning that ideally we should have <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns0="urn:oasis:names:tc:wsrp:v1:types"> <env:Body> <env:Fault xsi:type="env:Fault"> <faultcode>ns0:Interface.InvalidCookie</faultcode> <faultstring>a meaningful description</faultstring> <detail> <ns0:InvalidCookieFault/> </detail> </env:Fault> </env:Body> </env:Envelope> but we can get away with: <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns0="urn:oasis:names:tc:wsrp:v1:types"> <env:Body> <env:Fault xsi:type="env:Fault"> <faultcode>env:Server</faultcode> <faultstring>oracle.webdb.wsrp.InvalidCookie</faultstring> <detail> <ns0:InvalidCookieFault/> </detail> </env:Fault> </env:Body> </env:Envelope> Correct? Regards Dave Andre Kramer wrote: I just went back to the wsdl and the fault *element* is actually called InitCookieFault. Both the fault's complexType and element end in "Fault" and the message part references the element, so I was wrong! It is probably better not to make an wsdl changes at this stage so let's go with <detail> <xyz:InvalidCookieFault/></detail>? regards, Andre -----Original Message----- From: Stephan Laertz [mailto:] Sent: 22 May 2003 13:21 To: Andre Kramer Cc: Andre Kramer; 'David Ward'; 'Richard Jacob' Subject: RE: Fault Messages I managed to produce fault messages like this. <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <soapenv:Fault> <faultcode xmlns:ns1="urn:oasis:names:tc:wsrp:v1:types">ns1:Security.InvalidRegistration</faultcode> <faultstring>Consumer supplies a registrationHandle/registrationState pair that is not recognized by the Producer.</faultstring> <detail> <ns2:InvalidRegistration xmlns:ns2="urn:oasis:names:tc:wsrp:v1:types"/> </detail> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope> But without renaming, in particular omitting the suffix "Fault " from the name of the fault types in the schema definition Axis will not deserialize the exception since it seems that axis relies on the first detail child element for deserializing. MfG / Best regards, Stephan Laertz -------------------------------------------------------------------------- WebSphere Portal Server Development IBM Deutschland Entwicklung GmbH Schoenaicher Str. 220, 71032 Boeblingen Phone: +49 7031 16-3313 (*120 3313) Email: --------------------------------------------------------------------------- Andre Kramer <> 22.05.2003 13:21 To: Andre Kramer <>, Stephan Laertz/Germany/IBM@IBMDE cc: "'David Ward'" <>, Richard Jacob/Germany/IBM@IBMDE Subject: RE: Fault Messages Below is the fault that I now create and catch with .NET. If this is OK with us all, we should get an errata (more an interop clarification) into the spec and try it with the IBM producer? regards, Andre <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body> <soap:Fault> <faultcode xmlns:q0="urn:oasis:names:tc:wsrp:v1:types">q0:Interface.InvalidCookie</faultcode> <faultstring>System.Web.Services.Protocols.SoapException: NETlets at NETlet.NETletServer.MarkupServer.getMarkup(getMarkup getMarkup1, HttpContext Context, HttpSessionState Session) in c:\inetpub\wwwroot\netlets\netletserver.cs:line 1447 at NETlet.NETletService.WSRP_v1_Markup_Binding_SOAP.getMarkup(getMarkup getMarkup1) in C:\Inetpub\wwwroot\NETlets\NETletsService.cs:line 89</faultstring> <faultactor>urn:citrix.com/netlets</faultactor> <detail> <InvalidCookie xmlns="urn:oasis:names:tc:wsrp:v1:types" /> </detail> </soap:Fault> </soap:Body> </soap:Envelope> -----Original Message----- From: Andre Kramer Sent: 22 May 2003 11:58 To: 'Stephan Laertz'; Andre Kramer Cc: David Ward; Richard Jacob Subject: RE: Fault Messages So that explains the "Fault" ending on the trace you provided! I was going to come back to that... This is a bug and should be reported to Axis? Is it possible to just create a generic SOAP Fault and add a detail node by hand? i.e. not using the fault class generated from the wsdl. -- Andre -----Original Message----- From: Stephan Laertz [mailto:] Sent: 22 May 2003 11:44 To: Andre Kramer Cc: David Ward; Richard Jacob Subject: RE: Fault Messages I haven't found a way to generate fault messages according to your approach with Axis. I have no problem to handle with namespaced and scoped fault codes. But per default Axis always adds an element wich is called after the fault type e,g. <ns2:InvalidRegistrationFault xmlns:ns2="urn:oasis:names:tc:wsrp:v1:types"/> to the detail element. This means I can only have a detail element with the first child element named after the type and at least one other child element which can be any other element I create (e.g. <ns2:InvalidRegistration xmlns:ns2="urn:oasis:names:tc:wsrp:v1:types"/>). Our consumer relies on the first detail element named after the type. MfG / Best regards, Stephan Laertz -------------------------------------------------------------------------- WebSphere Portal Server Development IBM Deutschland Entwicklung GmbH Schoenaicher Str. 220, 71032 Boeblingen Phone: +49 7031 16-3313 (*120 3313) Email: --------------------------------------------------------------------------- Andre Kramer <> 22.05.2003 10:32 To: Stephan Laertz/Germany/IBM@IBMDE, David Ward <>, Andre Kramer <> cc: Richard Jacob/Germany/IBM@IBMDE, Richard Jacob/Germany/IBM@IBMDE Subject: RE: Fault Messages I think this unfortunately satifies neither Dave or I fully. My approach was to define fault codes in our own (wsrp) namespace. This seems to have become confused with soap's custom fault codes. In particular both use a ".". I now think that this is a SHOULD. i.e. the fault code SHOULD be set to the values in Section 13. The mention of WSDL in section 13 is wrong, but I would still use the "." to scope our (namespaced) fault/error codes. I also worry that the <detail> content model is too vague. We should make the messages conform to a strict pattern. Especially for faults like InvalidCookie that we need specific handlers for. My thinking is to add a MUST for interoperability: InvalidCookie and InvalidSession faults MUST contain only one element and this must be called InvalidCookie or Invalid Session (respectively) and MUST be qualified with the "urn:oasis:names:tc:wsrp:v1:types" namespace. I'm going to spend some time this morning checking that I can generate appropriate fault details in .NET. Could you and Dave see if we can meet the above SHOULDs and MUSTs? regards, Andre -----Original Message----- From: Stephan Laertz [mailto:] Sent: 22 May 2003 08:37 To: David Ward; Andre Kramer Cc: Richard Jacob; Richard Jacob Subject: Fault Messages Hello summing up the WS-I statements regarding fault messages, I suggest to handle with fault message like below. R1000 When a MESSAGE contains a soap:Fault element, that element MUST NOT have element children other than faultcode, faultstring, faultactor and detail. > We do not have any other elements. R1002 A RECEIVER MUST accept fault messages that have any number of elements, including zero, appearing as children of the detail element. Such children can be qualified or unqualified. > We should not fail if the <detail> element has any number of children elements. R1003 A RECEIVER MUST accept fault messages that have any number of qualified attributes, including zero, appearing on the detail element. The namespace of such attributes can be anything other than "http://schemas.xmlsoap.org/soap/envelope/". R1031 When a MESSAGE contains a faultcode element the content of that element SHOULD NOT use of the SOAP 1.1 "dot" notation to refine the meaning of the Fault. It is recommended that applications that require custom fault codes either use the SOAP1.1 defined fault codes and supply additional information in the detail element, or that they define these codes in a namespace that is controlled by the specifying authority. > We should not use faultcodes with "dot" notation like Interface.InvalidCookie. Instead use faultcodes that are namespaced. Since they recommend using the detail element and most stacks use the detail element to deserialize exceptions we should additionaly provide the detail element, but allow any number of childrens. What I suggest is to provide both options : a) provide namespaced faultcodes b) have a detail element Example: <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <soapenv:Fault> <faultcode xmlns:ns1="urn:oasis:names:tc:wsrp:v1:types">ns1:InvalidRegistrationFault</faultcode> <faultstring>RegistrationHandle '192.168.0.3_1053551289072_0' invalid on this producer</faultstring> <detail> <ns2:InvalidRegistrationFault xmlns:ns2="urn:oasis:names:tc:wsrp:v1:types"/> <string>RegistrationHandle '192.168.0.3_1053551289072_0' invalid on this producer</string> </detail> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope> MfG / Best regards, Stephan Laertz -------------------------------------------------------------------------- WebSphere Portal Server Development IBM Deutschland Entwicklung GmbH Schoenaicher Str. 220, 71032 Boeblingen Phone: +49 7031 16-3313 (*120 3313) Email: --------------------------------------------------------------------------- David Ward <> 21.05.2003 18:54 To: David Ward <> cc: Andre Kramer <>, Stephan Laertz/Germany/IBM@IBMDE, Peter Fischer3/Germany/IBM@IBMDE, Richard Jacob/Germany/IBM@IBMDE Subject: Re: IBM producer If we're going to start quoting WS-I, here's some ammunition to back up my case. It only suggests custom namespaced faultcodes as an alternative to using the detail element and recommends using the detail element. 4.1.6 SOAP Custom Fault Codes SOAP 1.1 allows custom fault codes to appear inside the faultcode element, through the use of the "dot" notation. Use of this mechanism to extend the meaning of the SOAP 1.1-defined fault codes can lead to namespace collision. Therefore, its use should be avoided, as doing so may cause interoperability issues when the same names are used in the right-hand side of &! nbsp; &nbs! p; the "." (d! ot) to convey different meaning. Instead, the Profile encourages the use of the fault codes defined in SOAP 1.1, along with additional information in the detail element to convey the nature of the Fault. &nbs! p; ! Alternatively, it is acceptable to define custom fault codes in a namespace controlled by the specifying authority. A number of specifications have already defined custom fault codes. Despite this, their use in future specifications is discouraged. Regards Dave David Ward wrote: Another question below.... Andre Kramer wrote: RE: IBM producer David, I believe any valid xml can go into the detail so you may have an JAX-RPC bug. But, Peter & Stephan: a) I expected the wsrp exception name to be carried in the fault code (i.e. in <faultcode> not <exceptionName>)! e.g. using: AxisFault f = new InvalidCookieFault(); f. setFaultCode( new QName("urn:oasis:names:tc:wsrp:v1:types", "Interface.InvalidVookieFault")); throw f; b) I expect the "Interfaces." or "Security." "Top Level" (chapter 13) as well as the "Specific Code" (separated by a '.') in the fault code. JAX-RPC provides no control over the QName used as the fault code - it's always soapenv:Server. Is this a mandatory part of the spec, and if so, why? Won't most stacks deserialize the exception using the typing of the contents of <detail>? I'll try and catch a fault once you have updated the producer. regards, Andre -----Original Message----- From: David Ward mailto:] Sent: 21 May 2003 15:07 To: Stephan Laertz Cc: Andre Kramer; Peter Fischer3; Richard Jacob Subject: Re: IBM producer We still have a problem handling your fault messages. This is what the InvalidCookieFault generated by your producer looks like: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <soapenv:Fault> <faultcode>soapenv:Server.generalException</faultcode> <faultstring>Timeout of HTTP-session. Consumer needs to invoke initCookie() again.</faultstring> <detail> <ns1:InvalidCookieFault xmlns:ns1="urn:oasis:names:tc:wsrp:v1:types"/> <ns2:exceptionName xmlns:ns2="http://xml.apache.org/axis/">oasis.names.tc.wsrp.v1.types.InvalidCookieFault</ns2:exceptionName> </detail> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope> Our problem is the exceptionName element - our serializers don't expect it so it trips them up. Does the WSDL allow this? Thanks David Stephan Laertz wrote: > > I'm glad it finally works. > The only difference between the two display portlets is the fact that > they have different portlet sessions. Besides that they are the same > > MfG / Best regards, > > Stephan Laertz > > -------------------------------------------------------------------------- > WebSphere Portal Server Development > > IBM Deutschland Entwicklung GmbH > Schoenaicher Str. 220, 71032 Boeblingen > Phone: +49 7031 16-3313 (*120 3313) > Email: > --------------------------------------------------------------------------- > > > > > David Ward <> > > 21.05.2003 12:46 > > > To: Stephan Laertz/Germany/IBM@IBMDE > cc: Andre Kramer <>, Richard > Jacob/Germany/IBM@IBMDE, Peter Fischer3/Germany/IBM@IBMDE > Subject: Re: IBM producer > > > > > > > It seems to be working well now. The date portlet seems to change the > cartoons displayed in the display portlet and the action links > increment portlet and application counters. Is there any difference > between the two display portlets? > > Here's what it looks like on Oracle Portal.... > > Screenshot > > Regards > > David > > Stephan Laertz wrote: > > Hello, > > I have fixed most of the problems and it works correctly with our > consumer implementation. > > But still we have a setup problem on our interop machine that keeps > the portlet from connecting to the dilbert site. > For now I've enabled the local mode for portlet 0.2 and 0.3. This > means that clicking a date in the date portlet won't change > the picture displayed by the other portlets. > > David, I could not verify that our producer always sends a session > context with new ID. It does always send a session context but keeping > the ID of > the established session. Even though I have not testet HTTP/1.1 with > keep-alive I wouldn't be surprised if it doesn't work since we use > Axis as SOAP stack. > > Best regards, > > Stephan Laertz > > -------------------------------------------------------------------------- > > WebSphere Portal Server Development > > IBM Deutschland Entwicklung GmbH > Schoenaicher Str. 220, 71032 Boeblingen > Phone: +49 7031 16-3313 (*120 3313) > Email: <mailto:> > --------------------------------------------------------------------------- > > > > > Andre Kramer <> > <mailto:> > > 20.05.2003 13:40 > > To: Stephan Laertz/Germany/IBM@IBMDE > cc: > Subject: RE: testing IBM producer > > > > > > > > ok, I'll display portlet 0.1 and portlet 0.2 or 0.3 together. What's > the difference between 0.2 and 0.3? > > regards, > Andre > -----Original Message----- > From: Stephan Laertz [mailto:] > Sent: 20 May 2003 12:27 > To: Andre Kramer > Cc: <mailto:>; Peter > Fischer3; 'Richard Jacob' > Subject: Re: testing IBM producer > > > > Hi Andre, > > comments below > > MfG / Best regards, > > Stephan Laertz > > -------------------------------------------------------------------------- > > WebSphere Portal Server Development > > IBM Deutschland Entwicklung GmbH > Schoenaicher Str. 220, 71032 Boeblingen > Phone: +49 7031 16-3313 (*120 3313) > Email: > --------------------------------------------------------------------------- > > > > > Andre Kramer <> > <mailto:> > > 20.05.2003 12:44 > > To: Stephan Laertz/Germany/IBM@IBMDE, Peter > Fischer3/Germany/IBM@IBMDE > cc: Andre Kramer <> > <mailto:>, Richard Jacob/Germany/IBM@IBMDE, > "'David Ward'" <> <mailto:> > Subject: testing IBM producer > > > > > > > > Much better today! But I notice that the wsp-mode rewrite token is > called wsrp-Mode. > <step>You're right. Just a typo. Thanks</step> > > For portlet 0.1 (see attached ibm0.3-action&mode), clicking a link > now results in a performBlockingInteraction. This sets the > navigationalState to "none" but seems to have no other impact, as > the following getMarkup returns the same table of date/links. What > is the expected behaviour? > <step> Portlet 0.1 only writes something (a date string) in the > GroupSession. This string is read by portlet 0.2 and 0.3 and used to > fetch the dilbert comic of that specific day (you clicked on in 0.1) > from the dilbert site.</step> > > Also, calling getMarkup with <mode>wsrp:edit</mode> causes the > "Error occurred while invoking portlet service!" markup to get > returned (only for portlet 0.3). > <step>I wonder why this doesn't happen with 0.2. They have the same > code.</step> > > For portlet 0.2, I (see attached ibm0.1) get the "Could not connect > to Dilbert home page" markup. I can now click on the "Edit" link > (with a work around for wsrp-Mode) to get to the edit mode dialog, > but: > <step>I don't know why the portlet cannot connect to the dilbert > site. I will check that.</step> > > - I do not know what to enter for proxy host and port. > <step>These fields can be used to enter the proxy server and port > which are used by the portlets to connect to the dilbert site. > You should not enter any values here, unless you want to > see what happens if the portlet can not connect (The markup you've > seen already). > Once I've fixed some bugs you can use this form to test > form parameters and namespacing.</step> > > - Checking the "display a local Dilbert image" and then Submit > simply goes back to the "Could not connect ... " markup. > <step>Yes, I also recognized this bug this morning. I'm still > working on it. I'll let you know!</step> > > Anything else I could be testing? > <step>I'm afraid no, as long as I'm not finished working on that > issues. I hope this will be tomorrow.</step> > > regards, > Andre > > > > #### ibm0.2.xml has been removed from this note on May 20 2003 by > Stephan Laertz > #### ibm1.0-action&mode.xml has been removed from this note on May 20 > 2003 by Stephan Laertz > > > > > -- > ------------------------------------------------------------------------ > > > David Ward > Principal Software Engineer > Oracle Portal > Oracle European Development Centre > 520 Oracle Parkway > Thames Valley Park > Reading > Berkshire RG6 1RA > UK > Email: <mailto:> > Tel: +44 118 924 5079 > Fax: +44 118 924 5005 > > > > > > -- ------------------------------------------------------------------------ David Ward Principal Software Engineer Oracle Portal Oracle European Development Centre 520 Oracle Parkway Thames Valley Park Reading Berkshire RG6 1RA UK Email: <mailto:> Tel: +44 118 924 5079 Fax: +44 118 924 5005 -- David Ward Principal Software Engineer Oracle Portal Oracle European Development Centre 520 Oracle Parkway Thames Valley Park Reading Berkshire RG6 1RA UK Email: Tel: +44 118 924 5079 Fax: +44 118 924 5005 -- David Ward Principal Software Engineer Oracle Portal Oracle European Development Centre 520 Oracle Parkway Thames Valley Park Reading Berkshire RG6 1RA UK Email: Tel: +44 118 924 5079 Fax: +44 118 924 5005 -- David Ward Principal Software Engineer Oracle Portal Oracle European Development Centre 520 Oracle Parkway Thames Valley Park Reading Berkshire RG6 1RA UK Email: Tel: +44 118 924 5079 Fax: +44 118 924 5005 -- David Ward Principal Software Engineer Oracle Portal Oracle European Development Centre 520 Oracle Parkway Thames Valley Park Reading Berkshire RG6 1RA UK Email: Tel: +44 118 924 5079 Fax: +44 118 924 5005
← Prev in month
← Prev in thread
Next in thread →
Next in month →