AW: LOG4NET-405 (was Re: [VOTE] Release Log4Net 1.2.13 based on RC2)
>On 2013-11-14, Dominik Psenner wrote: > >>> I'm not sure whether setting the encoding to UTF8 triggers some sort of >>> different handling inside of the framweork's SMTP code even if the test >>> was pure ASCII. If it doesn't, then I'm fine with UTF8. > >> and checking a few of my Gmail's mails it seems they default to UTF8. I've >> just spammed test messages, this is the code: > >OK, looks as if the main difference was UTF8 yields base64 encoding >while ASCII yields quoted printable. In general any MUA should be able >to deal with either and the difference likely is no big deal. I can >live with keeping the default at UTF8. I've come to the same conclusion, thus agreed.
Re: LOG4NET-405 (was Re: [VOTE] Release Log4Net 1.2.13 based on RC2)
On 2013-11-14, Dominik Psenner wrote: >> I'm not sure whether setting the encoding to UTF8 triggers some sort of >> different handling inside of the framweork's SMTP code even if the test >> was pure ASCII. If it doesn't, then I'm fine with UTF8. > and checking a few of my Gmail's mails it seems they default to UTF8. I've > just spammed test messages, this is the code: OK, looks as if the main difference was UTF8 yields base64 encoding while ASCII yields quoted printable. In general any MUA should be able to deal with either and the difference likely is no big deal. I can live with keeping the default at UTF8. Stefan
AW: LOG4NET-405 (was Re: [VOTE] Release Log4Net 1.2.13 based on RC2)
>> Thought of that too, but I decided to let it be in UTF8 cause its the most >> compatible format nowadays whereas ASCII is somewhat antique. What do >you >> think? > >IIUC ASCII would have been the implicit body encoding for log4net < >1.2.12 so when looking for a backwards compatible default this would be >the most natural choice. > >I'm not sure whether setting the encoding to UTF8 triggers some sort of >different handling inside of the framweork's SMTP code even if the test >was pure ASCII. If it doesn't, then I'm fine with UTF8. > >Maybe we should send two messages with a body only containing ASCII >letters and compare the raw messages created with encoding set to ASCII >or UTF8 respectively. Agreed. FWIW, I found this: http://w3techs.com/technologies/overview/character_encoding/all and checking a few of my Gmail's mails it seems they default to UTF8. I've just spammed test messages, this is the code: static void Main(string[] args) { MailAddress from = new MailAddress("dpsen...@gmail.com"); MailAddress to = new MailAddress("log4net-dev@logging.apache.org"); string host = "smtp.gmail.com"; int port = 25; NetworkCredential networkCredentials = new NetworkCredential("f...@gmail.com", "bar"); bool enableSsl = true; Encoding[] subjectEncodings = new Encoding[] { Encoding.ASCII, Encoding.UTF8 }; Encoding[] bodyEncodings = new Encoding[] { Encoding.ASCII, Encoding.UTF8 }; List content = new List(); for (byte i = 0x20; i <= 0x7F; i++) content.Add(i); string[] subjects = new string[] { "ASCII:\t" + Encoding.ASCII.GetString(content.ToArray()), "UTF8:\t" + Encoding.UTF8.GetString(content.ToArray()) }; string[] bodies = new string[] { "ASCII:\t" + Encoding.ASCII.GetString(content.ToArray()), "UTF8:\t" + Encoding.UTF8.GetString(content.ToArray()) }; foreach (Encoding subjectEncoding in subjectEncodings) { foreach (Encoding bodyEncoding in bodyEncodings) { foreach (string subject in subjects) { foreach(string body in bodies) { Console.WriteLine(@" SubjectEncoding={0} BodyEncoding= {1} Subject={2} Body= {3}", subjectEncoding.EncodingName, bodyEncoding.EncodingName, subject, body); SendMail(from, to, string.Format("[LOG4NET-405 Test Mail] [{0}] [{1}] {2}", subjectEncoding.EncodingName, bodyEncoding.EncodingName, subject), subjectEncoding, body, bodyEncoding, host, port, networkCredentials, enableSsl); } } } } Console.ReadKey(); } private static void SendMail(MailAddress from, MailAddress to, string subject, Encoding subjectEncoding, string body, Encoding bodyEncoding, string host, int port, NetworkCredential credentials = null, bool enableSsl = true, SmtpDeliveryMethod deliveryMethod = SmtpDeliveryMethod.Network) { try { ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(TrustAllCertificatesPolicy); using (SmtpClient client = new SmtpClient(host, port)) { client.Timeout = 30 * 1000; // 10 seconds // set properties client.DeliveryMethod = deliveryMethod; client.EnableSsl = enableSsl; client.UseDefaultCredentials = (credentials == null); client.Credentials = credentials; // send message using (MailMessage msg = new MailMessage()) { msg.From = from; msg.To.Add(to); msg.Body = body; msg.BodyEncoding = bodyEncoding; msg.Subject = subject;
LOG4NET-405 (was Re: [VOTE] Release Log4Net 1.2.13 based on RC2)
On 2013-11-13, Dominik Psenner wrote: > Thought of that too, but I decided to let it be in UTF8 cause its the most > compatible format nowadays whereas ASCII is somewhat antique. What do you > think? IIUC ASCII would have been the implicit body encoding for log4net < 1.2.12 so when looking for a backwards compatible default this would be the most natural choice. I'm not sure whether setting the encoding to UTF8 triggers some sort of different handling inside of the framweork's SMTP code even if the test was pure ASCII. If it doesn't, then I'm fine with UTF8. Maybe we should send two messages with a body only containing ASCII letters and compare the raw messages created with encoding set to ASCII or UTF8 respectively. Stefan
Re: [VOTE] Release Log4Net 1.2.13 based on RC2
Thought of that too, but I decided to let it be in UTF8 cause its the most compatible format nowadays whereas ASCII is somewhat antique. What do you think? 2013/11/13 Stefan Bodewig > On 2013-11-13, Dominik Psenner wrote: > > > To me it looks like I've broken the prior behaviour while trying to fix > > LOG4NET-354 and LOG4NET-405 remedies that. *ouch* > > I see > > > Quoting: > > > http://msdn.microsoft.com/en-us/library/system.net.mail.mailmessage.bodyenco > > ding(v=vs.110).aspx > > >> The default character set is "us-ascii". > > > Here they do not mention the default encoding, but it will most likely be > > Encoding.ASCII whereas Encoding.Default will most likely yield something > > different. > > Shouldn't we change body encoding's default to ASCII, then? > > Stefan > -- Dominik Psenner
[CANCELED][VOTE] Release Log4Net 1.2.13 based on RC2
Cancelling this vote as a bug has showned up that we want to fix before cutting another release candidate. Stefan
Re: [VOTE] Release Log4Net 1.2.13 based on RC2
On 2013-11-13, Dominik Psenner wrote: > To me it looks like I've broken the prior behaviour while trying to fix > LOG4NET-354 and LOG4NET-405 remedies that. *ouch* I see > Quoting: > http://msdn.microsoft.com/en-us/library/system.net.mail.mailmessage.bodyenco > ding(v=vs.110).aspx >> The default character set is "us-ascii". > Here they do not mention the default encoding, but it will most likely be > Encoding.ASCII whereas Encoding.Default will most likely yield something > different. Shouldn't we change body encoding's default to ASCII, then? Stefan
AW: [VOTE] Release Log4Net 1.2.13 based on RC2
To me it looks like I've broken the prior behaviour while trying to fix LOG4NET-354 and LOG4NET-405 remedies that. *ouch* Quoting: http://msdn.microsoft.com/en-us/library/system.net.mail.mailmessage.headerse ncoding(v=vs.110).aspx > The value of the HeadersEncoding property defaults to Encoding.UTF8 whereas Encoding.Default will most likely yield something different. Quoting: http://msdn.microsoft.com/en-us/library/system.net.mail.mailmessage.bodyenco ding(v=vs.110).aspx > The default character set is "us-ascii". Here they do not mention the default encoding, but it will most likely be Encoding.ASCII whereas Encoding.Default will most likely yield something different.
Re: [VOTE] Release Log4Net 1.2.13 based on RC2
On 2013-11-13, Dominik Psenner wrote: > 0 > LOG4NET-405 jumped in and I am about to commit a fix. I'm not comfortable with putting that into 1.2.13. This changes a default value which in turn might byte people relying on the old default. I don't have any problem with changing the default for 1.3. Stefan
AW: [VOTE] Release Log4Net 1.2.13 based on RC2
0 LOG4NET-405 jumped in and I am about to commit a fix.
Re: [VOTE] Release Log4Net 1.2.13 based on RC2
On 2013-11-10, wrote: > Professionally I’m back to working with a .NET technology stack, so > I’ll also try find time to contribute to .NET OSS projects again. very much looking forward to it. Stefan
Re: [VOTE] Release Log4Net 1.2.13 based on RC2
+1 Note: i have no Windows machine and was not able to verify building or other technical checks. I have tested formal requirements though On 10 Nov 2013, at 9:54, Stefan Bodewig wrote: > Hi all, > > per discussion of the last few days we intend to cut a final(?) release > from the 1.2.x branch fixing some problems with the ILog extensions and > compilation for the compact framework. > > log4net 1.2.13 RC2 is available for review here: > https://dist.apache.org/repos/dist/dev/logging/log4net > (revision 3469) > > Details of changes since 1.2.12 are in the release notes: > http://logging.apache.org/log4net/log4net-1.2.13/release/release-notes.html > > (note, I've already committed the site ot the live system but it is > not reachable by any links - the 1.2.12 site is the one shown by default) > > I have tested this with Mono and several .NET frameworks using NAnt. > > The tag is here: > https://svn.apache.org/repos/asf/logging/log4net/tags/1.2.13RC2 > (revision 1540448) > > Site: > http://logging.apache.org/log4net/log4net-1.2.13/ > > RAT Report: > http://logging.apache.org/log4net/log4net-1.2.13/rat-report.html > > Votes, please. This vote will close in 72 hours, 0900 GMT 13-Nov > 2013 > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thanks! > > Stefan --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB
Re: [VOTE] Release Log4Net 1.2.13 based on RC2
Stefan, Thanks for the feedback, and thank you and Dominic for breathing new life into log4net! Professionally I’m back to working with a .NET technology stack, so I’ll also try find time to contribute to .NET OSS projects again. Gert Van: Stefan Bodewig Verzonden: zondag 10 november 2013 12:47 Aan: log4net-dev@logging.apache.org Great to see you here, Gert! On 2013-11-10, wrote: > no build for .NET 4.5, but I assume this was already discussed before > and is planned for a subsequent release We introduced the 4.0 builds in 2011 mainly because of the new security model. Without that the 2.0 version worked just fine. In a similiar vain the 4.0 version is supposed to be well suited for 4.5 and we'd only add special builds when needed. Targeting WinRT would require quite a bit of work. Technically, NAnt doesn't support 4.5, yet, which is a hurdle. Also AFAIU I wouldn't be able to target 4.0 on a machine with 4.5 installed as it is an in-place update so building the release would require two different Windows installations. > do we position “net” binaries as targeting only MS .NET, or are they > suppose to be cross-CLR / cross-platform? The trunk of log4net (targeting log4net 1.3.x and dropping support for .NET 1.x) uses the exact same source code to compile the net/2.0 and mono/2.0 assemblies, there is no specific MONO define used right now. As long as your version of Mono is recent enough (2.10 works well) the "net" binaries should work fine. I intend to add builds for mono-3.5 and 4.0 (based on Mono 2.10 as NAnt has problems with Mono 3.x) to verify the newer assemblies work for them as well. The goal is to keep platform dependenencies to a minimum but also accept them when needed - i.e. we wouldn't rule out supporting a certain feature just because it wasn't supported on all platforms. Stefan
Re: [VOTE] Release Log4Net 1.2.13 based on RC2
Great to see you here, Gert! On 2013-11-10, wrote: > no build for .NET 4.5, but I assume this was already discussed before > and is planned for a subsequent release We introduced the 4.0 builds in 2011 mainly because of the new security model. Without that the 2.0 version worked just fine. In a similiar vain the 4.0 version is supposed to be well suited for 4.5 and we'd only add special builds when needed. Targeting WinRT would require quite a bit of work. Technically, NAnt doesn't support 4.5, yet, which is a hurdle. Also AFAIU I wouldn't be able to target 4.0 on a machine with 4.5 installed as it is an in-place update so building the release would require two different Windows installations. > do we position “net” binaries as targeting only MS .NET, or are they > suppose to be cross-CLR / cross-platform? The trunk of log4net (targeting log4net 1.3.x and dropping support for .NET 1.x) uses the exact same source code to compile the net/2.0 and mono/2.0 assemblies, there is no specific MONO define used right now. As long as your version of Mono is recent enough (2.10 works well) the "net" binaries should work fine. I intend to add builds for mono-3.5 and 4.0 (based on Mono 2.10 as NAnt has problems with Mono 3.x) to verify the newer assemblies work for them as well. The goal is to keep platform dependenencies to a minimum but also accept them when needed - i.e. we wouldn't rule out supporting a certain feature just because it wasn't supported on all platforms. Stefan
Re: [VOTE] Release Log4Net 1.2.13 based on RC2
+1 with following questions/remarks: no build for .NET 4.5, but I assume this was already discussed before and is planned for a subsequent release do we position “net” binaries as targeting only MS .NET, or are they suppose to be cross-CLR / cross-platform? Van: Stefan Bodewig Verzonden: zondag 10 november 2013 9:54 Aan: log4net-dev@logging.apache.org, gene...@logging.apache.org Hi all, per discussion of the last few days we intend to cut a final(?) release from the 1.2.x branch fixing some problems with the ILog extensions and compilation for the compact framework. log4net 1.2.13 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/logging/log4net (revision 3469) Details of changes since 1.2.12 are in the release notes: http://logging.apache.org/log4net/log4net-1.2.13/release/release-notes.html (note, I've already committed the site ot the live system but it is not reachable by any links - the 1.2.12 site is the one shown by default) I have tested this with Mono and several .NET frameworks using NAnt. The tag is here: https://svn.apache.org/repos/asf/logging/log4net/tags/1.2.13RC2 (revision 1540448) Site: http://logging.apache.org/log4net/log4net-1.2.13/ RAT Report: http://logging.apache.org/log4net/log4net-1.2.13/rat-report.html Votes, please. This vote will close in 72 hours, 0900 GMT 13-Nov 2013 [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Stefan
[VOTE] Release Log4Net 1.2.13 based on RC2
Hi all, per discussion of the last few days we intend to cut a final(?) release from the 1.2.x branch fixing some problems with the ILog extensions and compilation for the compact framework. log4net 1.2.13 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/logging/log4net (revision 3469) Details of changes since 1.2.12 are in the release notes: http://logging.apache.org/log4net/log4net-1.2.13/release/release-notes.html (note, I've already committed the site ot the live system but it is not reachable by any links - the 1.2.12 site is the one shown by default) I have tested this with Mono and several .NET frameworks using NAnt. The tag is here: https://svn.apache.org/repos/asf/logging/log4net/tags/1.2.13RC2 (revision 1540448) Site: http://logging.apache.org/log4net/log4net-1.2.13/ RAT Report: http://logging.apache.org/log4net/log4net-1.2.13/rat-report.html Votes, please. This vote will close in 72 hours, 0900 GMT 13-Nov 2013 [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Stefan