Re: porting log4j2 to .NET
I could possible offer some assistance if the effort would be along the lines of porting log4j2 to .NET. As I mentioned, I had suggested this on the log4net mailing list and while they were not totally against it there seemed some concern, rightly so, on the overall effort and possibly not being backwards compatible. I wouldn't be interested in helping move log4net along in a different direction than log4j2 as I think that's the wrong decision. Thanks, Nick From: Matt Sicker Sent: Wednesday, October 19, 2016 9:59 AM To: Log4J Users List Subject: Re: porting log4j2 to .NET That would be great. From what I recall, the two main log4net developers are pretty busy with other things now and can only provide some maintenance work on log4net. We have tweeted and blogged about this in the recent past looking for some new developers. I personally haven't used C# since college, and the .net framework has changed a lot since then, so I don't feel competent enough to spearhead a log4net2 or anything like that myself. On 19 October 2016 at 02:45, Mikael Ståldal wrote: > It seems to me that a (conceptually) simple and constructive way forward > would be to improve or redo (depending on the current state of it) Log4Net > to be on par with with Log4j 2.x in terms of architecture and features > (such as support for markers). > > Log4j is currently the most advanced and comprehensive logging framework, > so let's model the others after it. > > On Wed, Oct 19, 2016 at 3:36 AM, Nicholas Duane wrote: > > > But I'm not suggesting a code base that will run everywhere. As I said, > > I'm not talking about a single source code base. What I'm suggesting is > a > > single design/architecture which is then implemented across a set of > > runtimes/OS's. As opposed to what seems to be the case now where log4j > is > > its own team with it's own design and log4net, I guess, was originally a > > port of log4j but might be moving in its own direction. > > > > > > I suggested the same to the log4net team. And while it could be the case > > that I could help with the log4net effort, I would not be interested in > it > > going off in its own direction as I see a big benefit in having similar > > logging frameworks across Java and .NET. > > > > > > Thanks, > > > > Nick > > > > > > From: Ralph Goers > > Sent: Tuesday, October 18, 2016 8:08 PM > > To: Log4J Users List > > Subject: Re: porting log4j2 to .NET > > > > I feel lost because I don’t understand the concept of a code base that > > will run everywhere in any language. The run everywhere part is called > > “Java”. The run in any language part doesn’t exist as far as I know, let > > alone when combined with “run everywhere”. So I don’t know where that > part > > of the discussion is coming from. > > > > It would be possible to create implementations of the Log4j design in > > multiple languages, but we would need many more committers with skills in > > those various languages to do it. To be sure, I would love to see that > > happen, but it isn’t possible with the set of committers who actively > > contribute to the logging project today. If you are volunteering to kick > > that off we won’t get in your way. > > > > Ralph > > > > > > > > > On Oct 18, 2016, at 1:53 PM, Nicholas Duane wrote: > > > > > > Doesn't sound like you're too lost. Yes, plug-ins certainly is an area > > where the implementation will cause variations, in the config for > > instance. And with respect to asynchronous appenders, that might even > be a > > feature missing in some implementations if support for it would be too > > difficult. > > > > > > > > > By the way, thanks to everyone for putting up with my questions as I > try > > to work though the issues I have with our implementation. > > > > > > > > > Thanks, > > > > > > Nick > > > > > > > > > From: Ralph Goers mailto:ralph.goers@ > > dslextreme.com>> > > > Sent: Tuesday, October 18, 2016 4:25 PM > > > To: Log4J Users List > > > Subject: Re: porting log4j2 to .NET > > > > > > I’ve gotten completely lost in this conversation. > > > > > > The design certainly doesn’t need to know about the language, but > > certain design features have to be implementable. > > > > > > For example, to use the same configuration each implementation would > >
Re: porting log4j2 to .NET
That would be great. From what I recall, the two main log4net developers are pretty busy with other things now and can only provide some maintenance work on log4net. We have tweeted and blogged about this in the recent past looking for some new developers. I personally haven't used C# since college, and the .net framework has changed a lot since then, so I don't feel competent enough to spearhead a log4net2 or anything like that myself. On 19 October 2016 at 02:45, Mikael Ståldal wrote: > It seems to me that a (conceptually) simple and constructive way forward > would be to improve or redo (depending on the current state of it) Log4Net > to be on par with with Log4j 2.x in terms of architecture and features > (such as support for markers). > > Log4j is currently the most advanced and comprehensive logging framework, > so let's model the others after it. > > On Wed, Oct 19, 2016 at 3:36 AM, Nicholas Duane wrote: > > > But I'm not suggesting a code base that will run everywhere. As I said, > > I'm not talking about a single source code base. What I'm suggesting is > a > > single design/architecture which is then implemented across a set of > > runtimes/OS's. As opposed to what seems to be the case now where log4j > is > > its own team with it's own design and log4net, I guess, was originally a > > port of log4j but might be moving in its own direction. > > > > > > I suggested the same to the log4net team. And while it could be the case > > that I could help with the log4net effort, I would not be interested in > it > > going off in its own direction as I see a big benefit in having similar > > logging frameworks across Java and .NET. > > > > > > Thanks, > > > > Nick > > > > > > From: Ralph Goers > > Sent: Tuesday, October 18, 2016 8:08 PM > > To: Log4J Users List > > Subject: Re: porting log4j2 to .NET > > > > I feel lost because I don’t understand the concept of a code base that > > will run everywhere in any language. The run everywhere part is called > > “Java”. The run in any language part doesn’t exist as far as I know, let > > alone when combined with “run everywhere”. So I don’t know where that > part > > of the discussion is coming from. > > > > It would be possible to create implementations of the Log4j design in > > multiple languages, but we would need many more committers with skills in > > those various languages to do it. To be sure, I would love to see that > > happen, but it isn’t possible with the set of committers who actively > > contribute to the logging project today. If you are volunteering to kick > > that off we won’t get in your way. > > > > Ralph > > > > > > > > > On Oct 18, 2016, at 1:53 PM, Nicholas Duane wrote: > > > > > > Doesn't sound like you're too lost. Yes, plug-ins certainly is an area > > where the implementation will cause variations, in the config for > > instance. And with respect to asynchronous appenders, that might even > be a > > feature missing in some implementations if support for it would be too > > difficult. > > > > > > > > > By the way, thanks to everyone for putting up with my questions as I > try > > to work though the issues I have with our implementation. > > > > > > > > > Thanks, > > > > > > Nick > > > > > > > > > From: Ralph Goers mailto:ralph.goers@ > > dslextreme.com>> > > > Sent: Tuesday, October 18, 2016 4:25 PM > > > To: Log4J Users List > > > Subject: Re: porting log4j2 to .NET > > > > > > I’ve gotten completely lost in this conversation. > > > > > > The design certainly doesn’t need to know about the language, but > > certain design features have to be implementable. > > > > > > For example, to use the same configuration each implementation would > > have to support the plugin concept. The Java implementation relies upon > > annotations to do this. .NET has something similar but other languages > may > > not. Asynchronous Loggers take advantage of a highly optimized > concurrent > > queue. Although you might be able to create something equivalent in > other > > languages it might not scale as well. Then again, some languages don’t > > support multi-threading so either might require all loggers to be > > synchronous. > > > > > > Ralph > > > > > >> On Oct 18, 2016, at 10:22
Re: porting log4j2 to .NET
It seems to me that a (conceptually) simple and constructive way forward would be to improve or redo (depending on the current state of it) Log4Net to be on par with with Log4j 2.x in terms of architecture and features (such as support for markers). Log4j is currently the most advanced and comprehensive logging framework, so let's model the others after it. On Wed, Oct 19, 2016 at 3:36 AM, Nicholas Duane wrote: > But I'm not suggesting a code base that will run everywhere. As I said, > I'm not talking about a single source code base. What I'm suggesting is a > single design/architecture which is then implemented across a set of > runtimes/OS's. As opposed to what seems to be the case now where log4j is > its own team with it's own design and log4net, I guess, was originally a > port of log4j but might be moving in its own direction. > > > I suggested the same to the log4net team. And while it could be the case > that I could help with the log4net effort, I would not be interested in it > going off in its own direction as I see a big benefit in having similar > logging frameworks across Java and .NET. > > > Thanks, > > Nick > > > From: Ralph Goers > Sent: Tuesday, October 18, 2016 8:08 PM > To: Log4J Users List > Subject: Re: porting log4j2 to .NET > > I feel lost because I don’t understand the concept of a code base that > will run everywhere in any language. The run everywhere part is called > “Java”. The run in any language part doesn’t exist as far as I know, let > alone when combined with “run everywhere”. So I don’t know where that part > of the discussion is coming from. > > It would be possible to create implementations of the Log4j design in > multiple languages, but we would need many more committers with skills in > those various languages to do it. To be sure, I would love to see that > happen, but it isn’t possible with the set of committers who actively > contribute to the logging project today. If you are volunteering to kick > that off we won’t get in your way. > > Ralph > > > > > On Oct 18, 2016, at 1:53 PM, Nicholas Duane wrote: > > > > Doesn't sound like you're too lost. Yes, plug-ins certainly is an area > where the implementation will cause variations, in the config for > instance. And with respect to asynchronous appenders, that might even be a > feature missing in some implementations if support for it would be too > difficult. > > > > > > By the way, thanks to everyone for putting up with my questions as I try > to work though the issues I have with our implementation. > > > > > > Thanks, > > > > Nick > > > > > > From: Ralph Goers mailto:ralph.goers@ > dslextreme.com>> > > Sent: Tuesday, October 18, 2016 4:25 PM > > To: Log4J Users List > > Subject: Re: porting log4j2 to .NET > > > > I’ve gotten completely lost in this conversation. > > > > The design certainly doesn’t need to know about the language, but > certain design features have to be implementable. > > > > For example, to use the same configuration each implementation would > have to support the plugin concept. The Java implementation relies upon > annotations to do this. .NET has something similar but other languages may > not. Asynchronous Loggers take advantage of a highly optimized concurrent > queue. Although you might be able to create something equivalent in other > languages it might not scale as well. Then again, some languages don’t > support multi-threading so either might require all loggers to be > synchronous. > > > > Ralph > > > >> On Oct 18, 2016, at 10:22 AM, Nicholas Duane wrote: > >> > >> I guess I don't agree. And just to be clear, I'm not talking about > trying to have a huge percentage, or any at all really, of single source > and then glue code around it for the various runtimes/OS's you're targeting. > >> > >> > >> I'm not that familiar with log4j2 but I would assume you have: > >> > >> > >> * a core engine with accepts events and then runs them through some > checks before throwing them out or sending them along their way. > >> > >> > >> * seems the major abstraction is the appender. > >> > >> > >> * some other abstractions like filters and layouts. > >> > >> > >> * configuration > >> > >> > >> * an object model such that most, if not all, can be configured > programmatically > >> > >> > >> I'm sure ther
Re: porting log4j2 to .NET
A similar analogy might be EMS. EMS is a specification. There is a java implementation, JMS. I know TIBCO also has C/C++ and C# implementations on Windows. I think the C# one is a wrapper around their C/C++ implementation. I assume there is also a C/C++ implementation on Linux. Thanks, Nick From: Nicholas Duane Sent: Tuesday, October 18, 2016 9:36 PM To: Log4J Users List Subject: Re: porting log4j2 to .NET But I'm not suggesting a code base that will run everywhere. As I said, I'm not talking about a single source code base. What I'm suggesting is a single design/architecture which is then implemented across a set of runtimes/OS's. As opposed to what seems to be the case now where log4j is its own team with it's own design and log4net, I guess, was originally a port of log4j but might be moving in its own direction. I suggested the same to the log4net team. And while it could be the case that I could help with the log4net effort, I would not be interested in it going off in its own direction as I see a big benefit in having similar logging frameworks across Java and .NET. Thanks, Nick From: Ralph Goers Sent: Tuesday, October 18, 2016 8:08 PM To: Log4J Users List Subject: Re: porting log4j2 to .NET I feel lost because I don’t understand the concept of a code base that will run everywhere in any language. The run everywhere part is called “Java”. The run in any language part doesn’t exist as far as I know, let alone when combined with “run everywhere”. So I don’t know where that part of the discussion is coming from. It would be possible to create implementations of the Log4j design in multiple languages, but we would need many more committers with skills in those various languages to do it. To be sure, I would love to see that happen, but it isn’t possible with the set of committers who actively contribute to the logging project today. If you are volunteering to kick that off we won’t get in your way. Ralph > On Oct 18, 2016, at 1:53 PM, Nicholas Duane wrote: > > Doesn't sound like you're too lost. Yes, plug-ins certainly is an area where > the implementation will cause variations, in the config for instance. And > with respect to asynchronous appenders, that might even be a feature missing > in some implementations if support for it would be too difficult. > > > By the way, thanks to everyone for putting up with my questions as I try to > work though the issues I have with our implementation. > > > Thanks, > > Nick > > > From: Ralph Goers <mailto:ralph.go...@dslextreme.com>> > Sent: Tuesday, October 18, 2016 4:25 PM > To: Log4J Users List > Subject: Re: porting log4j2 to .NET > > I’ve gotten completely lost in this conversation. > > The design certainly doesn’t need to know about the language, but certain > design features have to be implementable. > > For example, to use the same configuration each implementation would have to > support the plugin concept. The Java implementation relies upon annotations > to do this. .NET has something similar but other languages may not. > Asynchronous Loggers take advantage of a highly optimized concurrent queue. > Although you might be able to create something equivalent in other languages > it might not scale as well. Then again, some languages don’t support > multi-threading so either might require all loggers to be synchronous. > > Ralph > >> On Oct 18, 2016, at 10:22 AM, Nicholas Duane wrote: >> >> I guess I don't agree. And just to be clear, I'm not talking about trying >> to have a huge percentage, or any at all really, of single source and then >> glue code around it for the various runtimes/OS's you're targeting. >> >> >> I'm not that familiar with log4j2 but I would assume you have: >> >> >> * a core engine with accepts events and then runs them through some checks >> before throwing them out or sending them along their way. >> >> >> * seems the major abstraction is the appender. >> >> >> * some other abstractions like filters and layouts. >> >> >> * configuration >> >> >> * an object model such that most, if not all, can be configured >> programmatically >> >> >> I'm sure there's some stuff I'm missing. Still not sure why most of the >> design for this has to know what runtime/language it's targeting. >> >> >> Thanks, >> >> Nick >> >> >> From: Matt Sicker mailto:boa...@gmail.com> >> <mailto:boa...@gmail.com <mailto:boa...
Re: porting log4j2 to .NET
But I'm not suggesting a code base that will run everywhere. As I said, I'm not talking about a single source code base. What I'm suggesting is a single design/architecture which is then implemented across a set of runtimes/OS's. As opposed to what seems to be the case now where log4j is its own team with it's own design and log4net, I guess, was originally a port of log4j but might be moving in its own direction. I suggested the same to the log4net team. And while it could be the case that I could help with the log4net effort, I would not be interested in it going off in its own direction as I see a big benefit in having similar logging frameworks across Java and .NET. Thanks, Nick From: Ralph Goers Sent: Tuesday, October 18, 2016 8:08 PM To: Log4J Users List Subject: Re: porting log4j2 to .NET I feel lost because I don’t understand the concept of a code base that will run everywhere in any language. The run everywhere part is called “Java”. The run in any language part doesn’t exist as far as I know, let alone when combined with “run everywhere”. So I don’t know where that part of the discussion is coming from. It would be possible to create implementations of the Log4j design in multiple languages, but we would need many more committers with skills in those various languages to do it. To be sure, I would love to see that happen, but it isn’t possible with the set of committers who actively contribute to the logging project today. If you are volunteering to kick that off we won’t get in your way. Ralph > On Oct 18, 2016, at 1:53 PM, Nicholas Duane wrote: > > Doesn't sound like you're too lost. Yes, plug-ins certainly is an area where > the implementation will cause variations, in the config for instance. And > with respect to asynchronous appenders, that might even be a feature missing > in some implementations if support for it would be too difficult. > > > By the way, thanks to everyone for putting up with my questions as I try to > work though the issues I have with our implementation. > > > Thanks, > > Nick > > > From: Ralph Goers <mailto:ralph.go...@dslextreme.com>> > Sent: Tuesday, October 18, 2016 4:25 PM > To: Log4J Users List > Subject: Re: porting log4j2 to .NET > > I’ve gotten completely lost in this conversation. > > The design certainly doesn’t need to know about the language, but certain > design features have to be implementable. > > For example, to use the same configuration each implementation would have to > support the plugin concept. The Java implementation relies upon annotations > to do this. .NET has something similar but other languages may not. > Asynchronous Loggers take advantage of a highly optimized concurrent queue. > Although you might be able to create something equivalent in other languages > it might not scale as well. Then again, some languages don’t support > multi-threading so either might require all loggers to be synchronous. > > Ralph > >> On Oct 18, 2016, at 10:22 AM, Nicholas Duane wrote: >> >> I guess I don't agree. And just to be clear, I'm not talking about trying >> to have a huge percentage, or any at all really, of single source and then >> glue code around it for the various runtimes/OS's you're targeting. >> >> >> I'm not that familiar with log4j2 but I would assume you have: >> >> >> * a core engine with accepts events and then runs them through some checks >> before throwing them out or sending them along their way. >> >> >> * seems the major abstraction is the appender. >> >> >> * some other abstractions like filters and layouts. >> >> >> * configuration >> >> >> * an object model such that most, if not all, can be configured >> programmatically >> >> >> I'm sure there's some stuff I'm missing. Still not sure why most of the >> design for this has to know what runtime/language it's targeting. >> >> >> Thanks, >> >> Nick >> >> >> From: Matt Sicker mailto:boa...@gmail.com> >> <mailto:boa...@gmail.com <mailto:boa...@gmail.com>>> >> Sent: Tuesday, October 18, 2016 12:22 PM >> To: Log4J Users List >> Subject: Re: porting log4j2 to .NET >> >> Really, the only portable-ish way to make a common framework would be to >> write them in C or Rust or something and make glue code for every runtime >> out there. JVM users tend to prefer Java-native libraries over >> JNI/JNA/whatever type libraries, and I'm
Re: porting log4j2 to .NET
I feel lost because I don’t understand the concept of a code base that will run everywhere in any language. The run everywhere part is called “Java”. The run in any language part doesn’t exist as far as I know, let alone when combined with “run everywhere”. So I don’t know where that part of the discussion is coming from. It would be possible to create implementations of the Log4j design in multiple languages, but we would need many more committers with skills in those various languages to do it. To be sure, I would love to see that happen, but it isn’t possible with the set of committers who actively contribute to the logging project today. If you are volunteering to kick that off we won’t get in your way. Ralph > On Oct 18, 2016, at 1:53 PM, Nicholas Duane wrote: > > Doesn't sound like you're too lost. Yes, plug-ins certainly is an area where > the implementation will cause variations, in the config for instance. And > with respect to asynchronous appenders, that might even be a feature missing > in some implementations if support for it would be too difficult. > > > By the way, thanks to everyone for putting up with my questions as I try to > work though the issues I have with our implementation. > > > Thanks, > > Nick > > > From: Ralph Goers <mailto:ralph.go...@dslextreme.com>> > Sent: Tuesday, October 18, 2016 4:25 PM > To: Log4J Users List > Subject: Re: porting log4j2 to .NET > > I’ve gotten completely lost in this conversation. > > The design certainly doesn’t need to know about the language, but certain > design features have to be implementable. > > For example, to use the same configuration each implementation would have to > support the plugin concept. The Java implementation relies upon annotations > to do this. .NET has something similar but other languages may not. > Asynchronous Loggers take advantage of a highly optimized concurrent queue. > Although you might be able to create something equivalent in other languages > it might not scale as well. Then again, some languages don’t support > multi-threading so either might require all loggers to be synchronous. > > Ralph > >> On Oct 18, 2016, at 10:22 AM, Nicholas Duane wrote: >> >> I guess I don't agree. And just to be clear, I'm not talking about trying >> to have a huge percentage, or any at all really, of single source and then >> glue code around it for the various runtimes/OS's you're targeting. >> >> >> I'm not that familiar with log4j2 but I would assume you have: >> >> >> * a core engine with accepts events and then runs them through some checks >> before throwing them out or sending them along their way. >> >> >> * seems the major abstraction is the appender. >> >> >> * some other abstractions like filters and layouts. >> >> >> * configuration >> >> >> * an object model such that most, if not all, can be configured >> programmatically >> >> >> I'm sure there's some stuff I'm missing. Still not sure why most of the >> design for this has to know what runtime/language it's targeting. >> >> >> Thanks, >> >> Nick >> >> >> From: Matt Sicker mailto:boa...@gmail.com> >> <mailto:boa...@gmail.com <mailto:boa...@gmail.com>>> >> Sent: Tuesday, October 18, 2016 12:22 PM >> To: Log4J Users List >> Subject: Re: porting log4j2 to .NET >> >> Really, the only portable-ish way to make a common framework would be to >> write them in C or Rust or something and make glue code for every runtime >> out there. JVM users tend to prefer Java-native libraries over >> JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some >> other runtimes. >> >> On 18 October 2016 at 10:11, Mikael Ståldal > <mailto:mikael.stal...@magine.com>> >> wrote: >> >>> In my opinion, one of the major benefits of Log4j is its comprehensive >>> ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party. >>> This will automatically benefit all users of Log4j, regardless of language >>> (on the JVM) and OS (that you can run the JVM on). But this does not extend >>> to other runtimes (e.g. .Net). >>> >>> Another benefit is that your application and 3rd party frameworks/libraries >>> you use can log via the same framework and you can collect the logs >>> together. This does not extend to other runtimes either, sinc
Re: porting log4j2 to .NET
Doesn't sound like you're too lost. Yes, plug-ins certainly is an area where the implementation will cause variations, in the config for instance. And with respect to asynchronous appenders, that might even be a feature missing in some implementations if support for it would be too difficult. By the way, thanks to everyone for putting up with my questions as I try to work though the issues I have with our implementation. Thanks, Nick From: Ralph Goers Sent: Tuesday, October 18, 2016 4:25 PM To: Log4J Users List Subject: Re: porting log4j2 to .NET I’ve gotten completely lost in this conversation. The design certainly doesn’t need to know about the language, but certain design features have to be implementable. For example, to use the same configuration each implementation would have to support the plugin concept. The Java implementation relies upon annotations to do this. .NET has something similar but other languages may not. Asynchronous Loggers take advantage of a highly optimized concurrent queue. Although you might be able to create something equivalent in other languages it might not scale as well. Then again, some languages don’t support multi-threading so either might require all loggers to be synchronous. Ralph > On Oct 18, 2016, at 10:22 AM, Nicholas Duane wrote: > > I guess I don't agree. And just to be clear, I'm not talking about trying to > have a huge percentage, or any at all really, of single source and then glue > code around it for the various runtimes/OS's you're targeting. > > > I'm not that familiar with log4j2 but I would assume you have: > > > * a core engine with accepts events and then runs them through some checks > before throwing them out or sending them along their way. > > > * seems the major abstraction is the appender. > > > * some other abstractions like filters and layouts. > > > * configuration > > > * an object model such that most, if not all, can be configured > programmatically > > > I'm sure there's some stuff I'm missing. Still not sure why most of the > design for this has to know what runtime/language it's targeting. > > > Thanks, > > Nick > > ____________ > From: Matt Sicker mailto:boa...@gmail.com>> > Sent: Tuesday, October 18, 2016 12:22 PM > To: Log4J Users List > Subject: Re: porting log4j2 to .NET > > Really, the only portable-ish way to make a common framework would be to > write them in C or Rust or something and make glue code for every runtime > out there. JVM users tend to prefer Java-native libraries over > JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some > other runtimes. > > On 18 October 2016 at 10:11, Mikael Ståldal > wrote: > >> In my opinion, one of the major benefits of Log4j is its comprehensive >> ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party. >> This will automatically benefit all users of Log4j, regardless of language >> (on the JVM) and OS (that you can run the JVM on). But this does not extend >> to other runtimes (e.g. .Net). >> >> Another benefit is that your application and 3rd party frameworks/libraries >> you use can log via the same framework and you can collect the logs >> together. This does not extend to other runtimes either, since you won't >> use the same libraries. >> >> On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker wrote: >> >>> I'm saying the architecture of the code depends on the language you're >>> using. Different design patterns apply to different languages, for >>> instance. A logging framework in Java and C# might be very similar, but >>> they'd look quite different from one written entirely in Clojure or F#. >> The >>> general concept of appenders, loggers, filters, etc., would all probably >>> apply, but the APIs would probably differ a lot. This would affect plugin >>> authors more than users of the library, but the only common things I >> could >>> see happening between different languages might be a similar API in a >>> Logger class or module. >>> >>> On 18 October 2016 at 09:45, Nicholas Duane wrote: >>> >>>> I just mentioned the config as one piece where I think it would be very >>>> useful to have similar, if not exactly the same, configs across >>>> implementations. I also realize that it might not be possible. >>>> >>>> >>>> So are you saying that when you get to designing a logging framework >> you >>>> first have to know what language/runtime
Re: porting log4j2 to .NET
I’ve gotten completely lost in this conversation. The design certainly doesn’t need to know about the language, but certain design features have to be implementable. For example, to use the same configuration each implementation would have to support the plugin concept. The Java implementation relies upon annotations to do this. .NET has something similar but other languages may not. Asynchronous Loggers take advantage of a highly optimized concurrent queue. Although you might be able to create something equivalent in other languages it might not scale as well. Then again, some languages don’t support multi-threading so either might require all loggers to be synchronous. Ralph > On Oct 18, 2016, at 10:22 AM, Nicholas Duane wrote: > > I guess I don't agree. And just to be clear, I'm not talking about trying to > have a huge percentage, or any at all really, of single source and then glue > code around it for the various runtimes/OS's you're targeting. > > > I'm not that familiar with log4j2 but I would assume you have: > > > * a core engine with accepts events and then runs them through some checks > before throwing them out or sending them along their way. > > > * seems the major abstraction is the appender. > > > * some other abstractions like filters and layouts. > > > * configuration > > > * an object model such that most, if not all, can be configured > programmatically > > > I'm sure there's some stuff I'm missing. Still not sure why most of the > design for this has to know what runtime/language it's targeting. > > > Thanks, > > Nick > > ____________________ > From: Matt Sicker mailto:boa...@gmail.com>> > Sent: Tuesday, October 18, 2016 12:22 PM > To: Log4J Users List > Subject: Re: porting log4j2 to .NET > > Really, the only portable-ish way to make a common framework would be to > write them in C or Rust or something and make glue code for every runtime > out there. JVM users tend to prefer Java-native libraries over > JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some > other runtimes. > > On 18 October 2016 at 10:11, Mikael Ståldal > wrote: > >> In my opinion, one of the major benefits of Log4j is its comprehensive >> ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party. >> This will automatically benefit all users of Log4j, regardless of language >> (on the JVM) and OS (that you can run the JVM on). But this does not extend >> to other runtimes (e.g. .Net). >> >> Another benefit is that your application and 3rd party frameworks/libraries >> you use can log via the same framework and you can collect the logs >> together. This does not extend to other runtimes either, since you won't >> use the same libraries. >> >> On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker wrote: >> >>> I'm saying the architecture of the code depends on the language you're >>> using. Different design patterns apply to different languages, for >>> instance. A logging framework in Java and C# might be very similar, but >>> they'd look quite different from one written entirely in Clojure or F#. >> The >>> general concept of appenders, loggers, filters, etc., would all probably >>> apply, but the APIs would probably differ a lot. This would affect plugin >>> authors more than users of the library, but the only common things I >> could >>> see happening between different languages might be a similar API in a >>> Logger class or module. >>> >>> On 18 October 2016 at 09:45, Nicholas Duane wrote: >>> >>>> I just mentioned the config as one piece where I think it would be very >>>> useful to have similar, if not exactly the same, configs across >>>> implementations. I also realize that it might not be possible. >>>> >>>> >>>> So are you saying that when you get to designing a logging framework >> you >>>> first have to know what language/runtime you're designing it for? I >>> would >>>> think not. Hopefully most, if not all, can be designed OS/runtime >>> agnostic >>>> and without having to design to a lowest common denominator. >>>> >>>> >>>> Also not sure about the OOP thing. As far as I can tell, OOP is just a >>>> convenience thing, syntactic sugar. I believe you can do the same in a >>>> procedural language. >>>> >>>> >>>> Thanks, >>>>
Re: porting log4j2 to .NET
I guess I don't agree. And just to be clear, I'm not talking about trying to have a huge percentage, or any at all really, of single source and then glue code around it for the various runtimes/OS's you're targeting. I'm not that familiar with log4j2 but I would assume you have: * a core engine with accepts events and then runs them through some checks before throwing them out or sending them along their way. * seems the major abstraction is the appender. * some other abstractions like filters and layouts. * configuration * an object model such that most, if not all, can be configured programmatically I'm sure there's some stuff I'm missing. Still not sure why most of the design for this has to know what runtime/language it's targeting. Thanks, Nick From: Matt Sicker Sent: Tuesday, October 18, 2016 12:22 PM To: Log4J Users List Subject: Re: porting log4j2 to .NET Really, the only portable-ish way to make a common framework would be to write them in C or Rust or something and make glue code for every runtime out there. JVM users tend to prefer Java-native libraries over JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some other runtimes. On 18 October 2016 at 10:11, Mikael Ståldal wrote: > In my opinion, one of the major benefits of Log4j is its comprehensive > ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party. > This will automatically benefit all users of Log4j, regardless of language > (on the JVM) and OS (that you can run the JVM on). But this does not extend > to other runtimes (e.g. .Net). > > Another benefit is that your application and 3rd party frameworks/libraries > you use can log via the same framework and you can collect the logs > together. This does not extend to other runtimes either, since you won't > use the same libraries. > > On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker wrote: > > > I'm saying the architecture of the code depends on the language you're > > using. Different design patterns apply to different languages, for > > instance. A logging framework in Java and C# might be very similar, but > > they'd look quite different from one written entirely in Clojure or F#. > The > > general concept of appenders, loggers, filters, etc., would all probably > > apply, but the APIs would probably differ a lot. This would affect plugin > > authors more than users of the library, but the only common things I > could > > see happening between different languages might be a similar API in a > > Logger class or module. > > > > On 18 October 2016 at 09:45, Nicholas Duane wrote: > > > > > I just mentioned the config as one piece where I think it would be very > > > useful to have similar, if not exactly the same, configs across > > > implementations. I also realize that it might not be possible. > > > > > > > > > So are you saying that when you get to designing a logging framework > you > > > first have to know what language/runtime you're designing it for? I > > would > > > think not. Hopefully most, if not all, can be designed OS/runtime > > agnostic > > > and without having to design to a lowest common denominator. > > > > > > > > > Also not sure about the OOP thing. As far as I can tell, OOP is just a > > > convenience thing, syntactic sugar. I believe you can do the same in a > > > procedural language. > > > > > > > > > Thanks, > > > > > > Nick > > > > > > > > > From: Matt Sicker > > > Sent: Tuesday, October 18, 2016 10:37 AM > > > To: Log4J Users List > > > Subject: Re: porting log4j2 to .NET > > > > > > Every programming language has its own idioms, and that even goes for > all > > > the various JVM languages as demonstrated by the log4j-scala API. > Unless > > > you mean more of an architectural thing with a similar config format, > > then > > > that might be more possible, but even that relies on a language being > > > mostly OOP or mostly procedural or mostly functional or some other > exotic > > > thing. > > > > > > On 18 October 2016 at 09:23, Nicholas Duane wrote: > > > > > > > I agree. I'm also one for not coding to the lowest common > denominator. > > > > That's one reason we're not using a logging facade as I assume with a > > > > facade you get only the features that are common across the set of > > > logging > > > > framewor
Re: porting log4j2 to .NET
There is also the idea of IDL from CORBA and type libraries in the MS world where you can generate language bindings, then you are left to implement the stubs. Gary On Tue, Oct 18, 2016 at 9:22 AM, Matt Sicker wrote: > Really, the only portable-ish way to make a common framework would be to > write them in C or Rust or something and make glue code for every runtime > out there. JVM users tend to prefer Java-native libraries over > JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some > other runtimes. > > On 18 October 2016 at 10:11, Mikael Ståldal > wrote: > > > In my opinion, one of the major benefits of Log4j is its comprehensive > > ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd > party. > > This will automatically benefit all users of Log4j, regardless of > language > > (on the JVM) and OS (that you can run the JVM on). But this does not > extend > > to other runtimes (e.g. .Net). > > > > Another benefit is that your application and 3rd party > frameworks/libraries > > you use can log via the same framework and you can collect the logs > > together. This does not extend to other runtimes either, since you won't > > use the same libraries. > > > > On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker wrote: > > > > > I'm saying the architecture of the code depends on the language you're > > > using. Different design patterns apply to different languages, for > > > instance. A logging framework in Java and C# might be very similar, but > > > they'd look quite different from one written entirely in Clojure or F#. > > The > > > general concept of appenders, loggers, filters, etc., would all > probably > > > apply, but the APIs would probably differ a lot. This would affect > plugin > > > authors more than users of the library, but the only common things I > > could > > > see happening between different languages might be a similar API in a > > > Logger class or module. > > > > > > On 18 October 2016 at 09:45, Nicholas Duane wrote: > > > > > > > I just mentioned the config as one piece where I think it would be > very > > > > useful to have similar, if not exactly the same, configs across > > > > implementations. I also realize that it might not be possible. > > > > > > > > > > > > So are you saying that when you get to designing a logging framework > > you > > > > first have to know what language/runtime you're designing it for? I > > > would > > > > think not. Hopefully most, if not all, can be designed OS/runtime > > > agnostic > > > > and without having to design to a lowest common denominator. > > > > > > > > > > > > Also not sure about the OOP thing. As far as I can tell, OOP is > just a > > > > convenience thing, syntactic sugar. I believe you can do the same > in a > > > > procedural language. > > > > > > > > > > > > Thanks, > > > > > > > > Nick > > > > > > > > > > > > From: Matt Sicker > > > > Sent: Tuesday, October 18, 2016 10:37 AM > > > > To: Log4J Users List > > > > Subject: Re: porting log4j2 to .NET > > > > > > > > Every programming language has its own idioms, and that even goes for > > all > > > > the various JVM languages as demonstrated by the log4j-scala API. > > Unless > > > > you mean more of an architectural thing with a similar config format, > > > then > > > > that might be more possible, but even that relies on a language being > > > > mostly OOP or mostly procedural or mostly functional or some other > > exotic > > > > thing. > > > > > > > > On 18 October 2016 at 09:23, Nicholas Duane wrote: > > > > > > > > > I agree. I'm also one for not coding to the lowest common > > denominator. > > > > > That's one reason we're not using a logging facade as I assume > with a > > > > > facade you get only the features that are common across the set of > > > > logging > > > > > frameworks the facade supports. > > > > > > > > > > > > > > > What I'm suggesting is to come up with a design and architecture > > which > > > is > > > > > language/runtime/OS agnostic. While it's easy for me to s
Re: porting log4j2 to .NET
Really, the only portable-ish way to make a common framework would be to write them in C or Rust or something and make glue code for every runtime out there. JVM users tend to prefer Java-native libraries over JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some other runtimes. On 18 October 2016 at 10:11, Mikael Ståldal wrote: > In my opinion, one of the major benefits of Log4j is its comprehensive > ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party. > This will automatically benefit all users of Log4j, regardless of language > (on the JVM) and OS (that you can run the JVM on). But this does not extend > to other runtimes (e.g. .Net). > > Another benefit is that your application and 3rd party frameworks/libraries > you use can log via the same framework and you can collect the logs > together. This does not extend to other runtimes either, since you won't > use the same libraries. > > On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker wrote: > > > I'm saying the architecture of the code depends on the language you're > > using. Different design patterns apply to different languages, for > > instance. A logging framework in Java and C# might be very similar, but > > they'd look quite different from one written entirely in Clojure or F#. > The > > general concept of appenders, loggers, filters, etc., would all probably > > apply, but the APIs would probably differ a lot. This would affect plugin > > authors more than users of the library, but the only common things I > could > > see happening between different languages might be a similar API in a > > Logger class or module. > > > > On 18 October 2016 at 09:45, Nicholas Duane wrote: > > > > > I just mentioned the config as one piece where I think it would be very > > > useful to have similar, if not exactly the same, configs across > > > implementations. I also realize that it might not be possible. > > > > > > > > > So are you saying that when you get to designing a logging framework > you > > > first have to know what language/runtime you're designing it for? I > > would > > > think not. Hopefully most, if not all, can be designed OS/runtime > > agnostic > > > and without having to design to a lowest common denominator. > > > > > > > > > Also not sure about the OOP thing. As far as I can tell, OOP is just a > > > convenience thing, syntactic sugar. I believe you can do the same in a > > > procedural language. > > > > > > > > > Thanks, > > > > > > Nick > > > > > > > > > From: Matt Sicker > > > Sent: Tuesday, October 18, 2016 10:37 AM > > > To: Log4J Users List > > > Subject: Re: porting log4j2 to .NET > > > > > > Every programming language has its own idioms, and that even goes for > all > > > the various JVM languages as demonstrated by the log4j-scala API. > Unless > > > you mean more of an architectural thing with a similar config format, > > then > > > that might be more possible, but even that relies on a language being > > > mostly OOP or mostly procedural or mostly functional or some other > exotic > > > thing. > > > > > > On 18 October 2016 at 09:23, Nicholas Duane wrote: > > > > > > > I agree. I'm also one for not coding to the lowest common > denominator. > > > > That's one reason we're not using a logging facade as I assume with a > > > > facade you get only the features that are common across the set of > > > logging > > > > frameworks the facade supports. > > > > > > > > > > > > What I'm suggesting is to come up with a design and architecture > which > > is > > > > language/runtime/OS agnostic. While it's easy for me to say that I > > > > wouldn't be surprised if it's more difficult to achieve. When it > comes > > > to > > > > implementation I would assume the features might manifest themselves > in > > > > different ways across the different languages/runtimes/OS's. For > > > instance, > > > > .NET has extension methods and Java doesn't. You might decide to > > > implement > > > > some features in .NET using extension methods and in Java you'll have > > to > > > > pick a different way to implement. Configuration might be another > area > > > > where there are differences amon
Re: porting log4j2 to .NET
In my opinion, one of the major benefits of Log4j is its comprehensive ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party. This will automatically benefit all users of Log4j, regardless of language (on the JVM) and OS (that you can run the JVM on). But this does not extend to other runtimes (e.g. .Net). Another benefit is that your application and 3rd party frameworks/libraries you use can log via the same framework and you can collect the logs together. This does not extend to other runtimes either, since you won't use the same libraries. On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker wrote: > I'm saying the architecture of the code depends on the language you're > using. Different design patterns apply to different languages, for > instance. A logging framework in Java and C# might be very similar, but > they'd look quite different from one written entirely in Clojure or F#. The > general concept of appenders, loggers, filters, etc., would all probably > apply, but the APIs would probably differ a lot. This would affect plugin > authors more than users of the library, but the only common things I could > see happening between different languages might be a similar API in a > Logger class or module. > > On 18 October 2016 at 09:45, Nicholas Duane wrote: > > > I just mentioned the config as one piece where I think it would be very > > useful to have similar, if not exactly the same, configs across > > implementations. I also realize that it might not be possible. > > > > > > So are you saying that when you get to designing a logging framework you > > first have to know what language/runtime you're designing it for? I > would > > think not. Hopefully most, if not all, can be designed OS/runtime > agnostic > > and without having to design to a lowest common denominator. > > > > > > Also not sure about the OOP thing. As far as I can tell, OOP is just a > > convenience thing, syntactic sugar. I believe you can do the same in a > > procedural language. > > > > > > Thanks, > > > > Nick > > > > > > From: Matt Sicker > > Sent: Tuesday, October 18, 2016 10:37 AM > > To: Log4J Users List > > Subject: Re: porting log4j2 to .NET > > > > Every programming language has its own idioms, and that even goes for all > > the various JVM languages as demonstrated by the log4j-scala API. Unless > > you mean more of an architectural thing with a similar config format, > then > > that might be more possible, but even that relies on a language being > > mostly OOP or mostly procedural or mostly functional or some other exotic > > thing. > > > > On 18 October 2016 at 09:23, Nicholas Duane wrote: > > > > > I agree. I'm also one for not coding to the lowest common denominator. > > > That's one reason we're not using a logging facade as I assume with a > > > facade you get only the features that are common across the set of > > logging > > > frameworks the facade supports. > > > > > > > > > What I'm suggesting is to come up with a design and architecture which > is > > > language/runtime/OS agnostic. While it's easy for me to say that I > > > wouldn't be surprised if it's more difficult to achieve. When it comes > > to > > > implementation I would assume the features might manifest themselves in > > > different ways across the different languages/runtimes/OS's. For > > instance, > > > .NET has extension methods and Java doesn't. You might decide to > > implement > > > some features in .NET using extension methods and in Java you'll have > to > > > pick a different way to implement. Configuration might be another area > > > where there are differences among the different runtimes and thus the > > > implementation might be a bit different. Maybe there's even a feature > > that > > > one implementation has that others don't just because there is no way, > or > > > no easy enough way to implement. > > > > > > > > > Thanks, > > > > > > Nick > > > > > > > > > From: Mikael Ståldal > > > Sent: Tuesday, October 18, 2016 10:04 AM > > > To: Log4J Users List > > > Subject: Re: porting log4j2 to .NET > > > > > > Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what > > language > > > you run on the JVM (Java, Scala, Groovy, Clojure, etc). > > > > > >
Re: porting log4j2 to .NET
I'm saying the architecture of the code depends on the language you're using. Different design patterns apply to different languages, for instance. A logging framework in Java and C# might be very similar, but they'd look quite different from one written entirely in Clojure or F#. The general concept of appenders, loggers, filters, etc., would all probably apply, but the APIs would probably differ a lot. This would affect plugin authors more than users of the library, but the only common things I could see happening between different languages might be a similar API in a Logger class or module. On 18 October 2016 at 09:45, Nicholas Duane wrote: > I just mentioned the config as one piece where I think it would be very > useful to have similar, if not exactly the same, configs across > implementations. I also realize that it might not be possible. > > > So are you saying that when you get to designing a logging framework you > first have to know what language/runtime you're designing it for? I would > think not. Hopefully most, if not all, can be designed OS/runtime agnostic > and without having to design to a lowest common denominator. > > > Also not sure about the OOP thing. As far as I can tell, OOP is just a > convenience thing, syntactic sugar. I believe you can do the same in a > procedural language. > > > Thanks, > > Nick > > > From: Matt Sicker > Sent: Tuesday, October 18, 2016 10:37 AM > To: Log4J Users List > Subject: Re: porting log4j2 to .NET > > Every programming language has its own idioms, and that even goes for all > the various JVM languages as demonstrated by the log4j-scala API. Unless > you mean more of an architectural thing with a similar config format, then > that might be more possible, but even that relies on a language being > mostly OOP or mostly procedural or mostly functional or some other exotic > thing. > > On 18 October 2016 at 09:23, Nicholas Duane wrote: > > > I agree. I'm also one for not coding to the lowest common denominator. > > That's one reason we're not using a logging facade as I assume with a > > facade you get only the features that are common across the set of > logging > > frameworks the facade supports. > > > > > > What I'm suggesting is to come up with a design and architecture which is > > language/runtime/OS agnostic. While it's easy for me to say that I > > wouldn't be surprised if it's more difficult to achieve. When it comes > to > > implementation I would assume the features might manifest themselves in > > different ways across the different languages/runtimes/OS's. For > instance, > > .NET has extension methods and Java doesn't. You might decide to > implement > > some features in .NET using extension methods and in Java you'll have to > > pick a different way to implement. Configuration might be another area > > where there are differences among the different runtimes and thus the > > implementation might be a bit different. Maybe there's even a feature > that > > one implementation has that others don't just because there is no way, or > > no easy enough way to implement. > > > > > > Thanks, > > > > Nick > > > > > > From: Mikael Ståldal > > Sent: Tuesday, October 18, 2016 10:04 AM > > To: Log4J Users List > > Subject: Re: porting log4j2 to .NET > > > > Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what > language > > you run on the JVM (Java, Scala, Groovy, Clojure, etc). > > > > I guess it would be nice to have similar logging framework for other > > runtimes (such as .Net). However, I would not like to constrain Log4j to > > only use features available on both JVM and .Net. > > > > On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane wrote: > > > > > I guess platform is vague. Maybe I should have said language agnostic. > > > It would be nice to have a single logging architecture/design run on > > C/C++, > > > .NET, Java, etc. Or at least it seems like a nice feature to me. I > > would > > > assume there are many enterprises out there that have applications > > running > > > on different OS's and languages. If I'm trying to pick a logging > > framework > > > to use and I find a popular one which is capable and runs similarly > > across > > > the OS's and languages then that's a big plus in my mind. > > > > > > > > > Thanks, > > > > > > Nick > > > >
Re: porting log4j2 to .NET
I just mentioned the config as one piece where I think it would be very useful to have similar, if not exactly the same, configs across implementations. I also realize that it might not be possible. So are you saying that when you get to designing a logging framework you first have to know what language/runtime you're designing it for? I would think not. Hopefully most, if not all, can be designed OS/runtime agnostic and without having to design to a lowest common denominator. Also not sure about the OOP thing. As far as I can tell, OOP is just a convenience thing, syntactic sugar. I believe you can do the same in a procedural language. Thanks, Nick From: Matt Sicker Sent: Tuesday, October 18, 2016 10:37 AM To: Log4J Users List Subject: Re: porting log4j2 to .NET Every programming language has its own idioms, and that even goes for all the various JVM languages as demonstrated by the log4j-scala API. Unless you mean more of an architectural thing with a similar config format, then that might be more possible, but even that relies on a language being mostly OOP or mostly procedural or mostly functional or some other exotic thing. On 18 October 2016 at 09:23, Nicholas Duane wrote: > I agree. I'm also one for not coding to the lowest common denominator. > That's one reason we're not using a logging facade as I assume with a > facade you get only the features that are common across the set of logging > frameworks the facade supports. > > > What I'm suggesting is to come up with a design and architecture which is > language/runtime/OS agnostic. While it's easy for me to say that I > wouldn't be surprised if it's more difficult to achieve. When it comes to > implementation I would assume the features might manifest themselves in > different ways across the different languages/runtimes/OS's. For instance, > .NET has extension methods and Java doesn't. You might decide to implement > some features in .NET using extension methods and in Java you'll have to > pick a different way to implement. Configuration might be another area > where there are differences among the different runtimes and thus the > implementation might be a bit different. Maybe there's even a feature that > one implementation has that others don't just because there is no way, or > no easy enough way to implement. > > > Thanks, > > Nick > > ____________ > From: Mikael Ståldal > Sent: Tuesday, October 18, 2016 10:04 AM > To: Log4J Users List > Subject: Re: porting log4j2 to .NET > > Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what language > you run on the JVM (Java, Scala, Groovy, Clojure, etc). > > I guess it would be nice to have similar logging framework for other > runtimes (such as .Net). However, I would not like to constrain Log4j to > only use features available on both JVM and .Net. > > On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane wrote: > > > I guess platform is vague. Maybe I should have said language agnostic. > > It would be nice to have a single logging architecture/design run on > C/C++, > > .NET, Java, etc. Or at least it seems like a nice feature to me. I > would > > assume there are many enterprises out there that have applications > running > > on different OS's and languages. If I'm trying to pick a logging > framework > > to use and I find a popular one which is capable and runs similarly > across > > the OS's and languages then that's a big plus in my mind. > > > > > > Thanks, > > > > Nick > > > > > > From: Mikael Ståldal > > Sent: Tuesday, October 18, 2016 2:52 AM > > To: Log4J Users List > > Subject: Re: porting log4j2 to .NET > > > > Just to make things clear, Log4j is a logging framework for the JVM > > platform, and it is agnostic to the underlying OS. It it well tested on > (at > > least) both Linux and Windows. > > > > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane wrote: > > > > > Figured I would send this question out to the log4j side. I have > already > > > had some email exchanges with the log4net mailing list regarding > porting > > > log4j2 to .NET. My suggestion was that the apache logging framework > be a > > > single architecture design which is platform agnostic and then teams > > which > > > port to the different platforms. It seems log4net was a port of log4j > > and > > > may be going off in its own direction from that initial port. My > > viewpoint > > > is that's a bad idea as one of the be
Re: porting log4j2 to .NET
Every programming language has its own idioms, and that even goes for all the various JVM languages as demonstrated by the log4j-scala API. Unless you mean more of an architectural thing with a similar config format, then that might be more possible, but even that relies on a language being mostly OOP or mostly procedural or mostly functional or some other exotic thing. On 18 October 2016 at 09:23, Nicholas Duane wrote: > I agree. I'm also one for not coding to the lowest common denominator. > That's one reason we're not using a logging facade as I assume with a > facade you get only the features that are common across the set of logging > frameworks the facade supports. > > > What I'm suggesting is to come up with a design and architecture which is > language/runtime/OS agnostic. While it's easy for me to say that I > wouldn't be surprised if it's more difficult to achieve. When it comes to > implementation I would assume the features might manifest themselves in > different ways across the different languages/runtimes/OS's. For instance, > .NET has extension methods and Java doesn't. You might decide to implement > some features in .NET using extension methods and in Java you'll have to > pick a different way to implement. Configuration might be another area > where there are differences among the different runtimes and thus the > implementation might be a bit different. Maybe there's even a feature that > one implementation has that others don't just because there is no way, or > no easy enough way to implement. > > > Thanks, > > Nick > > ____________________ > From: Mikael Ståldal > Sent: Tuesday, October 18, 2016 10:04 AM > To: Log4J Users List > Subject: Re: porting log4j2 to .NET > > Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what language > you run on the JVM (Java, Scala, Groovy, Clojure, etc). > > I guess it would be nice to have similar logging framework for other > runtimes (such as .Net). However, I would not like to constrain Log4j to > only use features available on both JVM and .Net. > > On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane wrote: > > > I guess platform is vague. Maybe I should have said language agnostic. > > It would be nice to have a single logging architecture/design run on > C/C++, > > .NET, Java, etc. Or at least it seems like a nice feature to me. I > would > > assume there are many enterprises out there that have applications > running > > on different OS's and languages. If I'm trying to pick a logging > framework > > to use and I find a popular one which is capable and runs similarly > across > > the OS's and languages then that's a big plus in my mind. > > > > > > Thanks, > > > > Nick > > > > > > From: Mikael Ståldal > > Sent: Tuesday, October 18, 2016 2:52 AM > > To: Log4J Users List > > Subject: Re: porting log4j2 to .NET > > > > Just to make things clear, Log4j is a logging framework for the JVM > > platform, and it is agnostic to the underlying OS. It it well tested on > (at > > least) both Linux and Windows. > > > > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane wrote: > > > > > Figured I would send this question out to the log4j side. I have > already > > > had some email exchanges with the log4net mailing list regarding > porting > > > log4j2 to .NET. My suggestion was that the apache logging framework > be a > > > single architecture design which is platform agnostic and then teams > > which > > > port to the different platforms. It seems log4net was a port of log4j > > and > > > may be going off in its own direction from that initial port. My > > viewpoint > > > is that's a bad idea as one of the benefits I saw was that log4net was > > > similar to log4j2 and we're looking for logging frameworks for our > > > enterprise. We have applications on both Windows/.NET and Linux/Java > so > > > having a logging framework for Windows/.NET which is similar to a > logging > > > framework for Linux/Java was a big plus. > > > > > > > > > While I have no doubt the effort to port log4j2 to .NET is > considerable, > > > it would be a port and thus I'm not spending time figuring out design > and > > > algorithms. Would anyone want to venture a guess at what that effort > > might > > > be? > > > > > > > > > Thanks, > > > > > > Nick > > > > > > > > >
Re: porting log4j2 to .NET
I did look a bit into syslog. That appeared to be the defacto standard for logging, though it also seems that many just write to their own log files. The other constraint we had was working in a PaaS environment and thus writing to local disk might not be possible. While I'm not sure whether we're going to be running in a PaaS environment, that's what was in the back of our minds as we were developing the solution. We wrote a unix domain socket appender which we use to send events to a daemon we have running. This daemon buffers events in memory and when the buffer is full it compresses it and sends it via http to one of our endpoints. Thanks, Nick From: Mikael Ståldal Sent: Tuesday, October 18, 2016 10:06 AM To: Log4J Users List Subject: Re: porting log4j2 to .NET ...or a standardized non-binary format (like GELF, JSON based). On Tue, Oct 18, 2016 at 3:58 PM, Matt Sicker wrote: > Using syslog is a pretty standard way to collect logs from all sorts of > programs and goes back decades. There has been an update to the syslog > format in RFC 5424 which fleshes it out a bunch. > > Then there are programs like Logstash and Flume which can be used in a more > platform-agnostic manner to collect logs from different applications. > > Really, when it comes down to it, the most standard way you can log > everything regardless of programming language is to use log files or some > sort of network appender using a standardized binary format. > > On 18 October 2016 at 08:53, Nicholas Duane wrote: > > > I guess platform is vague. Maybe I should have said language agnostic. > > It would be nice to have a single logging architecture/design run on > C/C++, > > .NET, Java, etc. Or at least it seems like a nice feature to me. I > would > > assume there are many enterprises out there that have applications > running > > on different OS's and languages. If I'm trying to pick a logging > framework > > to use and I find a popular one which is capable and runs similarly > across > > the OS's and languages then that's a big plus in my mind. > > > > > > Thanks, > > > > Nick > > > > > > From: Mikael Ståldal > > Sent: Tuesday, October 18, 2016 2:52 AM > > To: Log4J Users List > > Subject: Re: porting log4j2 to .NET > > > > Just to make things clear, Log4j is a logging framework for the JVM > > platform, and it is agnostic to the underlying OS. It it well tested on > (at > > least) both Linux and Windows. > > > > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane wrote: > > > > > Figured I would send this question out to the log4j side. I have > already > > > had some email exchanges with the log4net mailing list regarding > porting > > > log4j2 to .NET. My suggestion was that the apache logging framework > be a > > > single architecture design which is platform agnostic and then teams > > which > > > port to the different platforms. It seems log4net was a port of log4j > > and > > > may be going off in its own direction from that initial port. My > > viewpoint > > > is that's a bad idea as one of the benefits I saw was that log4net was > > > similar to log4j2 and we're looking for logging frameworks for our > > > enterprise. We have applications on both Windows/.NET and Linux/Java > so > > > having a logging framework for Windows/.NET which is similar to a > logging > > > framework for Linux/Java was a big plus. > > > > > > > > > While I have no doubt the effort to port log4j2 to .NET is > considerable, > > > it would be a port and thus I'm not spending time figuring out design > and > > > algorithms. Would anyone want to venture a guess at what that effort > > might > > > be? > > > > > > > > > Thanks, > > > > > > Nick > > > > > > > > > > > -- > > [image: MagineTV] > > > > *Mikael Ståldal* > > Senior software developer > > > > *Magine TV* > > mikael.stal...@magine.com > > Grev Turegatan 3 | 114 46 Stockholm, Sweden | > > www.magine.com<<http://www.magine.com<> > > http://www.magine.com> > > [https://de.magine.com/content/uploads/2016/09/magine_global_social.png > ]< > > http://www.magine.com/> > > > > TV online with Magine TV<http://www.magine.com/> > > www.magine.com<http://www.magine.com> > > Watch the TV you love, on any device, anywhere in Germany and Sweden and > >
Re: porting log4j2 to .NET
I agree. I'm also one for not coding to the lowest common denominator. That's one reason we're not using a logging facade as I assume with a facade you get only the features that are common across the set of logging frameworks the facade supports. What I'm suggesting is to come up with a design and architecture which is language/runtime/OS agnostic. While it's easy for me to say that I wouldn't be surprised if it's more difficult to achieve. When it comes to implementation I would assume the features might manifest themselves in different ways across the different languages/runtimes/OS's. For instance, .NET has extension methods and Java doesn't. You might decide to implement some features in .NET using extension methods and in Java you'll have to pick a different way to implement. Configuration might be another area where there are differences among the different runtimes and thus the implementation might be a bit different. Maybe there's even a feature that one implementation has that others don't just because there is no way, or no easy enough way to implement. Thanks, Nick From: Mikael Ståldal Sent: Tuesday, October 18, 2016 10:04 AM To: Log4J Users List Subject: Re: porting log4j2 to .NET Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what language you run on the JVM (Java, Scala, Groovy, Clojure, etc). I guess it would be nice to have similar logging framework for other runtimes (such as .Net). However, I would not like to constrain Log4j to only use features available on both JVM and .Net. On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane wrote: > I guess platform is vague. Maybe I should have said language agnostic. > It would be nice to have a single logging architecture/design run on C/C++, > .NET, Java, etc. Or at least it seems like a nice feature to me. I would > assume there are many enterprises out there that have applications running > on different OS's and languages. If I'm trying to pick a logging framework > to use and I find a popular one which is capable and runs similarly across > the OS's and languages then that's a big plus in my mind. > > > Thanks, > > Nick > > ____________ > From: Mikael Ståldal > Sent: Tuesday, October 18, 2016 2:52 AM > To: Log4J Users List > Subject: Re: porting log4j2 to .NET > > Just to make things clear, Log4j is a logging framework for the JVM > platform, and it is agnostic to the underlying OS. It it well tested on (at > least) both Linux and Windows. > > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane wrote: > > > Figured I would send this question out to the log4j side. I have already > > had some email exchanges with the log4net mailing list regarding porting > > log4j2 to .NET. My suggestion was that the apache logging framework be a > > single architecture design which is platform agnostic and then teams > which > > port to the different platforms. It seems log4net was a port of log4j > and > > may be going off in its own direction from that initial port. My > viewpoint > > is that's a bad idea as one of the benefits I saw was that log4net was > > similar to log4j2 and we're looking for logging frameworks for our > > enterprise. We have applications on both Windows/.NET and Linux/Java so > > having a logging framework for Windows/.NET which is similar to a logging > > framework for Linux/Java was a big plus. > > > > > > While I have no doubt the effort to port log4j2 to .NET is considerable, > > it would be a port and thus I'm not spending time figuring out design and > > algorithms. Would anyone want to venture a guess at what that effort > might > > be? > > > > > > Thanks, > > > > Nick > > > > > > -- > [image: MagineTV] > > *Mikael Ståldal* > Senior software developer > > *Magine TV* > mikael.stal...@magine.com > Grev Turegatan 3 | 114 46 Stockholm, Sweden | > www.magine.com<<http://www.magine.com<> > http://www.magine.com> > [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]< > http://www.magine.com/> > > TV online with Magine TV<http://www.magine.com/> > www.magine.com<http://www.magine.com> > Watch the TV you love, on any device, anywhere in Germany and Sweden and > find out more about our global OTT B2B solutions. Get started today. > > > > Privileged and/or Confidential Information may be contained in this > message. If you are not the addressee indicated in this message > (or responsible for delivery of the message to such a person), you may not > copy or deliver this message
Re: porting log4j2 to .NET
...or a standardized non-binary format (like GELF, JSON based). On Tue, Oct 18, 2016 at 3:58 PM, Matt Sicker wrote: > Using syslog is a pretty standard way to collect logs from all sorts of > programs and goes back decades. There has been an update to the syslog > format in RFC 5424 which fleshes it out a bunch. > > Then there are programs like Logstash and Flume which can be used in a more > platform-agnostic manner to collect logs from different applications. > > Really, when it comes down to it, the most standard way you can log > everything regardless of programming language is to use log files or some > sort of network appender using a standardized binary format. > > On 18 October 2016 at 08:53, Nicholas Duane wrote: > > > I guess platform is vague. Maybe I should have said language agnostic. > > It would be nice to have a single logging architecture/design run on > C/C++, > > .NET, Java, etc. Or at least it seems like a nice feature to me. I > would > > assume there are many enterprises out there that have applications > running > > on different OS's and languages. If I'm trying to pick a logging > framework > > to use and I find a popular one which is capable and runs similarly > across > > the OS's and languages then that's a big plus in my mind. > > > > > > Thanks, > > > > Nick > > > > ____________ > > From: Mikael Ståldal > > Sent: Tuesday, October 18, 2016 2:52 AM > > To: Log4J Users List > > Subject: Re: porting log4j2 to .NET > > > > Just to make things clear, Log4j is a logging framework for the JVM > > platform, and it is agnostic to the underlying OS. It it well tested on > (at > > least) both Linux and Windows. > > > > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane wrote: > > > > > Figured I would send this question out to the log4j side. I have > already > > > had some email exchanges with the log4net mailing list regarding > porting > > > log4j2 to .NET. My suggestion was that the apache logging framework > be a > > > single architecture design which is platform agnostic and then teams > > which > > > port to the different platforms. It seems log4net was a port of log4j > > and > > > may be going off in its own direction from that initial port. My > > viewpoint > > > is that's a bad idea as one of the benefits I saw was that log4net was > > > similar to log4j2 and we're looking for logging frameworks for our > > > enterprise. We have applications on both Windows/.NET and Linux/Java > so > > > having a logging framework for Windows/.NET which is similar to a > logging > > > framework for Linux/Java was a big plus. > > > > > > > > > While I have no doubt the effort to port log4j2 to .NET is > considerable, > > > it would be a port and thus I'm not spending time figuring out design > and > > > algorithms. Would anyone want to venture a guess at what that effort > > might > > > be? > > > > > > > > > Thanks, > > > > > > Nick > > > > > > > > > > > -- > > [image: MagineTV] > > > > *Mikael Ståldal* > > Senior software developer > > > > *Magine TV* > > mikael.stal...@magine.com > > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com< > > http://www.magine.com> > > [https://de.magine.com/content/uploads/2016/09/magine_global_social.png > ]< > > http://www.magine.com/> > > > > TV online with Magine TV<http://www.magine.com/> > > www.magine.com > > Watch the TV you love, on any device, anywhere in Germany and Sweden and > > find out more about our global OTT B2B solutions. Get started today. > > > > > > > > Privileged and/or Confidential Information may be contained in this > > message. If you are not the addressee indicated in this message > > (or responsible for delivery of the message to such a person), you may > not > > copy or deliver this message to anyone. In such case, > > you should destroy this message and kindly notify the sender by reply > > email. > > > > > > -- > Matt Sicker > -- [image: MagineTV] *Mikael Ståldal* Senior software developer *Magine TV* mikael.stal...@magine.com Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email.
Re: porting log4j2 to .NET
Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what language you run on the JVM (Java, Scala, Groovy, Clojure, etc). I guess it would be nice to have similar logging framework for other runtimes (such as .Net). However, I would not like to constrain Log4j to only use features available on both JVM and .Net. On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane wrote: > I guess platform is vague. Maybe I should have said language agnostic. > It would be nice to have a single logging architecture/design run on C/C++, > .NET, Java, etc. Or at least it seems like a nice feature to me. I would > assume there are many enterprises out there that have applications running > on different OS's and languages. If I'm trying to pick a logging framework > to use and I find a popular one which is capable and runs similarly across > the OS's and languages then that's a big plus in my mind. > > > Thanks, > > Nick > > > From: Mikael Ståldal > Sent: Tuesday, October 18, 2016 2:52 AM > To: Log4J Users List > Subject: Re: porting log4j2 to .NET > > Just to make things clear, Log4j is a logging framework for the JVM > platform, and it is agnostic to the underlying OS. It it well tested on (at > least) both Linux and Windows. > > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane wrote: > > > Figured I would send this question out to the log4j side. I have already > > had some email exchanges with the log4net mailing list regarding porting > > log4j2 to .NET. My suggestion was that the apache logging framework be a > > single architecture design which is platform agnostic and then teams > which > > port to the different platforms. It seems log4net was a port of log4j > and > > may be going off in its own direction from that initial port. My > viewpoint > > is that's a bad idea as one of the benefits I saw was that log4net was > > similar to log4j2 and we're looking for logging frameworks for our > > enterprise. We have applications on both Windows/.NET and Linux/Java so > > having a logging framework for Windows/.NET which is similar to a logging > > framework for Linux/Java was a big plus. > > > > > > While I have no doubt the effort to port log4j2 to .NET is considerable, > > it would be a port and thus I'm not spending time figuring out design and > > algorithms. Would anyone want to venture a guess at what that effort > might > > be? > > > > > > Thanks, > > > > Nick > > > > > > -- > [image: MagineTV] > > *Mikael Ståldal* > Senior software developer > > *Magine TV* > mikael.stal...@magine.com > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com< > http://www.magine.com> > [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]< > http://www.magine.com/> > > TV online with Magine TV<http://www.magine.com/> > www.magine.com > Watch the TV you love, on any device, anywhere in Germany and Sweden and > find out more about our global OTT B2B solutions. Get started today. > > > > Privileged and/or Confidential Information may be contained in this > message. If you are not the addressee indicated in this message > (or responsible for delivery of the message to such a person), you may not > copy or deliver this message to anyone. In such case, > you should destroy this message and kindly notify the sender by reply > email. > -- [image: MagineTV] *Mikael Ståldal* Senior software developer *Magine TV* mikael.stal...@magine.com Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email.
Re: porting log4j2 to .NET
Matt, I think you are missing the point. He wants a standard logging API that he can use in both .NET and Java so when the developers switch between them they have the same contract and functionality. Ralph > On Oct 18, 2016, at 6:58 AM, Matt Sicker wrote: > > Using syslog is a pretty standard way to collect logs from all sorts of > programs and goes back decades. There has been an update to the syslog > format in RFC 5424 which fleshes it out a bunch. > > Then there are programs like Logstash and Flume which can be used in a more > platform-agnostic manner to collect logs from different applications. > > Really, when it comes down to it, the most standard way you can log > everything regardless of programming language is to use log files or some > sort of network appender using a standardized binary format. > > On 18 October 2016 at 08:53, Nicholas Duane wrote: > >> I guess platform is vague. Maybe I should have said language agnostic. >> It would be nice to have a single logging architecture/design run on C/C++, >> .NET, Java, etc. Or at least it seems like a nice feature to me. I would >> assume there are many enterprises out there that have applications running >> on different OS's and languages. If I'm trying to pick a logging framework >> to use and I find a popular one which is capable and runs similarly across >> the OS's and languages then that's a big plus in my mind. >> >> >> Thanks, >> >> Nick >> >> ____________ >> From: Mikael Ståldal >> Sent: Tuesday, October 18, 2016 2:52 AM >> To: Log4J Users List >> Subject: Re: porting log4j2 to .NET >> >> Just to make things clear, Log4j is a logging framework for the JVM >> platform, and it is agnostic to the underlying OS. It it well tested on (at >> least) both Linux and Windows. >> >> On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane wrote: >> >>> Figured I would send this question out to the log4j side. I have already >>> had some email exchanges with the log4net mailing list regarding porting >>> log4j2 to .NET. My suggestion was that the apache logging framework be a >>> single architecture design which is platform agnostic and then teams >> which >>> port to the different platforms. It seems log4net was a port of log4j >> and >>> may be going off in its own direction from that initial port. My >> viewpoint >>> is that's a bad idea as one of the benefits I saw was that log4net was >>> similar to log4j2 and we're looking for logging frameworks for our >>> enterprise. We have applications on both Windows/.NET and Linux/Java so >>> having a logging framework for Windows/.NET which is similar to a logging >>> framework for Linux/Java was a big plus. >>> >>> >>> While I have no doubt the effort to port log4j2 to .NET is considerable, >>> it would be a port and thus I'm not spending time figuring out design and >>> algorithms. Would anyone want to venture a guess at what that effort >> might >>> be? >>> >>> >>> Thanks, >>> >>> Nick >>> >> >> >> >> -- >> [image: MagineTV] >> >> *Mikael Ståldal* >> Senior software developer >> >> *Magine TV* >> mikael.stal...@magine.com >> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com< >> http://www.magine.com> >> [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]< >> http://www.magine.com/> >> >> TV online with Magine TV<http://www.magine.com/> >> www.magine.com >> Watch the TV you love, on any device, anywhere in Germany and Sweden and >> find out more about our global OTT B2B solutions. Get started today. >> >> >> >> Privileged and/or Confidential Information may be contained in this >> message. If you are not the addressee indicated in this message >> (or responsible for delivery of the message to such a person), you may not >> copy or deliver this message to anyone. In such case, >> you should destroy this message and kindly notify the sender by reply >> email. >> > > > > -- > Matt Sicker - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: porting log4j2 to .NET
Using syslog is a pretty standard way to collect logs from all sorts of programs and goes back decades. There has been an update to the syslog format in RFC 5424 which fleshes it out a bunch. Then there are programs like Logstash and Flume which can be used in a more platform-agnostic manner to collect logs from different applications. Really, when it comes down to it, the most standard way you can log everything regardless of programming language is to use log files or some sort of network appender using a standardized binary format. On 18 October 2016 at 08:53, Nicholas Duane wrote: > I guess platform is vague. Maybe I should have said language agnostic. > It would be nice to have a single logging architecture/design run on C/C++, > .NET, Java, etc. Or at least it seems like a nice feature to me. I would > assume there are many enterprises out there that have applications running > on different OS's and languages. If I'm trying to pick a logging framework > to use and I find a popular one which is capable and runs similarly across > the OS's and languages then that's a big plus in my mind. > > > Thanks, > > Nick > > > From: Mikael Ståldal > Sent: Tuesday, October 18, 2016 2:52 AM > To: Log4J Users List > Subject: Re: porting log4j2 to .NET > > Just to make things clear, Log4j is a logging framework for the JVM > platform, and it is agnostic to the underlying OS. It it well tested on (at > least) both Linux and Windows. > > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane wrote: > > > Figured I would send this question out to the log4j side. I have already > > had some email exchanges with the log4net mailing list regarding porting > > log4j2 to .NET. My suggestion was that the apache logging framework be a > > single architecture design which is platform agnostic and then teams > which > > port to the different platforms. It seems log4net was a port of log4j > and > > may be going off in its own direction from that initial port. My > viewpoint > > is that's a bad idea as one of the benefits I saw was that log4net was > > similar to log4j2 and we're looking for logging frameworks for our > > enterprise. We have applications on both Windows/.NET and Linux/Java so > > having a logging framework for Windows/.NET which is similar to a logging > > framework for Linux/Java was a big plus. > > > > > > While I have no doubt the effort to port log4j2 to .NET is considerable, > > it would be a port and thus I'm not spending time figuring out design and > > algorithms. Would anyone want to venture a guess at what that effort > might > > be? > > > > > > Thanks, > > > > Nick > > > > > > -- > [image: MagineTV] > > *Mikael Ståldal* > Senior software developer > > *Magine TV* > mikael.stal...@magine.com > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com< > http://www.magine.com> > [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]< > http://www.magine.com/> > > TV online with Magine TV<http://www.magine.com/> > www.magine.com > Watch the TV you love, on any device, anywhere in Germany and Sweden and > find out more about our global OTT B2B solutions. Get started today. > > > > Privileged and/or Confidential Information may be contained in this > message. If you are not the addressee indicated in this message > (or responsible for delivery of the message to such a person), you may not > copy or deliver this message to anyone. In such case, > you should destroy this message and kindly notify the sender by reply > email. > -- Matt Sicker
Re: porting log4j2 to .NET
I guess platform is vague. Maybe I should have said language agnostic. It would be nice to have a single logging architecture/design run on C/C++, .NET, Java, etc. Or at least it seems like a nice feature to me. I would assume there are many enterprises out there that have applications running on different OS's and languages. If I'm trying to pick a logging framework to use and I find a popular one which is capable and runs similarly across the OS's and languages then that's a big plus in my mind. Thanks, Nick From: Mikael Ståldal Sent: Tuesday, October 18, 2016 2:52 AM To: Log4J Users List Subject: Re: porting log4j2 to .NET Just to make things clear, Log4j is a logging framework for the JVM platform, and it is agnostic to the underlying OS. It it well tested on (at least) both Linux and Windows. On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane wrote: > Figured I would send this question out to the log4j side. I have already > had some email exchanges with the log4net mailing list regarding porting > log4j2 to .NET. My suggestion was that the apache logging framework be a > single architecture design which is platform agnostic and then teams which > port to the different platforms. It seems log4net was a port of log4j and > may be going off in its own direction from that initial port. My viewpoint > is that's a bad idea as one of the benefits I saw was that log4net was > similar to log4j2 and we're looking for logging frameworks for our > enterprise. We have applications on both Windows/.NET and Linux/Java so > having a logging framework for Windows/.NET which is similar to a logging > framework for Linux/Java was a big plus. > > > While I have no doubt the effort to port log4j2 to .NET is considerable, > it would be a port and thus I'm not spending time figuring out design and > algorithms. Would anyone want to venture a guess at what that effort might > be? > > > Thanks, > > Nick > -- [image: MagineTV] *Mikael Ståldal* Senior software developer *Magine TV* mikael.stal...@magine.com Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com<http://www.magine.com> [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]<http://www.magine.com/> TV online with Magine TV<http://www.magine.com/> www.magine.com Watch the TV you love, on any device, anywhere in Germany and Sweden and find out more about our global OTT B2B solutions. Get started today. Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email.
Re: porting log4j2 to .NET
Just to make things clear, Log4j is a logging framework for the JVM platform, and it is agnostic to the underlying OS. It it well tested on (at least) both Linux and Windows. On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane wrote: > Figured I would send this question out to the log4j side. I have already > had some email exchanges with the log4net mailing list regarding porting > log4j2 to .NET. My suggestion was that the apache logging framework be a > single architecture design which is platform agnostic and then teams which > port to the different platforms. It seems log4net was a port of log4j and > may be going off in its own direction from that initial port. My viewpoint > is that's a bad idea as one of the benefits I saw was that log4net was > similar to log4j2 and we're looking for logging frameworks for our > enterprise. We have applications on both Windows/.NET and Linux/Java so > having a logging framework for Windows/.NET which is similar to a logging > framework for Linux/Java was a big plus. > > > While I have no doubt the effort to port log4j2 to .NET is considerable, > it would be a port and thus I'm not spending time figuring out design and > algorithms. Would anyone want to venture a guess at what that effort might > be? > > > Thanks, > > Nick > -- [image: MagineTV] *Mikael Ståldal* Senior software developer *Magine TV* mikael.stal...@magine.com Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email.
Re: porting log4j2 to .NET
Thanks for the guess. I assume there is enough "separate" big enough pieces that a small group of people could work on different sections without stepping on each others toes such that you'd get some linear scaling. For instance, it might take 3 people 2 months? Even if we double your estimate, 3 people taking 4 months? Doesn't sound too bad. Thanks, Nick From: Gary Gregory Sent: Monday, October 17, 2016 8:54 PM To: Log4J Users List Subject: Re: porting log4j2 to .NET Random guesstimate for a complete port, including tests (what about docs): 6 man-months. You can shorten things up by reducing appenders and configuration formats. Gary On Mon, Oct 17, 2016 at 5:33 PM, Nicholas Duane wrote: > Figured I would send this question out to the log4j side. I have already > had some email exchanges with the log4net mailing list regarding porting > log4j2 to .NET. My suggestion was that the apache logging framework be a > single architecture design which is platform agnostic and then teams which > port to the different platforms. It seems log4net was a port of log4j and > may be going off in its own direction from that initial port. My viewpoint > is that's a bad idea as one of the benefits I saw was that log4net was > similar to log4j2 and we're looking for logging frameworks for our > enterprise. We have applications on both Windows/.NET and Linux/Java so > having a logging framework for Windows/.NET which is similar to a logging > framework for Linux/Java was a big plus. > > > While I have no doubt the effort to port log4j2 to .NET is considerable, > it would be a port and thus I'm not spending time figuring out design and > algorithms. Would anyone want to venture a guess at what that effort might > be? > > > Thanks, > > Nick > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> JUnit in Action, Second Edition: Petar Tahchiev, Felipe Leme, Vincent Massol, Gary Gregory: 9781935182023: Amazon.com: Books<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> www.amazon.com JUnit in Action, Second Edition [Petar Tahchiev, Felipe Leme, Vincent Massol, Gary Gregory] on Amazon.com. *FREE* shipping on qualifying offers. When JUnit was first introduced a decade ago by Kent Beck and Erich Gamma, the Agile movement was in its infancy <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> Spring Batch in Action: Arnaud Cogoluegnes, Thierry Templier, Gary Gregory, Olivier Bazoud: 9781935182955: Amazon.com: Books<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> www.amazon.com Spring Batch in Action [Arnaud Cogoluegnes, Thierry Templier, Gary Gregory, Olivier Bazoud] on Amazon.com. *FREE* shipping on qualifying offers. Summary Spring Batch in Action is an in-depth guide to writing batch applications using Spring Batch. Written for developers who have basic knowledge of Java and the Spring lightweight container <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com [https://s0.wp.com/i/blank.jpg]<http://garygregory.wordpress.com/> Gary Gregory<http://garygregory.wordpress.com/> garygregory.wordpress.com Software construction, the web, and other techs Home: http://garygregory.com/ Gary Gregory<http://garygregory.com/> garygregory.com Rocket | Seagull . I am a Software Architect for Seagull Software, a division of Rocket Software. Rocket Seagull specializes in tools and expertise to modernize ... Tweet! http://twitter.com/GaryGregory
Re: porting log4j2 to .NET
Random guesstimate for a complete port, including tests (what about docs): 6 man-months. You can shorten things up by reducing appenders and configuration formats. Gary On Mon, Oct 17, 2016 at 5:33 PM, Nicholas Duane wrote: > Figured I would send this question out to the log4j side. I have already > had some email exchanges with the log4net mailing list regarding porting > log4j2 to .NET. My suggestion was that the apache logging framework be a > single architecture design which is platform agnostic and then teams which > port to the different platforms. It seems log4net was a port of log4j and > may be going off in its own direction from that initial port. My viewpoint > is that's a bad idea as one of the benefits I saw was that log4net was > similar to log4j2 and we're looking for logging frameworks for our > enterprise. We have applications on both Windows/.NET and Linux/Java so > having a logging framework for Windows/.NET which is similar to a logging > framework for Linux/Java was a big plus. > > > While I have no doubt the effort to port log4j2 to .NET is considerable, > it would be a port and thus I'm not spending time figuring out design and > algorithms. Would anyone want to venture a guess at what that effort might > be? > > > Thanks, > > Nick > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
porting log4j2 to .NET
Figured I would send this question out to the log4j side. I have already had some email exchanges with the log4net mailing list regarding porting log4j2 to .NET. My suggestion was that the apache logging framework be a single architecture design which is platform agnostic and then teams which port to the different platforms. It seems log4net was a port of log4j and may be going off in its own direction from that initial port. My viewpoint is that's a bad idea as one of the benefits I saw was that log4net was similar to log4j2 and we're looking for logging frameworks for our enterprise. We have applications on both Windows/.NET and Linux/Java so having a logging framework for Windows/.NET which is similar to a logging framework for Linux/Java was a big plus. While I have no doubt the effort to port log4j2 to .NET is considerable, it would be a port and thus I'm not spending time figuring out design and algorithms. Would anyone want to venture a guess at what that effort might be? Thanks, Nick
