Re: [Mono-dev] WS stack.
Hi, Well, if your patch is exactly about message serialization, then it is not appropriate. The WSDL currently we generate is buggy and such a buggy WSDL will result in such an incorrect message serialization (that is, since the WSDL says fooSpecified should/could be in the message, wsdl.exe will interpret it as part of the message contract, and thus it will generate wrong proxy classes). However, you patch is for SoapReflectionImporter and I guess that seems to be the correct file to fix. Or is your way to reproduce the bug different? Are you using different service engine (e.g. .NET) ? Atsushi Eno Daniel Lundqvist wrote: Hi, Ok, I think there perhaps is a missunderstanding here. What I'm talking about here is not the resulting WSDL but the actual SOAP/XML serialization of the RPC call. I apologize if I wasn't clear enough about that from the start. Hope that makes more sense for you in this case. -Ursprungligt meddelande- Från: [EMAIL PROTECTED] genom Atsushi Eno Skickat: on 2007-02-07 16:27 Till: mono-devel-list@lists.ximian.com Ämne: Re: [Mono-dev] WS stack. Hi :) Daniel Lundqvist wrote: Hey again :) ons 2007-02-07 klockan 20:51 +0900 skrev Atsushi Eno: Hi Daniel, Daniel Lundqvist wrote: Hi Atsushi, mån 2007-02-05 klockan 15:14 +0900 skrev Atsushi Eno: Hi Daniel, Daniel Lundqvist wrote: The issue here is that it always sends the oid and parentoid field regardless of value of fieldSpecified. I got a patch (against SVN) for it, don't know if it's correct but solves the problem for me. So now it only sends oid and parentoid when fieldSpecified is set to true. This was tested with 1.1.17.1 but the problem is in SVN as well from what I can see. Oh, cool. Can you please share the patch so that it could be fixed? Of course, thought I attached it but I'll reattach it. The problem is that XmlTypeMapMember::CheckOptionalValueType is never called and thus the OPTIONAL bit in its flags field is never set (Which is then checked in XmlSerializationWriterInterpreter::MemberHasValue). Thanks :) However, now I tried your patch but it does not seem to fix the issue. Do you have actual case that the patch indeed fix the issue? I attached what I tried. Weird. I've redone my tests with the 1.2.3 release. With a stock System.Xml.dll it have the problem but with a patched (with the patch I sent earlier) it don't. There are some other places (I think) that XmlTypeMapMember is instanciated but I didn't add the call there, so this patch only fixes my problem. Perhaps this call should be placed in a more appropiate place, but I don't speak the XML/WS stack fluently enough to find where. If your patch does not fix the case that I attached, then yes it is likely to happen. I'd wait for your case and try to fix it. Now I think I see one issue. Since you are using WebService and WebMethod attributes perhaps they are hitting the other path that is calling CreateMapMember(), in ImportMembersMapping in either XmlReflectionImport.cs or SoapReflectionImport.cs (depends on using literal encoding or not). After some more investigation that seems to be the case. From what I can see the enclosing type is not available at that point (which is needed to call XmlTypeMapMember::CheckOptionalValueType). Well, however removing [WebService] didn't change anything, and without [WebMethod] it doesn't expose any ports. Or are you checking anything else than the output WSDL? (As long as the WSDL contains 'oldSpecified' and 'parentoidSpecified' the issue isn't fixed.) Probably a reproducible example would tell me what exactly is the issue you are having fix. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WS stack.
Hi Daniel,
Daniel Lundqvist wrote:
Hi Atsushi,
mån 2007-02-05 klockan 15:14 +0900 skrev Atsushi Eno:
Hi Daniel,
Daniel Lundqvist wrote:
The issue here is that it always sends the oid and parentoid field
regardless of value of fieldSpecified.
I got a patch (against SVN) for it, don't know if it's correct but
solves the problem for me. So now it only sends oid and parentoid when
fieldSpecified is set to true. This was tested with 1.1.17.1 but the
problem is in SVN as well from what I can see.
Oh, cool. Can you please share the patch so that it could be fixed?
Of course, thought I attached it but I'll reattach it. The problem is
that XmlTypeMapMember::CheckOptionalValueType is never called and thus
the OPTIONAL bit in its flags field is never set (Which is then checked
in XmlSerializationWriterInterpreter::MemberHasValue).
Thanks :) However, now I tried your patch but it does not seem to
fix the issue. Do you have actual case that the patch indeed fix
the issue? I attached what I tried.
There are some other places (I think) that XmlTypeMapMember is
instanciated but I didn't add the call there, so this patch only fixes
my problem. Perhaps this call should be placed in a more appropiate
place, but I don't speak the XML/WS stack fluently enough to find where.
If your patch does not fix the case that I attached, then yes it is
likely to happen. I'd wait for your case and try to fix it.
2) When using wsdl2 from latest release of Mono I have the following issues:
1) When using properties for member access, and field is the same name
as a keyword it don't prefix the property name with @.
Hmm, it would be nice if you file a bug for it. It is kind of corner
case, but fixing it would be nicer.
Will do. Discovered another problem of the same kind. The parser that is
generated for the WS also have the same problem with types that is named
after keywords and object, so when Mono tries to compile it it
encounters a couple of syntax errors.
Thanks :)
2) It seems to generate each service binding twice. One with the normal
name and another with name1. I.i
[System.Web.Services.WebServiceBinding(Name=packetfront_becs,
Namespace=urn:packetfront_becs)]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute(code)]
public class packetfront_becs :
System.Web.Services.Protocols.SoapHttpClientProtocol {
snip
}
[System.Web.Services.WebServiceBinding(Name=packetfront_becs,
Namespace=urn:packetfront_becs)]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute(code)]
public class packetfront_becs1 :
System.Web.Services.Protocols.SoapHttpClientProtocol {
snip
}
Do you have test case for this as well? I tried it (from svn) but
it didn't happen. Though I remember this kind of duplicate results
from those days I was working on Sys.Web.Services in my private
branch. It was because of target protocol unawareness on processing
bindings.
Hmm.. ok. Do this mean that there is some error in the WSDL file? I can
send our WSDL file in private to you if you want to investigate it.
If you mean what I've experienced, then no, it was bugs in my code
that it produced proxy classes for both SOAP 1.1 and 1.2 profiles.
If you can send me the problematic WSDL, I'll check it :)
Btw is there a way to have the WS stack reuse same WebRequest object for
the duration of the program? As it is now it creates a new for
WebRequest now and then (after a short while of inactivity it seems) and
this a new TCP connection. I would like it to use HTTP/1.1 Keep-Alive to
cut down traffic and TCP connections (since my software is a fairly long
running CLI program that does 50k-100k SOAP calls). I tried overriding
GetWebRequest(Uri) on the generated WS proxy code to return a singleton
WebRequest but that only resulting in using a disposed object after a
short while.
I'm kind of newbie to this area, but according to the API I guess
it might be possible if you create your own SoapHttpClientProtocol
(derived) class that overrides GetWebRequest() where you return
the same WebRequest whose KeepAlive is enabled, and use replace
SoapHttpClientProtocol with your own class.
Atsushi Eno
using System;
using System.Web.Services;
using System.Web.Services.Protocols;
[WebService]
public class TestService
{
[WebMethod]
//[SoapRpcMethod]
public void Register (TestObject data)
{
}
}
/// remarks/
[System.Xml.Serialization.SoapType(Namespace=urn:packetfront_becs)]
public class TestObject {
/// remarks/
public System.UInt64 oid;
/// remarks/
[System.Xml.Serialization.SoapIgnore()]
public bool oidSpecified;
/// remarks/
public System.UInt64 parentoid;
/// remarks/
[System.Xml.Serialization.SoapIgnore()]
public bool parentoidSpecified;
/// remarks/
public string creator;
}
Re: [Mono-dev] WS stack.
Hi :) Daniel Lundqvist wrote: Hey again :) ons 2007-02-07 klockan 20:51 +0900 skrev Atsushi Eno: Hi Daniel, Daniel Lundqvist wrote: Hi Atsushi, mån 2007-02-05 klockan 15:14 +0900 skrev Atsushi Eno: Hi Daniel, Daniel Lundqvist wrote: The issue here is that it always sends the oid and parentoid field regardless of value of fieldSpecified. I got a patch (against SVN) for it, don't know if it's correct but solves the problem for me. So now it only sends oid and parentoid when fieldSpecified is set to true. This was tested with 1.1.17.1 but the problem is in SVN as well from what I can see. Oh, cool. Can you please share the patch so that it could be fixed? Of course, thought I attached it but I'll reattach it. The problem is that XmlTypeMapMember::CheckOptionalValueType is never called and thus the OPTIONAL bit in its flags field is never set (Which is then checked in XmlSerializationWriterInterpreter::MemberHasValue). Thanks :) However, now I tried your patch but it does not seem to fix the issue. Do you have actual case that the patch indeed fix the issue? I attached what I tried. Weird. I've redone my tests with the 1.2.3 release. With a stock System.Xml.dll it have the problem but with a patched (with the patch I sent earlier) it don't. There are some other places (I think) that XmlTypeMapMember is instanciated but I didn't add the call there, so this patch only fixes my problem. Perhaps this call should be placed in a more appropiate place, but I don't speak the XML/WS stack fluently enough to find where. If your patch does not fix the case that I attached, then yes it is likely to happen. I'd wait for your case and try to fix it. Now I think I see one issue. Since you are using WebService and WebMethod attributes perhaps they are hitting the other path that is calling CreateMapMember(), in ImportMembersMapping in either XmlReflectionImport.cs or SoapReflectionImport.cs (depends on using literal encoding or not). After some more investigation that seems to be the case. From what I can see the enclosing type is not available at that point (which is needed to call XmlTypeMapMember::CheckOptionalValueType). Well, however removing [WebService] didn't change anything, and without [WebMethod] it doesn't expose any ports. Or are you checking anything else than the output WSDL? (As long as the WSDL contains 'oldSpecified' and 'parentoidSpecified' the issue isn't fixed.) Probably a reproducible example would tell me what exactly is the issue you are having fix. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WS stack.
Hi, Ok, I think there perhaps is a missunderstanding here. What I'm talking about here is not the resulting WSDL but the actual SOAP/XML serialization of the RPC call. I apologize if I wasn't clear enough about that from the start. Hope that makes more sense for you in this case. -Ursprungligt meddelande- Från: [EMAIL PROTECTED] genom Atsushi Eno Skickat: on 2007-02-07 16:27 Till: mono-devel-list@lists.ximian.com Ämne: Re: [Mono-dev] WS stack. Hi :) Daniel Lundqvist wrote: Hey again :) ons 2007-02-07 klockan 20:51 +0900 skrev Atsushi Eno: Hi Daniel, Daniel Lundqvist wrote: Hi Atsushi, mån 2007-02-05 klockan 15:14 +0900 skrev Atsushi Eno: Hi Daniel, Daniel Lundqvist wrote: The issue here is that it always sends the oid and parentoid field regardless of value of fieldSpecified. I got a patch (against SVN) for it, don't know if it's correct but solves the problem for me. So now it only sends oid and parentoid when fieldSpecified is set to true. This was tested with 1.1.17.1 but the problem is in SVN as well from what I can see. Oh, cool. Can you please share the patch so that it could be fixed? Of course, thought I attached it but I'll reattach it. The problem is that XmlTypeMapMember::CheckOptionalValueType is never called and thus the OPTIONAL bit in its flags field is never set (Which is then checked in XmlSerializationWriterInterpreter::MemberHasValue). Thanks :) However, now I tried your patch but it does not seem to fix the issue. Do you have actual case that the patch indeed fix the issue? I attached what I tried. Weird. I've redone my tests with the 1.2.3 release. With a stock System.Xml.dll it have the problem but with a patched (with the patch I sent earlier) it don't. There are some other places (I think) that XmlTypeMapMember is instanciated but I didn't add the call there, so this patch only fixes my problem. Perhaps this call should be placed in a more appropiate place, but I don't speak the XML/WS stack fluently enough to find where. If your patch does not fix the case that I attached, then yes it is likely to happen. I'd wait for your case and try to fix it. Now I think I see one issue. Since you are using WebService and WebMethod attributes perhaps they are hitting the other path that is calling CreateMapMember(), in ImportMembersMapping in either XmlReflectionImport.cs or SoapReflectionImport.cs (depends on using literal encoding or not). After some more investigation that seems to be the case. From what I can see the enclosing type is not available at that point (which is needed to call XmlTypeMapMember::CheckOptionalValueType). Well, however removing [WebService] didn't change anything, and without [WebMethod] it doesn't expose any ports. Or are you checking anything else than the output WSDL? (As long as the WSDL contains 'oldSpecified' and 'parentoidSpecified' the issue isn't fixed.) Probably a reproducible example would tell me what exactly is the issue you are having fix. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WS stack.
Hi Atsushi,
mån 2007-02-05 klockan 15:14 +0900 skrev Atsushi Eno:
Hi Daniel,
Daniel Lundqvist wrote:
The issue here is that it always sends the oid and parentoid field
regardless of value of fieldSpecified.
I got a patch (against SVN) for it, don't know if it's correct but
solves the problem for me. So now it only sends oid and parentoid when
fieldSpecified is set to true. This was tested with 1.1.17.1 but the
problem is in SVN as well from what I can see.
Oh, cool. Can you please share the patch so that it could be fixed?
Of course, thought I attached it but I'll reattach it. The problem is
that XmlTypeMapMember::CheckOptionalValueType is never called and thus
the OPTIONAL bit in its flags field is never set (Which is then checked
in XmlSerializationWriterInterpreter::MemberHasValue).
There are some other places (I think) that XmlTypeMapMember is
instanciated but I didn't add the call there, so this patch only fixes
my problem. Perhaps this call should be placed in a more appropiate
place, but I don't speak the XML/WS stack fluently enough to find where.
2) When using wsdl2 from latest release of Mono I have the following issues:
1) When using properties for member access, and field is the same name
as a keyword it don't prefix the property name with @.
Hmm, it would be nice if you file a bug for it. It is kind of corner
case, but fixing it would be nicer.
Will do. Discovered another problem of the same kind. The parser that is
generated for the WS also have the same problem with types that is named
after keywords and object, so when Mono tries to compile it it
encounters a couple of syntax errors.
2) It seems to generate each service binding twice. One with the normal
name and another with name1. I.i
[System.Web.Services.WebServiceBinding(Name=packetfront_becs,
Namespace=urn:packetfront_becs)]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute(code)]
public class packetfront_becs :
System.Web.Services.Protocols.SoapHttpClientProtocol {
snip
}
[System.Web.Services.WebServiceBinding(Name=packetfront_becs,
Namespace=urn:packetfront_becs)]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute(code)]
public class packetfront_becs1 :
System.Web.Services.Protocols.SoapHttpClientProtocol {
snip
}
Do you have test case for this as well? I tried it (from svn) but
it didn't happen. Though I remember this kind of duplicate results
from those days I was working on Sys.Web.Services in my private
branch. It was because of target protocol unawareness on processing
bindings.
Hmm.. ok. Do this mean that there is some error in the WSDL file? I can
send our WSDL file in private to you if you want to investigate it.
Btw is there a way to have the WS stack reuse same WebRequest object for
the duration of the program? As it is now it creates a new for
WebRequest now and then (after a short while of inactivity it seems) and
this a new TCP connection. I would like it to use HTTP/1.1 Keep-Alive to
cut down traffic and TCP connections (since my software is a fairly long
running CLI program that does 50k-100k SOAP calls). I tried overriding
GetWebRequest(Uri) on the generated WS proxy code to return a singleton
WebRequest but that only resulting in using a disposed object after a
short while.
Thanks in advance.
--
daniel
Index: SoapReflectionImporter.cs
===
--- SoapReflectionImporter.cs (revision 72075)
+++ SoapReflectionImporter.cs (arbetskopia)
@@ -224,7 +224,9 @@
ICollection members = GetReflectionMembers (type);
foreach (XmlReflectionMember rmember in members) {
if (rmember.SoapAttributes.SoapIgnore) continue;
-classMap.AddMember (CreateMapMember (rmember, defaultNamespace));
+ XmlTypeMapMember tmember = CreateMapMember (rmember, defaultNamespace);
+ tmember.CheckOptionalValueType(type);
+ classMap.AddMember (tmember);
}
// Import included classes
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WS stack.
Hi Daniel,
Daniel Lundqvist wrote:
The issue here is that it always sends the oid and parentoid field
regardless of value of fieldSpecified.
I got a patch (against SVN) for it, don't know if it's correct but
solves the problem for me. So now it only sends oid and parentoid when
fieldSpecified is set to true. This was tested with 1.1.17.1 but the
problem is in SVN as well from what I can see.
Oh, cool. Can you please share the patch so that it could be fixed?
2) When using wsdl2 from latest release of Mono I have the following issues:
1) When using properties for member access, and field is the same name
as a keyword it don't prefix the property name with @.
Hmm, it would be nice if you file a bug for it. It is kind of corner
case, but fixing it would be nicer.
2) It seems to generate each service binding twice. One with the normal
name and another with name1. I.i
[System.Web.Services.WebServiceBinding(Name=packetfront_becs,
Namespace=urn:packetfront_becs)]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute(code)]
public class packetfront_becs :
System.Web.Services.Protocols.SoapHttpClientProtocol {
snip
}
[System.Web.Services.WebServiceBinding(Name=packetfront_becs,
Namespace=urn:packetfront_becs)]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute(code)]
public class packetfront_becs1 :
System.Web.Services.Protocols.SoapHttpClientProtocol {
snip
}
Do you have test case for this as well? I tried it (from svn) but
it didn't happen. Though I remember this kind of duplicate results
from those days I was working on Sys.Web.Services in my private
branch. It was because of target protocol unawareness on processing
bindings.
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
