Changes for page Web Services-Problems

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,3 +1,13 @@
	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	+
1	1	= Problems =
2	2
3	3	This section describes some problems and bugs that sometimes occur when using //WebObjects Web Services//.
...	...	@@ -32,13 +32,13 @@
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	37	**Authors:** Francis Labrie
38	38	**Affected products:** //WebObjects// 5.2.x, 5.3.x
39	39	**Bug reference:** [[rdar://3546330]]
40	40
41		-==== Problem: ====
	51	+=== Problem: ===
42	42
43	43	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
...	...	@@ -80,7 +80,7 @@
80	80
81	81	{{/code}}
82	82
83		-==== Solution: ====
	93	+=== Solution: ===
84	84
85	85	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:
86	86
...	...	@@ -100,17 +100,17 @@
100	100
101	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	102
103		-=== DirectToWebService can't return a WSDL with custom namespace and definitions name in it ===
	113	+== DirectToWebService can't return a WSDL with custom namespace and definitions name in it ==
104	104
105	105	**Authors:** Francis Labrie
106	106	**Affected products:** //WebObjects// 5.2.x, 5.3.x
107	107	**Bug reference:**
108	108
109		-==== Problem: ====
	119	+=== Problem: ===
110	110
111	111	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.
112	112
113		-==== Solution: ====
	123	+=== Solution: ===
114	114
115	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:
116	116
...	...	@@ -131,19 +131,19 @@
131	131
132	132	{{/code}}
133	133
134		-=== WOWebServiceClient class can't connect to a server that requires an authentication (WO 5.2.x, Bug ID 3568441) ===
	144	+== WOWebServiceClient class can't connect to a server that requires an authentication ==
135	135
136	136	**Authors:** Francis Labrie
137	137	**Affected products:** //WebObjects// 5.2.x, 5.3.x
138	138	**Bug reference:** [[rdar://3568441]]
139	139
140		-==== Problem: ====
	150	+=== Problem: ===
141	141
142	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).
143	143
144	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...
145	145
146		-==== Solution: ====
	156	+=== Solution: ===
147	147
148	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...
149	149
...	...	@@ -156,19 +156,19 @@
156	156
157	157	That's it. It looks like a big hack, but it works...
158	158
159		-=== Web Services can't return a WSDL with secure HTTPS references specifying port other than the default 443 ===
	169	+== Web Services can't return a WSDL with secure HTTPS references specifying port other than the default 443 ==
160	160
161	161	**Authors:** Francis Labrie
162	162	**Affected products:** //WebObjects// 5.2.x, 5.3.x
163	163	**Bug reference:** [[rdar://4196417]]
164	164
165		-==== Problem: ====
	175	+=== 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	169	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.
170	170
171		-==== Solution: ====
	181	+=== Solution: ===
172	172
173	173	To work around this bug, you can subclass the ##com.webobjects.appserver.WORequest## class like this:
174	174