Changes for page Web Services-Problems
Last modified by Francis Labrie on 2007/10/15 16:21
From version 8.1
edited by Francis Labrie
on 2007/10/15 16:21
on 2007/10/15 16:21
Change comment:
There is no comment for this version
To version 10.2
edited by Francis Labrie
on 2007/10/15 16:21
on 2007/10/15 16:21
Change comment:
Changed document parent to [xwiki:documentation.Home.Development Architecture.Web Services.WebHome].
Summary
-
Page properties (2 modified, 0 added, 0 removed)
Details
- Page properties
-
- Parent
-
... ... @@ -1,0 +1,1 @@ 1 +documentation.Home.Development Architecture.Web Services.WebHome - Content
-
... ... @@ -1,12 +1,16 @@ 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}} 1 +|=((( 2 +Contents 3 +))) 4 +|((( 5 +{{section}} 6 +1. [[#Problems>>doc:||anchor="Problems"]] 7 +11. [[#DirectToWebService can't return a WSDL with secure HTTPS references in it>>doc:||anchor="DirectToWebService can't return a WSDL with secure HTTPS references in it"]] 8 +11. [[#SOAP serializers and deserializers registered with ~~{~~{WOWebServiceRegistrar}} class doesn't appear in the WSDL schema>>doc:||anchor="SOAP serializers and deserializers registered with {{WOWebServiceRegistrar}} class doesn't appear in the WSDL schema"]] 9 +11. [[#DirectToWebService can't return a WSDL with custom namespace and definitions name in it>>doc:||anchor="DirectToWebService can't return a WSDL with custom namespace and definitions name in it"]] 10 +11. [[#WOWebServiceClient class can't connect to a server that requires an authentication>>doc:||anchor="WOWebServiceClient class can't connect to a server that requires an authentication"]] 11 +11. [[#Web Services can't return a WSDL with secure HTTPS references specifying port other than the default 443>>doc:||anchor="Web Services can't return a WSDL with secure HTTPS references specifying port other than the default 443"]] 12 +{{/section}} 13 +))) 10 10 11 11 = Problems = 12 12 ... ... @@ -15,16 +15,16 @@ 15 15 == DirectToWebService can't return a WSDL with secure HTTPS references in it == 16 16 17 17 **Authors:** Francis Labrie 18 -**Affected products:** //WebObjects// 5.2.x, 5.3.x 19 -**Bug reference:** [[rdar://3546304]] 22 + **Affected products:** //WebObjects// 5.2.x, 5.3.x 23 + **Bug reference:** [[rdar:~~/~~/3546304>>url:rdar://3546304||shape="rect"]] 20 20 21 21 === Problem: === 22 22 23 -A //DirectToWebService// defined Web Services doesn't return correct WSDL document, even if the correct procedure (see [[WO :Secure Web Services]]) is followed. So only classes oriented Web Services manually registered with the##com.webobjects.appserver.WOWebServiceRegistrar##class seems to generate a correct WSDL.27 +A //DirectToWebService// defined Web Services doesn't return correct WSDL document, even if the correct procedure (see [[doc:WO.Secure Web Services]]) is followed. So only classes oriented Web Services manually registered with the {{code language="none"}}com.webobjects.appserver.WOWebServiceRegistrar{{/code}} class seems to generate a correct WSDL. 24 24 25 25 === Solution: === 26 26 27 -Darel Lee from Apple told me that right now, the dynamic WSDL generation is not exposed to developers so there currently isn't a clean solution to perform this. One workaround is to hardcode rules (of ##com.webobjects.directtoweb.Assignment##type) with the##serviceLocationURL##key for each operation that you want to use secure HTTPS references. For instance:31 +Darel Lee from Apple told me that right now, the dynamic WSDL generation is not exposed to developers so there currently isn't a clean solution to perform this. One workaround is to hardcode rules (of {{code language="none"}}com.webobjects.directtoweb.Assignment{{/code}} type) with the {{code language="none"}}serviceLocationURL{{/code}} key for each operation that you want to use secure HTTPS references. For instance: 28 28 29 29 {{code}} 30 30 ... ... @@ -42,15 +42,15 @@ 42 42 43 43 {{/code}} 44 44 45 -== SOAP serializers and deserializers registered with ##WOWebServiceRegistrar##class doesn't appear in the WSDL schema ==49 +== SOAP serializers and deserializers registered with {{code language="none"}}WOWebServiceRegistrar{{/code}} class doesn't appear in the WSDL schema == 46 46 47 47 **Authors:** Francis Labrie 48 -**Affected products:** //WebObjects// 5.2.x, 5.3.x 49 -**Bug reference:** [[rdar://3546330]] 52 + **Affected products:** //WebObjects// 5.2.x, 5.3.x 53 + **Bug reference:** [[rdar:~~/~~/3546330>>url:rdar://3546330||shape="rect"]] 50 50 51 51 === Problem: === 52 52 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:57 +Custom SOAP serializers and deserializers registered to Web Services with {{code language="none"}}com.webobjects.appserver.WOWebServiceRegistrar{{/code}} class are never added to the types / schema definition of the WSDL. The only type definitions shown are the following: 54 54 55 55 {{code}} 56 56 ... ... @@ -92,7 +92,7 @@ 92 92 93 93 === Solution: === 94 94 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:99 +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 {{code language="none"}}writeSchema(Types){{/code}} method of the class serializer. For example: 96 96 97 97 {{code}} 98 98 ... ... @@ -113,8 +113,8 @@ 113 113 == DirectToWebService can't return a WSDL with custom namespace and definitions name in it == 114 114 115 115 **Authors:** Francis Labrie 116 -**Affected products:** //WebObjects// 5.2.x, 5.3.x 117 -**Bug reference:** 120 + **Affected products:** //WebObjects// 5.2.x, 5.3.x 121 + **Bug reference:** 118 118 119 119 === Problem: === 120 120 ... ... @@ -122,7 +122,7 @@ 122 122 123 123 === Solution: === 124 124 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:129 +Base on a tips from Darel Lee, I've found in the {{code language="none"}}com.webobjects.webservices.generation._private.WOWSDLTemplate{{/code}} class some extras key definitions read from the {{code language="none"}}user.d2wmodel{{/code}} //DirectToWebService// rule file. For instance: 126 126 127 127 * **serviceLocationURL:** a key that allow the setting of the location URL for an operation. This is usefull if you need your WebServices to be reached using a secure HTTPS reference; 128 128 * **WSDLDefinitionName:** a key that allow the definitions name change. So instead of having "ServiceNameDefinition", you can set this value; ... ... @@ -144,24 +144,24 @@ 144 144 == WOWebServiceClient class can't connect to a server that requires an authentication == 145 145 146 146 **Authors:** Francis Labrie 147 -**Affected products:** //WebObjects// 5.2.x, 5.3.x 148 -**Bug reference:** [[rdar://3568441]] 151 + **Affected products:** //WebObjects// 5.2.x, 5.3.x 152 + **Bug reference:** [[rdar:~~/~~/3568441>>url:rdar://3568441||shape="rect"]] 149 149 150 150 === Problem: === 151 151 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).156 +The {{code language="none"}}com.webobjects.webservices.client.WOWebServiceClient{{/code}} 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 {{code language="none"}}setSecurityDelegateForServiceNamed(Object, String){{/code}} instance method). 153 153 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...158 +Normally, the {{code language="none"}}processClientRequest(MessageContext){{/code}} delegate method (see {{code language="none"}}com.webobjects.webservices.support.WOSecurityDelegateinterface{{/code}} 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 {{code language="none"}}WOWebServiceClient{{/code}} 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 156 === Solution: === 157 157 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...162 +The best would be to add a default method to {{code language="none"}}WOWebServiceClient{{/code}} 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 160 160 But a workaround is still possible: 161 161 162 -1. Fetch the WSDL document yourself and store it to the local filesystem, using the java.net.URL instance and setting up the Basic HTTP Authentication header field of the ##java.net.URLConnection##yourself;163 -1. Instanciate another ##java.net.URL##class that refer to the local WSDL document file;164 -1. Instanciate the ##com.webobjects.webservices.client.WOWebServiceClient##class using the file URL;166 +1. Fetch the WSDL document yourself and store it to the local filesystem, using the java.net.URL instance and setting up the Basic HTTP Authentication header field of the {{code language="none"}}java.net.URLConnection{{/code}} yourself; 167 +1. Instanciate another {{code language="none"}}java.net.URL{{/code}} class that refer to the local WSDL document file; 168 +1. Instanciate the {{code language="none"}}com.webobjects.webservices.client.WOWebServiceClient{{/code}} class using the file URL; 165 165 1. Set for each service a security delegate that will add the proper credential information for the Basic HTTP Authentication. 166 166 167 167 That's it. It looks like a big hack, but it works... ... ... @@ -169,18 +169,18 @@ 169 169 == 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 -**Affected products:** //WebObjects// 5.2.x, 5.3.x 173 -**Bug reference:** [[rdar://4196417]] 176 + **Affected products:** //WebObjects// 5.2.x, 5.3.x 177 + **Bug reference:** [[rdar:~~/~~/4196417>>url:rdar://4196417||shape="rect"]] 174 174 175 175 === 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 -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.183 +This problem is related to the bad way {{code language="none"}}com.webobjects.appserver.WORequest{{/code}} builds the URL prefix: if the protocol is secure and no port (i.e. 0) is set when calling the {{code language="none"}}_completeURLPrefix(StringBuffer, boolean, int){{/code}} method, the port will always be 443. Unfortunately, Web Services {{code language="none"}}com.webobjects.appserver._private.WOWebService{{/code}} class seems to call this method without setting the port number. 180 180 181 181 === Solution: === 182 182 183 -To work around this bug, you can subclass the ##com.webobjects.appserver.WORequest##class like this:187 +To work around this bug, you can subclass the {{code language="none"}}com.webobjects.appserver.WORequest{{/code}} class like this: 184 184 185 185 {{code}} 186 186