Re: Programmatically determine if logger is "OFF"

Can't you just use isEnabled(Level.OFF)? On 30 March 2017 at 20:17, Gary Gregory wrote: > I am OK with adding these methods (isOff(), isAll()), I only wanted to > point out that this is not just one method. > > Gary > > On Thu, Mar 30, 2017 at 5:42 PM, Remko Popma

Re: Programmatically determine if logger is "OFF"

I am OK with adding these methods (isOff(), isAll()), I only wanted to point out that this is not just one method. Gary On Thu, Mar 30, 2017 at 5:42 PM, Remko Popma wrote: > I think Gary rightly points out that this may not be as trivial as it > seems. Personally I am

Re: Programmatically determine if logger is "OFF"

I think Gary rightly points out that this may not be as trivial as it seems. Personally I am not a fan of API changes to add convenience methods. Remko Sent from my iPhone > On Mar 31, 2017, at 8:20, Gary Gregory wrote: > > The best way to get this cooking is to

Re: Programmatically determine if logger is "OFF"

The best way to get this cooking is to create a JIRA and attach a patch. Note that It's not just adding an isOff() method, there is also the various implementations. You'll also have to add unit tests. Also, should there be an isOff(Marker)? There is also the ALL level... Gary On Thu, Mar 30,

Programmatically determine if logger is "OFF"

"OFF" is a level usable in a logging configuration file. I have a need to see if a logger is configured this way. There is no API in logger that checks this. There is a workaround of course - if isFatalEnabled() returns false, then the logger is OFF. But it would be trivial to add an

Re: Kafka Appender with Programmatic Configuration

I think so. That'd be less confusing. On 30 March 2017 at 02:43, Mikael Ståldal wrote: > Would it make sense to have shortcuts for Property and KeyValuePair, since > they are generic and used by several appenders/layouts? > > On Wed, Mar 29, 2017 at 7:12 PM, Matt

Re: About performance

Look at the source code for Thread.getStackTrace(). When this == currentThread(), it calls new Exception().getStackTrace(). Less indirection to just do it directly. ;) On 30 March 2017 at 10:16, Ralph Goers wrote: > I should note that in Java 9 getting the location

Re: About performance

I should note that in Java 9 getting the location information will be much faster. Ralph > On Mar 30, 2017, at 7:44 AM, Pietro Galassi wrote: > > Perfect. > > So using a method that will add location information on demand is the best > choice. This will let remove

Re: About performance

Perfect. So using a method that will add location information on demand is the best choice. This will let remove %M or the specific method finding logic whenever it's not necessary. Regards. On Thu, Mar 30, 2017 at 4:36 PM, Remko Popma wrote: > > > On Mar 30, 2017, at

Re: About performance

> On Mar 30, 2017, at 21:51, Pietro Galassi wrote: > > Thanks a lot! > > So: > > - for class name better to use %c with the LogManager.getLogger(this.class) > instead of the calculation i do ? Yes. > > - for method name avoid %M and use new

Re: About performance

Thanks a lot! So: - for class name better to use %c with the LogManager.getLogger(this.class) instead of the calculation i do ? - for method name avoid %M and use new Throwable().getStackTrace instead Thread.currentThread().getStackTrace() to get better performance ? Regards On Thu, Mar 30,

Re: About performance

Sent from my iPhone > On Mar 30, 2017, at 16:24, Pietro Galassi wrote: > > So, > > using such code like this: > > LogManager.getLogger(this.class); will let the code be fast ? Yes. > > > and it's faster than the code i published ? Yes. The point of my answer was

Re: Kafka Appender with Programmatic Configuration

Would it make sense to have shortcuts for Property and KeyValuePair, since they are generic and used by several appenders/layouts? On Wed, Mar 29, 2017 at 7:12 PM, Matt Sicker wrote: > Oh, I see. That's an interesting API... > > On 29 March 2017 at 10:49, Marvin Geitner

Re: About performance

So, using such code like this: LogManager.getLogger(this.class); will let the code be fast ? and it's faster than the code i published ? Also why new Throwable().getStackTrace is faster than Thread.currentThread().getStackTrace(). ? Does the new in Throwable can give performance issue ?