Re: [log4j] providing sourcewith Message

Looking to get some eyes on https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-2360 On Wed, Jun 27, 2018 at 11:02 PM, Jeffrey Shaw wrote: > I created a JIRA ticket for this. https://issues.apache.org/ > jira/browse/LOG4J2-2360 > > On Thu, Mar 15, 2018 at 11:37 PM, Jeff Shaw wrote: > >

Re: [log4j] providing sourcewith Message

I created a JIRA ticket for this. https://issues.apache.org/jira/browse/LOG4J2-2360 On Thu, Mar 15, 2018 at 11:37 PM, Jeff Shaw wrote: > Thanks, Remko. There is no ticket that I know of. This is something I was > inspired to work on before I gave any thought to a formal process. > > Sent from my

Re: [log4j] providing sourcewith Message

Thanks, Remko. There is no ticket that I know of. This is something I was inspired to work on before I gave any thought to a formal process. Sent from my phone > On Mar 15, 2018, at 11:26 PM, Remko Popma wrote: > > I am interested and planning to take a look if others don’t beat me to it. Is

Re: [log4j] providing sourcewith Message

I am interested and planning to take a look if others don’t beat me to it. Is there a corresponding JIRA ticket? (Shameless plug) Every java main() method deserves http://picocli.info > On Mar 16, 2018, at 5:33, Jeffrey Shaw wrote: > > Hi, just hoping to get some eyes on this again. > >> On F

Re: [log4j] providing sourcewith Message

Hi, just hoping to get some eyes on this again. On Fri, Feb 23, 2018 at 10:43 PM, Jeffrey Shaw wrote: > closed that one and opened a new one with the commits squashed > https://github.com/apache/logging-log4j2/pull/152 > > On Fri, Feb 23, 2018 at 10:11 PM, Jeffrey Shaw wrote: > >> done! https:/

Re: [log4j] providing sourcewith Message

closed that one and opened a new one with the commits squashed https://github.com/apache/logging-log4j2/pull/152 On Fri, Feb 23, 2018 at 10:11 PM, Jeffrey Shaw wrote: > done! https://github.com/apache/logging-log4j2/pull/151 > > On Fri, Feb 23, 2018 at 9:22 PM, Gary Gregory > wrote: > >> On Fri

Re: [log4j] providing sourcewith Message

done! https://github.com/apache/logging-log4j2/pull/151 On Fri, Feb 23, 2018 at 9:22 PM, Gary Gregory wrote: > On Fri, Feb 23, 2018 at 7:02 PM, Jeffrey Shaw wrote: > > > Hi All, > > I spent some more time on this tonight. I've brought my code up to date > for > > log4j versions 2 and 3. version

Re: [log4j] providing sourcewith Message

On Fri, Feb 23, 2018 at 7:02 PM, Jeffrey Shaw wrote: > Hi All, > I spent some more time on this tonight. I've brought my code up to date for > log4j versions 2 and 3. version 2 > location-release-2.x> > version > 3

Re: [log4j] providing sourcewith Message

Hi All, I spent some more time on this tonight. I've brought my code up to date for log4j versions 2 and 3. version 2 version 3 Per Ralph Goers and some

Re: [log4j] providing sourcewith Message

Yes, StackTraceElement does not allow null methodName. But what about using the empty string, or a string like "" if it is not possible to get? On 2017-12-22 20:26, Jeffrey Shaw wrote: I didn't know about clirr, but I can try running that. I tried to not break any existing public methods. I

Re: [log4j] providing sourcewith Message

Is there no mangled method name generated? For example, inside a lambda, the function might be called Foo$1 like with Java 8 lambdas. On 22 December 2017 at 14:18, Ralph Goers wrote: > I am concerned because users can create customer Appenders and Layouts > that will be affected by a change to t

Re: [log4j] providing sourcewith Message

I am concerned because users can create customer Appenders and Layouts that will be affected by a change to the signature of getSource() in the LogEvent. I suspect that there are other things that use the LogEvent (the Logging Server? Lillith?) that would be impacted by this. Ralph > On Dec 22

Re: [log4j] providing sourcewith Message

I didn't know about clirr, but I can try running that. I tried to not break any existing public methods. I created SourceLocation because I think for Scala macros, the method name can not exist, but StackTraceElement requires a method name. I'll double check this. On Thu, Dec 21, 2017 at 12:40 AM

Re: [log4j] providing sourcewith Message

A normal GitHub PR works. Have you signed an ICLA for Apache yet? And yes, we'll need to compare API changes to verify it doesn't cause BC problems. On 20 December 2017 at 23:40, Ralph Goers wrote: > I’m not sure I would be comfortable applying the patch this way. Have you > run a clirr report o

Re: [log4j] providing sourcewith Message

I’m not sure I would be comfortable applying the patch this way. Have you run a clirr report on your changes? I am concerned that this could break customizations that users might have made. What is the reason SourceLocation had to be used instead of StackTraceElement? Ralph > On Dec 20, 2017,

Re: [log4j] providing sourcewith Message

It looks like the location only ever gets the file name, because that's what StackTraceElement gives. So that's fine. I think I'm ready for a formal review. Should I create pull requests on github for https://github.com/shawjef3/logging-log4j2/tree/message-location and https://github.com/shawjef3/

Re: [log4j] providing sourcewith Message

