[jira] [Commented] (LOG4J2-1274) Layout improvements to enable avoiding temporary object allocation

[ https://issues.apache.org/jira/browse/LOG4J2-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147111#comment-15147111 ] Remko Popma commented on LOG4J2-1274: - This is what I have in mind: # add new method

[jira] [Updated] (LOG4J2-1263) log4j2.properties: monitorInterval has no effect

[ https://issues.apache.org/jira/browse/LOG4J2-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated LOG4J2-1263: -- Summary: log4j2.properties: monitorInterval has no effect (was: log4j2.properties: mon

[jira] [Updated] (LOG4J2-1274) Layout improvements to enable avoiding temporary object allocation

[ https://issues.apache.org/jira/browse/LOG4J2-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1274: Description: *Problem* The current Layout API does not make it easy for implementors to avoid creat

[jira] [Updated] (LOG4J2-1274) Layout improvements to enable avoiding temporary object allocation

[ https://issues.apache.org/jira/browse/LOG4J2-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1274: Description: *Problem* The current Layout API does not make it easy for implementors to avoid creat

[jira] [Updated] (LOG4J2-1274) Layout improvements to enable avoiding temporary object allocation

[ https://issues.apache.org/jira/browse/LOG4J2-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1274: Description: *Problem* The current Layout API does not make it easy for implementors to avoid creat

[jira] [Updated] (LOG4J2-1274) Layout improvements to enable avoiding temporary object allocation

[ https://issues.apache.org/jira/browse/LOG4J2-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1274: Description: *Problem* The current Layout API does not make it easy for implementors to avoid creat

[jira] [Commented] (LOG4J2-1255) Logger.entry and Logger.exit should support Messages.

[ https://issues.apache.org/jira/browse/LOG4J2-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147477#comment-15147477 ] Remko Popma commented on LOG4J2-1255: - After looking at the {{Generate}} tool in more

[jira] [Commented] (LOG4J2-1255) Logger.entry and Logger.exit should support Messages.

[ https://issues.apache.org/jira/browse/LOG4J2-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147484#comment-15147484 ] Remko Popma commented on LOG4J2-1255: - Also, I found what looks like a bug in the imp

[jira] [Commented] (LOG4J2-1255) Logger.entry and Logger.exit should support Messages.

[ https://issues.apache.org/jira/browse/LOG4J2-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147506#comment-15147506 ] Remko Popma commented on LOG4J2-1255: - The problem is hidden because the tested messa

traceExit() param order

Hi All: It seems to me the param order in traceExit() is backward. It should be: traceExit(message, returnValue), not traceExit(returnValue, message) Thoughts? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition

Deprecate entry/exit()

Hi All: Should we deprecate Logger.entry() and exit() in favor of Logger.traceEnter() and traceExit()? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition

Re: traceExit() param order

6 one way, half a dozen the other. Ralph > On Feb 15, 2016, at 9:26 AM, Gary Gregory wrote: > > Hi All: > > It seems to me the param order in traceExit() is backward. > > It should be: traceExit(message, returnValue), not traceExit(returnValue, > message) > > Thoughts? > > Gary > > -- >

Re: Deprecate entry/exit()

Unfortunately, all the entry and exit methods can’t be deprecated. entry(Object… params) is ambiguous with traceEntry(String format, Object…params). That, and the fact that entry(String fqcn, Object… params) already existed is the only reason I created the traceEntry() methods. Ralph > On Feb

traceExit and auto-boxing

Hi All: My my custom flow logger, I avoid auto-boxing on traceExit() calls by having primitive versions of the APIs. We could do the same and avoid auto-boxing unless a logger's level is enabled. This generates a lot less garbage when, for example, we flow trace our JDBC APIs and get 50m rows and

Re: Deprecate entry/exit()

Ok, I think this will work: deprecate enter() for traceEntry() deprecate all exit() methods for traceExit() methods Javadoc entry(Object...) and mention traceEntry() methods. Gary On Mon, Feb 15, 2016 at 8:37 AM, Ralph Goers wrote: > Unfortunately, all the entry and exit methods can’t be depre

Re: traceExit and auto-boxing

Considering the garbage-free epic, this sounds like a good idea to bake in from the start. On 15 February 2016 at 10:39, Gary Gregory wrote: > Hi All: > > My my custom flow logger, I avoid auto-boxing on traceExit() calls by > having primitive versions of the APIs. We could do the same and avoid

MessageSupplier and Supplier

Since 2.4 we have: public interface MessageSupplier { /** * Gets a Message. * * @return a Message */ Message get(); } and public interface Supplier { /** * Gets a value. * * @return a value */ T get(); } Which smells fishy to me. Instead

Re: traceExit() param order

On Mon, Feb 15, 2016 at 8:33 AM, Ralph Goers wrote: > 6 one way, half a dozen the other. > Since you are 50/50 I'll follow my gut and implement. Gary > > Ralph > > On Feb 15, 2016, at 9:26 AM, Gary Gregory wrote: > > Hi All: > > It seems to me the param order in traceExit() is backward. > >

Re: MessageSupplier and Supplier

Sounds good. Remko was mentioning how they could be combined by checking if get() returns an instanceof Message, but using the wildcard bounds like you show sounds like a better way (where possible). On 15 February 2016 at 11:06, Gary Gregory wrote: > Since 2.4 we have: > > public interface Mess

Re: MessageSupplier and Supplier

On Mon, Feb 15, 2016 at 9:08 AM, Matt Sicker wrote: > Sounds good. Remko was mentioning how they could be combined by checking > if get() returns an instanceof Message, but using the wildcard bounds like > you show sounds like a better way (where possible). > Wasn't Remko talking about a differe

Re: MessageSupplier and Supplier

On Mon, Feb 15, 2016 at 9:17 AM, Gary Gregory wrote: > On Mon, Feb 15, 2016 at 9:08 AM, Matt Sicker wrote: > >> Sounds good. Remko was mentioning how they could be combined by checking >> if get() returns an instanceof Message, but using the wildcard bounds like >> you show sounds like a better

[jira] [Commented] (LOG4J2-1274) Layout improvements to enable avoiding temporary object allocation

[ https://issues.apache.org/jira/browse/LOG4J2-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147625#comment-15147625 ] Mikael Ståldal commented on LOG4J2-1274: Do we then need the toSerializable() met

Jenkins build became unstable: Log4j 2.x #1677

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

We have a new type of unit test that might need Jenkins configuration for

I recently merged a patch related to OSGi, but the unit tests for it will only run after everything has been compiled at least once. Jenkins-wise, it might be a good idea to split it up into a build and test cycle. Otherwise, the OSGi tests are simply skipped every time. -- Matt Sicker

Jenkins build is back to stable : Log4j 2.x #1678

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: MessageSupplier and Supplier

The wildcard bounds are no help since they get erased, so we cannot have separate methods for Supplier and Supplier. (This is why I originally introduced MessageSupplier.) I don't mind deprecating MessageSupplier, but the point is that in the implementation of these logging methods we need to

Re: [2/2] logging-log4j2 git commit: Use Class.asSubclass() to remove @SuppressWarnings.

Nice, thanks! Sent from my iPhone > On 2016/02/16, at 4:47, mattsic...@apache.org wrote: > > Use Class.asSubclass() to remove @SuppressWarnings. > > > Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo > Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/e113

[jira] [Updated] (LOG4J2-1277) FormattedMessage, MessageFormatMessage and StringFormattedMessage should support passing in a Locale to ensure appropriate formatting

[ https://issues.apache.org/jira/browse/LOG4J2-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ludovic HOCHET updated LOG4J2-1277: --- Attachment: patch-log4j2-1277.diff Sorry, I should have included the factories as well since

[jira] [Updated] (LOG4J2-1276) LoggerMessageSupplierTest and LoggerSupplierTest are Locale sensitive

[ https://issues.apache.org/jira/browse/LOG4J2-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ludovic HOCHET updated LOG4J2-1276: --- Attachment: patch-log4j2-1276-2.diff With [LOG4J2-1277] in, I would rather use the constructo

[jira] [Comment Edited] (LOG4J2-1276) LoggerMessageSupplierTest and LoggerSupplierTest are Locale sensitive

[ https://issues.apache.org/jira/browse/LOG4J2-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147875#comment-15147875 ] Ludovic HOCHET edited comment on LOG4J2-1276 at 2/15/16 11:11 PM: -

Re: MessageSupplier and Supplier

The wildcard bounds are checked at compile time though I thought. Plus, despite the type erasure, there's still a bit of info available through reflection, so it's not entirely lost. On 15 February 2016 at 16:23, Remko Popma wrote: > The wildcard bounds are no help since they get erased, so we c

Re: traceExit and auto-boxing

A word of caution: the Logger API already has 209 method (and I think a few just got added). This will explode if we just add "var-arg unrolling" methods for 1 param, 2 params, 3 params, ... (up to how many?) Especially if we want to also prevent auto boxing in all possible combinations of the

Re: traceExit and auto-boxing

Oh wow, I didn't realise it was so big already. On 15 February 2016 at 17:46, Remko Popma wrote: > A word of caution: the Logger API already has 209 method (and I think a > few just got added). This will explode if we just add "var-arg unrolling" > methods for 1 param, 2 params, 3 params, ... (

Re: Better flow logging

With all respect, isn't this a very niche use case? I wouldn't want to push this into log4j, sounds like a perfect use case for a custom flow logger, or a custom helper method: logger.traceEntry("{} zoo(p1={}, p2={})", id(this), p1, s1); // id(obj) returns simpleName@hexHashCode Sent from my i

[jira] [Updated] (LOG4J2-1274) Layout improvements to enable avoiding temporary object allocation

[ https://issues.apache.org/jira/browse/LOG4J2-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1274: Description: *Problem* The current Layout API does not make it easy for implementors to avoid creat

Re: traceExit and auto-boxing

Which is one of the reasons I proposed "level logging". I'm on my phone so I can't do more that say there is a branch and Jira for my proposal. You only add a method once, not once per level. Then you say logger.alevel.log(...). Gary On Feb 15, 2016 3:47 PM, "Remko Popma" wrote: > A word of caut

[jira] [Commented] (LOG4J2-1274) Layout improvements to enable avoiding temporary object allocation

[ https://issues.apache.org/jira/browse/LOG4J2-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147945#comment-15147945 ] Remko Popma commented on LOG4J2-1274: - Some Appenders are aware they have a StringLay

Re: Better flow logging

What you describe is basically what I do now. So we are on the same page. I posted a while back what my custom flow logger class does. I do understand the niche comment as well. Another way to think about this is: how would you configure class after class, app after app, to do flow logging for mul

Re: traceExit and auto-boxing

Yep, that's definitely one of the candidates for a solution. Sent from my iPhone > On 2016/02/16, at 9:43, Gary Gregory wrote: > > Which is one of the reasons I proposed "level logging". I'm on my phone so I > can't do more that say there is a branch and Jira for my proposal. You only > add

Re: Better flow logging

Well, this is where I currently rely on location information. The only problem I had with the existing methods is that sometimes the parameters being logged at entry or exit need to be formatted (for example gson->toJson(response)). I dislike immensely having to type in method names and especia

Re: traceExit and auto-boxing

You could create special interfaces for these sets of special methods. There is not a design rule that says Logger must be the interface that does all things. Yep, that's definitely one of the candidates for a solution. Sent from my iPhone On 2016/02/16, at 9:43, Gary Gregory wrote: Which is on

Jenkins build became unstable: Log4j 2.x #1681

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Jenkins build is still unstable: Log4j 2.x #1682

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Jenkins build is still unstable: Log4j 2.x #1682

Did someone add new Properties tests? They seem to be failing when the LoggerContextRule tries to find the configuration. Ralph > On Feb 15, 2016, at 10:01 PM, Apache Jenkins Server > wrote: > > See > > > -

Re: Jenkins build is still unstable: Log4j 2.x #1682

No, but I'm looking into it as I changed PropertiesConfigurationFactory. On 15 February 2016 at 23:18, Ralph Goers wrote: > Did someone add new Properties tests? They seem to be failing when the > LoggerContextRule tries to find the configuration. > > Ralph > > > On Feb 15, 2016, at 10:01 PM, A

[jira] [Created] (LOG4J2-1278) Garbage-free logging API

Remko Popma created LOG4J2-1278: --- Summary: Garbage-free logging API Key: LOG4J2-1278 URL: https://issues.apache.org/jira/browse/LOG4J2-1278 Project: Log4j 2 Issue Type: Improvement Co

[jira] [Updated] (LOG4J2-1278) Garbage-free logging API (no varargs/autoboxing)

[ https://issues.apache.org/jira/browse/LOG4J2-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1278: Summary: Garbage-free logging API (no varargs/autoboxing) (was: Garbage-free logging API) > Garba

Jenkins build is back to stable : Log4j 2.x #1683

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: traceExit and auto-boxing

I created https://issues.apache.org/jira/browse/LOG4J2-1278 Sent from my iPhone > On 2016/02/16, at 12:58, Paul Benedict wrote: > > You could create special interfaces for these sets of special methods. There > is not a design rule that says Logger must be the interface that does all > thing