Changes for page Web Services-Problems
Last modified by Francis Labrie on 2007/10/15 16:21
From version 6.1
edited by Francis Labrie
on 2007/09/26 11:17
on 2007/09/26 11:17
Change comment:
Updates and layout fixes
To version 2.1
edited by Pascal Robert
on 2007/09/03 19:32
on 2007/09/03 19:32
Change comment:
There is no comment for this version
Summary
-
Page properties (2 modified, 0 added, 0 removed)
Details
- Page properties
-
- Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. flabrie1 +XWiki.probert - Content
-
... ... @@ -4,17 +4,27 @@ 4 4 5 5 == DirectToWebService can't return a WSDL with secure HTTPS references in it == 6 6 7 -**Authors:** Francis Labrie 8 -**Affected products:** //WebObjects// 5.2.x, 5.3.x 9 -**Bug reference:** [[rdar://3546304]] 7 + **Authors:** Francis Labrie 10 10 9 + **Affected products:** //WebObjects// 5.2.x, 5.3.x 10 + 11 + **Bug reference:** rdar:~/~/3546304 12 + 11 11 === Problem: === 12 12 13 -A //DirectToWebService// defined Web Services doesn't return correct WSDL document, even if the correct procedure (see [[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.15 +A //DirectToWebService// defined Web Services doesn't return correct WSDL document, even if the correct procedure (see Secure Web Services) is followed. So only classes oriented Web Services manually registered with the 14 14 17 +{{code}} 18 + 19 +com.webobjects.appserver.WOWebServiceRegistrar 20 + 21 +{{/code}} 22 + 23 +class seems to generate a correct WSDL. 24 + 15 15 === Solution: === 16 16 17 -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: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 (ofcom.webobjects.directtoweb.Assignment type) with the serviceLocationURL key for each operation that you want to use secure HTTPS references. For instance: 18 18 19 19 {{code}} 20 20 ... ... @@ -32,15 +32,15 @@ 32 32 33 33 {{/code}} 34 34 35 -=== SOAP serializers and deserializers registered with ##WOWebServiceRegistrar##class doesn't appear in the WSDL schema ===45 +=== SOAP serializers and deserializers registered with WOWebServiceRegistrar class doesn't appear in the WSDL schema === 36 36 37 - **Authors:**Francis Labrie38 - **Affected products:** //WebObjects//5.2.x, 5.3.x39 - **Bug reference:** [[rdar://3546330]]47 +Authors:Francis Labrie 48 +Affected products:WebObjects5.2.x, 5.3.x 49 +Bug reference:rdar:~/~/3546330 40 40 41 41 ==== Problem: ==== 42 42 43 -Custom SOAP serializers and deserializers registered to Web Services with ##com.webobjects.appserver.WOWebServiceRegistrar##class are never added to the types53 +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: 44 44 45 45 {{code}} 46 46 ... ... @@ -82,29 +82,13 @@ 82 82 83 83 ==== Solution: ==== 84 84 85 - Youmust knowthat all complexe data typesreferredin operations will be addedto the WSDLtypesdefinition. Butifacomplexetype makesreferencesto otherscomplexetypes,youshould make sureyou addpropercallsin the##writeSchema(Types)##method of the class serializer.For example:95 +I don't know any dynamic workaround right now... But a static and complete WSDL can be shared through a direct action. It's not very handy though... 86 86 87 -{{code}} 88 - 89 -public boolean writeSchema(Types types) 90 -throws Exception { 91 - ... 92 - // Add type for Foo 93 - types.writeType(Foo.class, _FooQName); 94 - ... 95 - 96 - return true; 97 -} 98 - 99 -{{/code}} 100 - 101 -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... 102 - 103 103 === DirectToWebService can't return a WSDL with custom namespace and definitions name in it === 104 104 105 - **Authors:**Francis Labrie106 - **Affected products:** //WebObjects//5.2.x, 5.3.x107 - **Bug reference:**99 +Authors:Francis Labrie 100 +Affected products:WebObjects5.2.x, 5.3.x 101 +Bug reference: 108 108 109 109 ==== Problem: ==== 110 110 ... ... @@ -112,11 +112,11 @@ 112 112 113 113 ==== Solution: ==== 114 114 115 -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:109 +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~:// 116 116 117 117 * **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; 118 118 * **WSDLDefinitionName:** a key that allow the definitions name change. So instead of having "ServiceNameDefinition", you can set this value; 119 -* **WSDLTargetNamespace:** a key that allow the namespace change. This is the most usefull: you can avoid dynamic generation depending on WebObjects HTTP Adaptor with this. 113 +* **WSDLTargetNamespace:** a key that allow the namespace change. This is the most usefull: you can avoid dynamic generation depending on WebObjects HTTP Adaptor? with this. 120 120 121 121 Here is an example of rule definition changing the above values: 122 122 ... ... @@ -133,25 +133,25 @@ 133 133 134 134 === WOWebServiceClient class can't connect to a server that requires an authentication (WO 5.2.x, Bug ID 3568441) === 135 135 136 - **Authors:**Francis Labrie137 - **Affected products:** //WebObjects//5.2.x, 5.3.x138 - **Bug reference:** [[rdar://3568441]]130 +Authors:Francis Labrie 131 +Affected products:WebObjects5.2.x, 5.3.x 132 +Bug reference:rdar:~/~/3568441 139 139 140 140 ==== Problem: ==== 141 141 142 -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).136 +The com.webobjects.webservices.client.WOWebServiceClientclass 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). 143 143 144 -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...138 +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 WOWebServiceClientclass 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... 145 145 146 146 ==== Solution: ==== 147 147 148 -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...142 +The best would be to add a default method to WOWebServiceClientclass 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... 149 149 150 150 But a workaround is still possible: 151 151 152 -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;153 -1. Instanciate another ##java.net.URL##class that refer to the local WSDL document file;154 -1. Instanciate the ##com.webobjects.webservices.client.WOWebServiceClient##class using the file URL;146 +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; 147 +1. Instanciate another java.net.URL class that refer to the local WSDL document file; 148 +1. Instanciate the com.webobjects.webservices.client.WOWebServiceClient<>code> class using the file URL; 155 155 1. Set for each service a security delegate that will add the proper credential information for the Basic HTTP Authentication. 156 156 157 157 That's it. It looks like a big hack, but it works... ... ... @@ -158,23 +158,23 @@ 158 158 159 159 === Web Services can't return a WSDL with secure HTTPS references specifying port other than the default 443 === 160 160 161 - **Authors:**Francis Labrie162 - **Affected products:** //WebObjects//5.2.x, 5.3.x163 - **Bug reference:** [[rdar://4196417]]155 +Authors:Francis Labrie 156 +Affected products:WebObjects5.2.x, 5.3.x 157 +Bug reference:rdar:~/~/4196417 164 164 165 165 ==== Problem: ==== 166 166 167 167 HTTPS protocol references can be published in Web Services WSDL. But unfortunately, WebObjects seems to ignore ports other than the default 443. 168 168 169 -This problem is related to the bad way ##com.webobjects.appserver.WORequest##buildsthe URL prefix: if the protocol is secure and no port (i.e. 0) is set when calling the##//completeURLPrefix(StringBuffer,//##//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.163 +This problem is related to the bad waycom.webobjects.appserver.WORequestbuild 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 Servicescom.webobjects.appserver.//private.WOWebServiceclass seems to call this method without setting the port number. 170 170 171 171 ==== Solution: ==== 172 172 173 -To work around this bug, you can subclass the ##com.webobjects.appserver.WORequest##class like this:167 +To work around this bug, you can subclass the com.webobjects.appserver.WORequest class like this: 174 174 175 175 {{code}} 176 176 177 -package com.smoguli.appserver; 171 + package com.smoguli.appserver; 178 178 179 179 import com.webobjects.appserver.WORequest; 180 180 import com.webobjects.foundation.NSData;