I think that should be configurable in the layout options. On 20 December 2017 at 13:04, Dominik Psenner wrote: > Could a compile time environment variable like SrcRootDirectory do the job? > > On 20 Dec 2017 7:49 p.m., "Jeffrey Shaw" wrote: > > > I got it working using a custom ExtendedLogger

Re: [log4j] providing sourcewith Message

Could a compile time environment variable like SrcRootDirectory do the job? On 20 Dec 2017 7:49 p.m., "Jeffrey Shaw" wrote: > I got it working using a custom ExtendedLogger instead of mocking. > > It looks like for file name, there are only two options. We can have the > file name, or the full p

Re: [log4j] providing sourcewith Message

I got it working using a custom ExtendedLogger instead of mocking. It looks like for file name, there are only two options. We can have the file name, or the full path to the file. The path relative to the project root looks impossible to get, unless we look for magic names like "src". Any opinion

Re: [log4j] providing sourcewith Message

It's possible that macros and mocks don't work well together, though that's just a guess. On 20 December 2017 at 00:00, Jeff Shaw wrote: > I should add that manually testing it works. > > Sent from my phone > > > On Dec 20, 2017, at 12:45 AM, Jeffrey Shaw wrote: > > > > I added some tests for t

Re: [log4j] providing sourcewith Message

I should add that manually testing it works. Sent from my phone > On Dec 20, 2017, at 12:45 AM, Jeffrey Shaw wrote: > > I added some tests for traced, but they don't pass. The mocks say, "Actually, > there were zero interactions with this mock." I could use some help getting > these two tests

Re: [log4j] providing sourcewith Message

I added some tests for traced, but they don't pass. The mocks say, "Actually, there were zero interactions with this mock." I could use some help getting these two tests to work. https://github.com/shawjef3/logging-log4j-scala/blob/message-location/log4j-api-scala_2.12/src/test/scala/org/apache/lo

Re: [log4j] providing sourcewith Message

Thanks for the encouragement everyone! I never worked on an Apache project before and had no idea what to expect from the community. I've made some progress. One cool thing I added was a `traced` method ( source

Re: [log4j] providing sourcewith Message

>From the little I've worked with macros (worked more with scalameta and shapeless), that looks good so far. If you can add some unit tests, then we'd be happy to merge! On 11 December 2017 at 20:41, Jeffrey Shaw wrote: > Great news! I'm able to run LoggingApp in the scala api repo without it >

Re: [log4j] providing sourcewith Message

Great news! I'm able to run LoggingApp in the scala api repo without it calling StackLocatorUtil.calcLocation, but it prints the same messages as before. I have to use my patch to log4j of course. See https://github.com/shawjef3/logging-log4j-scala/commits/message-location On Sun, Dec 10, 2017 at

Re: [log4j] providing sourcewith Message

This sounds like it'd make a great addition to the Scala API! On 9 December 2017 at 15:36, Jeffrey Shaw wrote: > Ralph, I agree with you entirely. My intent for these new log methods is > that they only be called from compile-time generated code. > > On Sat, Dec 9, 2017 at 4:30 PM, Ralph Goers

Re: [log4j] providing sourcewith Message

Ralph, I agree with you entirely. My intent for these new log methods is that they only be called from compile-time generated code. On Sat, Dec 9, 2017 at 4:30 PM, Ralph Goers wrote: > I don’t understand how this is a good idea. To use this you would need to > do something like: > > Message msg

Re: [log4j] providing sourcewith Message

I don’t understand how this is a good idea. To use this you would need to do something like: Message msg = new StringMessage(getCaller(), “My Message”); logger.debug(msg); Unfortunately the line number would point to the line where getCaller() is called not to the logger statement. I had thoug

Re: [log4j] providing sourcewith Message

Thanks for the link, Mikael. I'll take a look at it. I added some plumbing to core to allow clients to pass a StackTraceElement to loggers. I'd like a code review. I'm happy to try other methods. See the following commit. https://github.com/shawjef3/logging-log4j2/commit/9c42073e9ca4f25a2f4075b179

Re: [log4j] providing sourcewith Message

Have you tried the Log4j Scala API? http://logging.apache.org/log4j/2.x/manual/scala-api.html It does currently not support this, but it uses Scala macros, and this could be added there. But log4j-api and/or log4j-core probably needs to adapted as well. On 2017-12-09 07:30, Jeffrey Shaw wro

Re: [log4j] providing sourcewith Message

I got the idea from https://github.com/outr/scribe, and I wanted to adapt it for log4j. Basically the idea is that I'd create a wrapper for Loggers that provides information from the compiler for source code. See https://github.com/outr/scribe/blob/master/shared/src/main/scala/scribe/Macros.scala#

Re: [log4j] providing sourcewith Message

Interesting! Can you point to an example of how this works? I’m trying to understand what changes would be required. Remko (Shameless plug) Every java main() method deserves http://picocli.info > On Dec 9, 2017, at 15:30, Jeffrey Shaw wrote: > > Hello, > I've found that I am able to use Sca

[log4j] providing sourcewith Message

Hello, I've found that I am able to use Scala macros to provide compile-time source information for log messages. However, I don't see a way to inject this into log4j's logging mechanism. I'm wondering if there is something I'm missing, or if LogEvent's getSource method could be duplicated in Mess