Changes for page Web Services-Problems

Last modified by Francis Labrie on 2007/10/15 16:21

From version 7.1
edited by Francis Labrie
on 2007/10/09 13:16
Change comment: Layout and content table.
To version 6.1
edited by Francis Labrie
on 2007/09/26 11:17
Change comment: Updates and layout fixes

Summary

Details

Page properties
Content
... ... @@ -1,13 +11,3 @@
1 -|= Contents
2 -| {{section}}
3 -# [#Problems]
4 -## [#DirectToWebService can't return a WSDL with secure HTTPS references in it]
5 -## [#SOAP serializers and deserializers registered with {{WOWebServiceRegistrar}} class doesn't appear in the WSDL schema]
6 -## [#DirectToWebService can't return a WSDL with custom namespace and definitions name in it]
7 -## [#WOWebServiceClient class can't connect to a server that requires an authentication]
8 -## [#Web Services can't return a WSDL with secure HTTPS references specifying port other than the default 443]
9 -{{/section}}
10 -
11 11  = Problems =
12 12  
13 13  This section describes some problems and bugs that sometimes occur when using //WebObjects Web Services//.
... ... @@ -42,13 +42,13 @@
42 42  
43 43  {{/code}}
44 44  
45 -== SOAP serializers and deserializers registered with ##WOWebServiceRegistrar## class doesn't appear in the WSDL schema ==
35 +=== SOAP serializers and deserializers registered with ##WOWebServiceRegistrar## class doesn't appear in the WSDL schema ===
46 46  
47 47  **Authors:** Francis Labrie
48 48  **Affected products:** //WebObjects// 5.2.x, 5.3.x
49 49  **Bug reference:** [[rdar://3546330]]
50 50  
51 -=== Problem: ===
41 +==== Problem: ====
52 52  
53 53  Custom SOAP serializers and deserializers registered to Web Services with ##com.webobjects.appserver.WOWebServiceRegistrar## class are never added to the types / schema definition of the WSDL. The only type definitions shown are the following:
54 54  
... ... @@ -90,7 +90,7 @@
90 90  
91 91  {{/code}}
92 92  
93 -=== Solution: ===
83 +==== Solution: ====
94 94  
95 95  You must know that all complexe data types referred in operations will be added to the WSDL types definition. But if a complexe type makes references to others complexe types, you should make sure you add proper calls in the ##writeSchema(Types)## method of the class serializer. For example:
96 96  
... ... @@ -110,17 +110,17 @@
110 110  
111 111  Unfortunately, I don't know a dynamic workaround for all possible cases right now. At least a static and complete WSDL can be shared through a direct action, but it's not very handy though...
112 112  
113 -== DirectToWebService can't return a WSDL with custom namespace and definitions name in it ==
103 +=== DirectToWebService can't return a WSDL with custom namespace and definitions name in it ===
114 114  
115 115  **Authors:** Francis Labrie
116 116  **Affected products:** //WebObjects// 5.2.x, 5.3.x
117 117  **Bug reference:**
118 118  
119 -=== Problem: ===
109 +==== Problem: ====
120 120  
121 121  A //DirectToWebService// defined Web Services can't return a WSDL with custom values for properties like namespaces and definitions name. Worse, the generated namespace can even contains WebObjects application instance number or the wrong hostname.
122 122  
123 -=== Solution: ===
113 +==== Solution: ====
124 124  
125 125  Base on a tips from Darel Lee, I've found in the ##com.webobjects.webservices.generation.private.WOWSDLTemplate## class some extras key definitions read from the ##user.d2wmodel## //DirectToWebService// rule file. For instance:
126 126  
... ... @@ -141,19 +141,19 @@
141 141  
142 142  {{/code}}
143 143  
144 -== WOWebServiceClient class can't connect to a server that requires an authentication ==
134 +=== WOWebServiceClient class can't connect to a server that requires an authentication (WO 5.2.x, Bug ID 3568441) ===
145 145  
146 146  **Authors:** Francis Labrie
147 147  **Affected products:** //WebObjects// 5.2.x, 5.3.x
148 148  **Bug reference:** [[rdar://3568441]]
149 149  
150 -=== Problem: ===
140 +==== Problem: ====
151 151  
152 152  The ##com.webobjects.webservices.client.WOWebServiceClient## class can't connect to a server that requires a Basic HTTP Authentication despite the fact this class offers a way to register a security delegate (see ##setSecurityDelegateForServiceNamed(Object, String)## instance method).
153 153  
154 154  Normally, the ##processClientRequest(MessageContext)## delegate method (see ##com.webobjects.webservices.support.WOSecurityDelegateinterface## documentation) would allow an easy way to set a username and a password to the message context. But there is a problem related to the design of the class: to register a security delegate, the ##WOWebServiceClient## class has to fetch the Web Services Definition Language (WSDL) XML document. But to get access to this WSDL, an authentication header must be set. This is the classic chicken and egg problem...
155 155  
156 -=== Solution: ===
146 +==== Solution: ====
157 157  
158 158  The best would be to add a default method to ##WOWebServiceClient## class to register a default security delegate that is not related to a service name before the class fetch the WSDL. But unfortunately, all key methods that would allow this kind of behavior change are privates, so subclassing is not a solution...
159 159  
... ... @@ -166,19 +166,19 @@
166 166  
167 167  That's it. It looks like a big hack, but it works...
168 168  
169 -== Web Services can't return a WSDL with secure HTTPS references specifying port other than the default 443 ==
159 +=== Web Services can't return a WSDL with secure HTTPS references specifying port other than the default 443 ===
170 170  
171 171  **Authors:** Francis Labrie
172 172  **Affected products:** //WebObjects// 5.2.x, 5.3.x
173 173  **Bug reference:** [[rdar://4196417]]
174 174  
175 -=== Problem: ===
165 +==== Problem: ====
176 176  
177 177  HTTPS protocol references can be published in Web Services WSDL. But unfortunately, WebObjects seems to ignore ports other than the default 443.
178 178  
179 179  This problem is related to the bad way ##com.webobjects.appserver.WORequest## builds the URL prefix: if the protocol is secure and no port (i.e. 0) is set when calling the ##//completeURLPrefix(StringBuffer, boolean, int)//##// method, the port will always be 443. Unfortunately, Web Services ##com.webobjects.appserver.##//##private.WOWebService## class seems to call this method without setting the port number.
180 180  
181 -=== Solution: ===
171 +==== Solution: ====
182 182  
183 183  To work around this bug, you can subclass the ##com.webobjects.appserver.WORequest## class like this:
184 184