When a byte or byte combination cannot be converted to a character by the
character encoding, I think Java prints '?' (0x3F) by default.
You con't need SocketAppender to reproduce this:
@Test
public void test() {
String txt = "?String" + '\uD800';
System.out.println(txt); // prints
The build scripts I made and use do indeed use msbuild (or the dotnet
wrapper around it, depending on environment) - they simply abstract away
finding the latest (or requested) version as well as calling conventions.
They can also use nuget or the dotnet command for packaging and package
Great to see log4net gains some momentum! If changing the build system is
on the table, I would try sticking with the default msbuild capabilities.
Especially useful is the MSBuild inline task capability [1].
[1]
Hello,
While trying to understand the behavior of SocketAppender against
uncommon Unicode characters, I have come across to an interesting
case: \uD800 gets transmitted as \u003F ('?'). One can easily verify
this by appending \uD800 at the end of "This is a test message"
literals in
On progress reports: sure, I'll try to keep this list updated
On PRs: I'm happy to start helping once I've spent more time in the codebase
(which I will have to do anyway), so that I can give better feedback.
-d
On 2020-04-08 08:53:44, Ralph Goers wrote:
Sounds good. If you wouldn’t mind, it
Sounds good. If you wouldn’t mind, it would be nice if you could provide
progress reports on a regular schedule that works for you just so we know you
are still working on it.
Also, as you probably know we do get PRs and questions from time to time that
none of us are comfortable answering.
Thanks Matt
To clarify my plans, I will:
1. update the build system for log4net: I haven't seen any objection to using
node-based build scripts as I have for my own packages, so I'll head down that
path. Currently, I use those as a git submodule, but I'm quite close to having
them available as
