Re: [Mono-dev] [Mono-Dev] [Patch] System.Web.Services: ensure conformant WebSevice fails to generate its wsdl
Hello,
Some developers are stating that the new changes to web services
break all web services. Anything we should be watching out for?
Hi Kosta,
Thanks for the patch !
The attached patch ensures that a webservice attributed with
[WebServiceBinding (ConformsTo = WsiProfiles.BasicProfile1_1)] throws in
case it does not conform to that profile.
I guess the purpose of this patch is not only about it. After this
patch it rejects WebService classes that do not have
WebServiceBindingAttribute. Is it correct?
If yes, then the BindingInfo changes make it nicer.
In that case we could simply reuse the attribute for Name,
Namespace and Location too (i.e. no need to have those fields anymore).
+#if NET_2_0
+ if (binfo.WebServiceBindingAttribute != null
binfo.We
bServiceBindingAttribute.ConformsTo != WsiProfiles.None
String.IsNullOrEmpty
(binfo.WebServiceBindingAttribute.Name)) {
+ BasicProfileViolationCollection violations
= new
BasicProfileViolationCollection ();
+ if
(!WebServicesInteroperability.CheckConformanc
e (binfo.WebServiceBindingAttribute.ConformsTo, desc, violations))
+ throw new InvalidOperationException
(vio
lations [0].ToString ());
+ }
+#endif
Do we need to check WebServiceBindingAttribute.Name here?
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] [Mono-Dev] [Patch] System.Web.Services: ensure conformant WebSevice fails to generate its wsdl
This patch from Kosta is not applied yet. What is the details? There is
nothing we can do without any information.
Atsushi Eno
Miguel de Icaza wrote:
Hello,
Some developers are stating that the new changes to web services
break all web services. Anything we should be watching out for?
Hi Kosta,
Thanks for the patch !
The attached patch ensures that a webservice attributed with
[WebServiceBinding (ConformsTo = WsiProfiles.BasicProfile1_1)] throws in
case it does not conform to that profile.
I guess the purpose of this patch is not only about it. After this
patch it rejects WebService classes that do not have
WebServiceBindingAttribute. Is it correct?
If yes, then the BindingInfo changes make it nicer.
In that case we could simply reuse the attribute for Name,
Namespace and Location too (i.e. no need to have those fields anymore).
+#if NET_2_0
+ if (binfo.WebServiceBindingAttribute != null
binfo.We
bServiceBindingAttribute.ConformsTo != WsiProfiles.None
String.IsNullOrEmpty
(binfo.WebServiceBindingAttribute.Name)) {
+ BasicProfileViolationCollection violations
= new
BasicProfileViolationCollection ();
+ if
(!WebServicesInteroperability.CheckConformanc
e (binfo.WebServiceBindingAttribute.ConformsTo, desc, violations))
+ throw new InvalidOperationException
(vio
lations [0].ToString ());
+ }
+#endif
Do we need to check WebServiceBindingAttribute.Name here?
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] [Mono-Dev] [Patch] System.Web.Services: ensure conformant WebSevice fails to generate its wsdl
Hey, This patch from Kosta is not applied yet. What is the details? There is nothing we can do without any information. Ok, so it was not this. Hubert reported this: http://monoport.com/1622 Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-Dev] [Patch] System.Web.Services: ensure conformant WebSevice fails to generate its wsdl
Hey, It still does not tell much. Any reason he cannot file a bug report with something we can actually run? With the stack trace which starts with System.Net I'm not sure whether it is related to web service changes or not. Atsushi Eno Miguel de Icaza wrote: Hey, This patch from Kosta is not applied yet. What is the details? There is nothing we can do without any information. Ok, so it was not this. Hubert reported this: http://monoport.com/1622 Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpWebRequest method patch
Gert Driesen wrote: - Original Message - From: Robert Jordan [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Monday, January 29, 2007 12:46 PM Subject: Re: [Mono-dev] HttpWebRequest method patch Hi Atsushi, Atsushi Eno wrote: Well, it is very good idea to report this BUG to Microsoft and let them fix it. I will do that unless someone points out that our (a couple of lingr users') interpretation is wrong. I rather want judgement of the spec situation: whether HTTP methods like posT must retrieve request/response stream like POST. Since Apache IIS are both accepting case-insensitive method names it's a good idea to switch to POST-like behavior in HttpWebRequest, as implied by your patch. Robert Atsushi, have your decided against changing our implementation to match that of MS ? No, as I haven't removed the related test that you added without any agreement. (If you are saying that marking test as [Ignore] is a decision while adding test without any agreement is not a decision, it is very strange.) 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] [Mono-Dev] [Patch] System.Web.Services: ensure conformant WebSevice fails to generate its wsdl
Here's my IRC discussion with robert jordan, i hope it could help hubert the problem is... hubert Default service=new Default(); hubert service.Url=http://10.69.100.164:8080/Default.asmx;; hubert service.Method(); hubert this failed hubert and hubert Default service=new Default(); hubert service.Url=http://localhost:8080/Default.asmx;; hubert service.Method(); hubert this works robertj you mean it works on localhost only? hubert no... hubert it works if I use the name... robertj ah hubert service.Url=http://myhostname:8080/Default.asmx;; robertj ok. this is a new change. let me find the commit... hubert but this fail : service.Url=http://myhostname.fidudev.fr:8080/Default.asmx;; hubert the error is here : http://monoport.com/1622 robertj http://lists.ximian.com/pipermail/mono-patches/2007-January/086550.html I will do a bugreport... but i've not many free time... Le jeudi 01 février 2007 à 01:39 +0900, Atsushi Eno a écrit : Hey, It still does not tell much. Any reason he cannot file a bug report with something we can actually run? With the stack trace which starts with System.Net I'm not sure whether it is related to web service changes or not. Atsushi Eno Miguel de Icaza wrote: Hey, This patch from Kosta is not applied yet. What is the details? There is nothing we can do without any information. Ok, so it was not this. Hubert reported this: http://monoport.com/1622 Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Ce message et les �ventuels documents joints peuvent contenir des informations confidentielles. Au cas o� il ne vous serait pas destin�, nous vous remercions de bien vouloir le supprimer et en aviser imm�diatement l'exp�diteur. Toute utilisation de ce message non conforme � sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite. Les communications sur internet n'�tant pas s�curis�es, l'int�grit� de ce message n'est pas assur�e et la soci�t� �mettrice ne peut �tre tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpWebRequest method patch
-Original Message- From: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of Atsushi Eno Sent: woensdag 31 januari 2007 17:44 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] HttpWebRequest method patch Gert Driesen wrote: - Original Message - From: Robert Jordan [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Monday, January 29, 2007 12:46 PM Subject: Re: [Mono-dev] HttpWebRequest method patch Hi Atsushi, Atsushi Eno wrote: Well, it is very good idea to report this BUG to Microsoft and let them fix it. I will do that unless someone points out that our (a couple of lingr users') interpretation is wrong. I rather want judgement of the spec situation: whether HTTP methods like posT must retrieve request/response stream like POST. Since Apache IIS are both accepting case-insensitive method names it's a good idea to switch to POST-like behavior in HttpWebRequest, as implied by your patch. Robert Atsushi, have your decided against changing our implementation to match that of MS ? No, as I haven't removed the related test that you added without any agreement. Ok, no problem. I was just asking. (If you are saying that marking test as [Ignore] is a decision while adding test without any agreement is not a decision, it is very strange.) If you want to make a big deal out of adding a test (which helped to find out how MS exactly behaves, and which was marked NotWorking), then please go ahead. Gert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpWebRequest method patch
Gert Driesen wrote: If you want to make a big deal out of adding a test (which helped to find out how MS exactly behaves, and which was marked NotWorking), then please go ahead. You are likely misunderstanding what NotWorking means. It is used to mark tests on which we should fix our class libs based on them. There should not be any tests marked as NotWorking while they are for other purposes. Otherwise anyone else might spend his or her time to fix the bug while is it not really a bug. 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] HttpWebRequest method patch
-Original Message- From: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of Atsushi Eno Sent: woensdag 31 januari 2007 18:18 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] HttpWebRequest method patch Gert Driesen wrote: If you want to make a big deal out of adding a test (which helped to find out how MS exactly behaves, and which was marked NotWorking), then please go ahead. You are likely misunderstanding what NotWorking means. It is used to mark tests on which we should fix our class libs based on them. There should not be any tests marked as NotWorking while they are for other purposes. Otherwise anyone else might spend his or her time to fix the bug while is it not really a bug. I know and depending on the decision on whether or not to change our behavior to match that of MS, I would have changed it accordingly. How do you want to proceed on this one ? Let Gonzalo decide, or what do you propose ? Either way, I'd report it as a bug with MS. Gert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpWebRequest method patch
Gert Driesen wrote: You are likely misunderstanding what NotWorking means. It is used to mark tests on which we should fix our class libs based on them. There should not be any tests marked as NotWorking while they are for other purposes. Otherwise anyone else might spend his or her time to fix the bug while is it not really a bug. I know and depending on the decision on whether or not to change our behavior to match that of MS, I would have changed it accordingly. No, at least you didn't understand what I wrote above. Either way, I'd report it as a bug with MS. No need to do that. https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=254656 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] [PATCH] Mono.Data.SqliteClient ADO.NET 2.0 - new implementation
I'm glad to see Mono supporting the provider from Robert Simpson. It seems to be of high quality and actively maintained. I'm curious whether the encryption support in the provider will be made cross-platform if committed to mono. I would personally find such support beneficial. Patrick On 1/31/07, Marek Habersack [EMAIL PROTECTED] wrote: Hello, Attached is a new ADO.NET 2.0 provider for Sqlite3, adapted from http://sqlite-dotnet2.sourceforge.net/. Initially I thought the changes would be few, but then it turned out a more extensive adaptation was in order. I have tested the new stuff with f-spot which works nearly ok, except for an issue which turned out to be a bug in f-spot code (src/TagStore.cs:312 calls command.Dispose() and then goes on to reuse the command, which causes a problem since command.Connection is cleared by command.Dispose()). Please apply the patch to a copy of mono svn head and test on whatever application you have that uses Sqlite. A point to note - the new implementation does NOT support sqlite database format version 2! If your database is in that format, you need to convert it to format 3 (dump with sqlite 2.x and undump with sqlite3) prior to testing the code. Please let me know about any and all problems/issues you encouter while testing. thanks in advance for your time, marek ___ 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] [PATCH] Mono.Data.SqliteClient ADO.NET 2.0 - new implementation
On Wed, 31 Jan 2007 11:56:37 -0700, Patrick Earl [EMAIL PROTECTED] scribbled: I'm glad to see Mono supporting the provider from Robert Simpson. It We are effectively forking the effort, but I'm going to watch the changes Robert makes to his tree and backport the changes if need be. His stuff uses own version of sqlite3 which we can't obviously use, that's why the fork. seems to be of high quality and actively maintained. I'm curious Yes, I agree that the code is of very high quality. whether the encryption support in the provider will be made cross-platform if committed to mono. I would personally find such support beneficial. It probably won't, because it requires using Robert's interop.c and crypto.c to be used, which I can't do. But I think I'm going to find a way to implement that in C#, just not at the moment :) I would very much appreciate any input and testing you might throw into it - we'd like to get it into mono asap regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] System.Text.Encoding.GetEncoding compatibility fixes
Hi,
The attached patch fixes some minor differences between our and MS'
Encoding.GetEncoding implementation.
* GetEncoding (int): do not allow codepage value below zero
and above 0x.
* GetEncoding (string): modified NotSupportedException to
ArgumentException when encoding is not supported
Both changes are covered by unit tests.
Let me know if it's ok to commit.
Gert
Index: ChangeLog
===
--- ChangeLog (revision 71903)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2007-01-31 Gert Driesen [EMAIL PROTECTED]
+
+ * corlib_test.dll.sources: Added EncodingTest.cs.
+
2007-01-08 Sebastien Pouliot [EMAIL PROTECTED]
* corlib_test.dll.sources: Added new unit tests for bug #80439 to the
Index: corlib_test.dll.sources
===
--- corlib_test.dll.sources (revision 71903)
+++ corlib_test.dll.sources (working copy)
@@ -299,6 +299,7 @@
System.Text/EncoderReplacementFallbackTest.cs
System.Text/EncoderReplacementFallbackBufferTest.cs
System.Text/EncoderTest.cs
+System.Text/EncodingTest.cs
System.Text/EncodingInfoTest.cs
System.Text/StringBuilderTest.cs
System.Text/TestEncoding.cs
Index: System.Text/ChangeLog
===
--- System.Text/ChangeLog (revision 71903)
+++ System.Text/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2007-01-31 Gert Driesen [EMAIL PROTECTED]
+
+ * Encoding.cs: In GetEncoding (int) do not allow codepage value below zero
+ and above 0x. Modified NotSupportedException to ArgumentException in
+ GetEncoding (string).
+
2006-12-18 Atsushi Enomoto [EMAIL PROTECTED]
* EncoderFallbackBuffer.cs : implement Reset().
Index: System.Text/Encoding.cs
===
--- System.Text/Encoding.cs (revision 71903)
+++ System.Text/Encoding.cs (working copy)
@@ -1,5 +1,5 @@
/*
- * Encoding.cs - Implementation of the System.Text.Encoding class.
+ * Encoding.cs - Implementation of the System.Text.Encoding class.
*
* Copyright (c) 2001, 2002 Southern Storm Software, Pty Ltd
* Copyright (c) 2002, Ximian, Inc.
@@ -454,6 +454,10 @@
#endif
static Encoding GetEncoding (int codePage)
{
+ if (codePage 0 || codePage 0x)
+ throw new ArgumentOutOfRangeException (codepage,
+Valid values are between 0 and 65535, inclusive.);
+
// Check for the builtin code pages first.
switch (codePage) {
case 0: return Default;
@@ -695,7 +699,7 @@
}
// We have no idea how to handle this encoding name.
- throw new NotSupportedException (String.Format (Encoding name `{0}' not supported, name));
+ throw new ArgumentException (String.Format (Encoding name `{0}' not supported, name));
}
#endif // !ECMA_COMPAT
Index: Test/System.Text/ChangeLog
===
--- Test/System.Text/ChangeLog (revision 71903)
+++ Test/System.Text/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2007-01-31 Gert Driesen [EMAIL PROTECTED]
+
+ * EncodingTest.cs: Added tests for GetEncoding.
+
2006-07-18 Kornél Pál [EMAIL PROTECTED]
* ASCIIEncodingTest.cs: Added TestGetString3 test.
Index: Test/System.Text/EncodingTest.cs
===
--- Test/System.Text/EncodingTest.cs (revision 0)
+++ Test/System.Text/EncodingTest.cs (revision 0)
@@ -0,0 +1,85 @@
+//
+// EncodingTest.cs - Unit Tests for System.Text.Encoding
+//
+// Author:
+// Gert Driesen ([EMAIL PROTECTED])
+//
+// Copyright (C) 2007 Gert Driesen
+//
+// Permission is hereby granted, free of charge, to any person obtaining
+// a copy of this software and associated documentation files (the
+// Software), to deal in the Software without restriction, including
+// without limitation the rights to use, copy, modify, merge, publish,
+// distribute, sublicense, and/or sell copies of the Software, and to
+// permit persons to whom the Software is furnished to do so, subject to
+// the following conditions:
+//
+// The above copyright notice and this permission notice shall be
+// included in all copies or substantial portions of the Software.
+//
+// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+//
+
+using System;
+using System.Text;
+
+using NUnit.Framework;
+
+namespace MonoTests.System.Text
+{
+ [TestFixture]
+ public class EncodingTest
+ {
+ [Test]
+ public void GetEncoding_CodePage_Default ()
+ {
+ Assert.AreEqual (Encoding.Default, Encoding.GetEncoding (0));
+ }
+
+
Re: [Mono-dev] [Mono-Dev] [Patch] System.Web.Services: ensure conformant WebSevice fails to generate its wsdl
Title: RE: [Mono-Dev] [Patch] System.Web.Services: ensure conformant WebSevice fails to generate its wsdl
Hello Atsushi,
No, this is not correct. If there is no WebServiceBindingAttribute I add a default BindingInfo. I refactored the BindingInfo construction because currently we always create a default BindingInfo, which is not conformant. Thus my validation never works.
The reason I check the WebServiceBindingAttribute.Name is because of MS behavior. They throw ONLY if the name is unspecified (bug?), but in WSDL it always gets a default value. This is also the reason I need the original WebServiceBindingAttribute, since BindingInfo'a Name should be always valid...
Regards,
Kosta
-Original Message-
From: Atsushi Eno [mailto:[EMAIL PROTECTED]]
Sent: Wed 31/01/2007 08:31
To: Konstantin Triger
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-Dev] [Patch] System.Web.Services: ensure conformant WebSevice fails to generate its wsdl
Hi Kosta,
Thanks for the patch !
The attached patch ensures that a webservice attributed with
[WebServiceBinding (ConformsTo = WsiProfiles.BasicProfile1_1)] throws in
case it does not conform to that profile.
I guess the purpose of this patch is not only about it. After this
patch it rejects WebService classes that do not have
WebServiceBindingAttribute. Is it correct?
If yes, then the BindingInfo changes make it nicer.
In that case we could simply reuse the attribute for Name,
Namespace and Location too (i.e. no need to have those fields anymore).
+#if NET_2_0
+ if (binfo.WebServiceBindingAttribute != null binfo.We
bServiceBindingAttribute.ConformsTo != WsiProfiles.None String.IsNullOrEmpty
(binfo.WebServiceBindingAttribute.Name)) {
+ BasicProfileViolationCollection violations = new
BasicProfileViolationCollection ();
+ if (!WebServicesInteroperability.CheckConformanc
e (binfo.WebServiceBindingAttribute.ConformsTo, desc, violations))
+ throw new InvalidOperationException (vio
lations [0].ToString ());
+ }
+#endif
Do we need to check WebServiceBindingAttribute.Name here?
Atsushi Eno
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
