You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2016/02/15 17:39:07 UTC
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 50 columns per row.
Thoughts?
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: traceExit and auto-boxing
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Feb 15, 2016 at 7:58 PM, Paul Benedict <pb...@apache.org> 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 things.
>
You're right but the current design is a kitchen-sink interface.
If you look at my "level logger" (can anyone thing of a better name for
this design?) idea, then this issue becomes a moot point IMO because the
interface size is so much smaller. The method names can go back to being
simply enter() and exit() as well. But, still, yes, you could have all of
the enter and exit methods in a separate FlowLogger interface, I get the
point, but it seems a bit cumbersome.
Gary
> Yep, that's definitely one of the candidates for a solution.
>
> Sent from my iPhone
>
> On 2016/02/16, at 9:43, Gary Gregory <ga...@gmail.com> 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 a method once, not once per level. Then you say
> logger.alevel.log(...).
>
> Gary
> On Feb 15, 2016 3:47 PM, "Remko Popma" <re...@gmail.com> 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, ... (up to how many?) Especially
>> if we want to also prevent auto boxing in all possible combinations of the
>> primitive types boolean, long and double.
>>
>> There may be other ways to accomplish this. Let's think about this a bit
>> longer. I'll add a Jira for this in the no-GC epic.
>>
>> Sent from my iPhone
>>
>> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>>
>> 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 <ga...@gmail.com>
>> 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
>>> 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 50 columns per row.
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: traceExit and auto-boxing
Posted by Remko Popma <re...@gmail.com>.
I created https://issues.apache.org/jira/browse/LOG4J2-1278
Sent from my iPhone
> On 2016/02/16, at 12:58, Paul Benedict <pb...@apache.org> 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 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 <ga...@gmail.com> 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 a method once, not once per level. Then you say logger.alevel.log(...).
>>
>> Gary
>>
>>> On Feb 15, 2016 3:47 PM, "Remko Popma" <re...@gmail.com> 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, ... (up to how many?) Especially if we want to also prevent auto boxing in all possible combinations of the primitive types boolean, long and double.
>>>
>>> There may be other ways to accomplish this. Let's think about this a bit longer. I'll add a Jira for this in the no-GC epic.
>>>
>>> Sent from my iPhone
>>>
>>>> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> 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 <ga...@gmail.com> 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 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 50 columns per row.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Gary
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
Re: traceExit and auto-boxing
Posted by Paul Benedict <pb...@apache.org>.
I messed up the code example. Sorry. Let all supported logging interfaces
come from an empty marker interface.
public interface LogManager {
<T extends SomeMarkerInterface> T getLogger(Class<T> clz);
}
Cheers,
Paul
On Tue, Feb 16, 2016 at 10:27 AM, Paul Benedict <pb...@apache.org>
wrote:
> Maybe it's something worth discussing for version 3.0 :-) but you could
> have something like this:
>
> public interface LogManager {
> <T> T getLogger(Class<T> clz);
> }
>
> My suggestion is about allowing a "logger" (in the abstract) to be more
> than just the definite Logger interface. Having 200-some methods is a lot!
> I recommend to the team to think about splitting this up into many
> interfaces.
>
> I don't have any design issue with asking clients to grab different logger
> interfaces for specialized purposes.
>
> Food for thought.
>
> Cheers,
> Paul
>
> On Tue, Feb 16, 2016 at 10:20 AM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>> Well, you just need one interface: FlowLogger and all traceEntry and
>> traceExit methods can live there. But that means that a user must hold on
>> to 2 loggers for a given class for example. Unless FlowLogger extends
>> Logger. Then you'd also need to add getFlowLogger methods to LogManager.
>>
>> Which is better?
>> On Feb 15, 2016 7:58 PM, "Paul Benedict" <pb...@apache.org> 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 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 <ga...@gmail.com> 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 a method once, not once per level. Then you say
>>> logger.alevel.log(...).
>>>
>>> Gary
>>> On Feb 15, 2016 3:47 PM, "Remko Popma" <re...@gmail.com> 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, ... (up to how many?) Especially
>>>> if we want to also prevent auto boxing in all possible combinations of the
>>>> primitive types boolean, long and double.
>>>>
>>>> There may be other ways to accomplish this. Let's think about this a
>>>> bit longer. I'll add a Jira for this in the no-GC epic.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> 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 <ga...@gmail.com>
>>>> 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
>>>>> 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 50 columns per row.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Gary
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>
Re: traceExit and auto-boxing
Posted by Paul Benedict <pb...@apache.org>.
Maybe it's something worth discussing for version 3.0 :-) but you could
have something like this:
public interface LogManager {
<T> T getLogger(Class<T> clz);
}
My suggestion is about allowing a "logger" (in the abstract) to be more
than just the definite Logger interface. Having 200-some methods is a lot!
I recommend to the team to think about splitting this up into many
interfaces.
I don't have any design issue with asking clients to grab different logger
interfaces for specialized purposes.
Food for thought.
Cheers,
Paul
On Tue, Feb 16, 2016 at 10:20 AM, Gary Gregory <ga...@gmail.com>
wrote:
> Well, you just need one interface: FlowLogger and all traceEntry and
> traceExit methods can live there. But that means that a user must hold on
> to 2 loggers for a given class for example. Unless FlowLogger extends
> Logger. Then you'd also need to add getFlowLogger methods to LogManager.
>
> Which is better?
> On Feb 15, 2016 7:58 PM, "Paul Benedict" <pb...@apache.org> 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 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 <ga...@gmail.com> 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 a method once, not once per level. Then you say
>> logger.alevel.log(...).
>>
>> Gary
>> On Feb 15, 2016 3:47 PM, "Remko Popma" <re...@gmail.com> 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, ... (up to how many?) Especially
>>> if we want to also prevent auto boxing in all possible combinations of the
>>> primitive types boolean, long and double.
>>>
>>> There may be other ways to accomplish this. Let's think about this a bit
>>> longer. I'll add a Jira for this in the no-GC epic.
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> 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 <ga...@gmail.com>
>>> 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
>>>> 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 50 columns per row.
>>>>
>>>> Thoughts?
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
Re: traceExit and auto-boxing
Posted by Paul Benedict <pb...@apache.org>.
I don't think Log4J should get into the proxying or weaving business. By
that I mean the framework shouldn't gain the knowledge how to do it. It's a
specialization best deferred to the JDK, Spring, AspectJ, and other tools
that are devoted to the problem space. Rather, Log4J should provide all the
necessary annotations and glue and documentation to hook the feature up
using those tools.
On Feb 16, 2016 5:41 PM, "Matt Sicker" <bo...@gmail.com> wrote:
> I think a trace should be added for all return statements. If the method
> has no return statement, then it just goes at the end. I agree with the
> exceptional case Gary mentions as well.
>
> On 16 February 2016 at 16:55, Gary Gregory <ga...@gmail.com> wrote:
>
>> I did not explain myself correctly because I am talking about editing
>> class files, not java files. Or being part of the byte code generation,
>> however that works.
>>
>> Also the trace on finally you describe is a no go for me. I want to *not*
>> see a trace exit when an exception is thrown.
>>
>> Gary
>> On Feb 16, 2016 12:53 PM, "Ralph Goers" <ra...@dslextreme.com>
>> wrote:
>>
>>> If it worked that way the annotation processor would have to act as
>>> pre-processor and generate new .java files that would then be compiled. My
>>> expectation is that this functionality would be built into the existing
>>> annotation processor and the logging would be added during the compilation
>>> process, so users wouldn’t actually be able to see the logging calls in
>>> their source code. As such they could just be logger.trace calls with the
>>> correct Marker, etc added. Essentially it would be as if the pattern
>>>
>>> logger.trace(…. entry);
>>> try {
>>> existing code
>>> } finally {
>>> logger.trace(… exit);
>>> }
>>>
>>> was injected into every method enabled for logging.
>>>
>>> Ralph
>>>
>>> On Feb 16, 2016, at 12:40 PM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>> In my mind, the annotations would cause a build to inject code into
>>> class files using the new traceEntry/Exit APIs. That's the easiest to
>>> understand IMO. It would also generate the simplest code. It also does not
>>> force you into using annotations if you want to "see" the real thing in
>>> your code.
>>>
>>> Gary
>>>
>>> On Tue, Feb 16, 2016 at 9:21 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> I'd much prefer the annotation approach.
>>>>
>>>> On 16 February 2016 at 10:35, Ralph Goers <ra...@dslextreme.com>
>>>> wrote:
>>>>
>>>>> SLF4J created XLogger to do this. I wasn’t really happy with that and
>>>>> so added the methods to the Logger class when I started Log4j 2.
>>>>>
>>>>> The more I think about this I am wondering if the effort shouldn’t
>>>>> just be spent on implementing the annotations rather than arguing about
>>>>> this stuff. The annotations don’t actually require these methods to be able
>>>>> to implement the functionality.
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 16, 2016, at 9:20 AM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Well, you just need one interface: FlowLogger and all traceEntry and
>>>>> traceExit methods can live there. But that means that a user must hold on
>>>>> to 2 loggers for a given class for example. Unless FlowLogger extends
>>>>> Logger. Then you'd also need to add getFlowLogger methods to LogManager.
>>>>>
>>>>> Which is better?
>>>>> On Feb 15, 2016 7:58 PM, "Paul Benedict" <pb...@apache.org> 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 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 <ga...@gmail.com> 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 a method once, not once per level. Then you say
>>>>>> logger.alevel.log(...).
>>>>>>
>>>>>> Gary
>>>>>> On Feb 15, 2016 3:47 PM, "Remko Popma" <re...@gmail.com> 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, ... (up to how many?)
>>>>>>> Especially if we want to also prevent auto boxing in all possible
>>>>>>> combinations of the primitive types boolean, long and double.
>>>>>>>
>>>>>>> There may be other ways to accomplish this. Let's think about this a
>>>>>>> bit longer. I'll add a Jira for this in the no-GC epic.
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>>
>>>>>>> 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 <ga...@gmail.com>
>>>>>>> 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
>>>>>>>> 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 50 columns per row.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>> Home: http://garygregory.com/
>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: traceExit and auto-boxing
Posted by Matt Sicker <bo...@gmail.com>.
I think a trace should be added for all return statements. If the method
has no return statement, then it just goes at the end. I agree with the
exceptional case Gary mentions as well.
On 16 February 2016 at 16:55, Gary Gregory <ga...@gmail.com> wrote:
> I did not explain myself correctly because I am talking about editing
> class files, not java files. Or being part of the byte code generation,
> however that works.
>
> Also the trace on finally you describe is a no go for me. I want to *not*
> see a trace exit when an exception is thrown.
>
> Gary
> On Feb 16, 2016 12:53 PM, "Ralph Goers" <ra...@dslextreme.com>
> wrote:
>
>> If it worked that way the annotation processor would have to act as
>> pre-processor and generate new .java files that would then be compiled. My
>> expectation is that this functionality would be built into the existing
>> annotation processor and the logging would be added during the compilation
>> process, so users wouldn’t actually be able to see the logging calls in
>> their source code. As such they could just be logger.trace calls with the
>> correct Marker, etc added. Essentially it would be as if the pattern
>>
>> logger.trace(…. entry);
>> try {
>> existing code
>> } finally {
>> logger.trace(… exit);
>> }
>>
>> was injected into every method enabled for logging.
>>
>> Ralph
>>
>> On Feb 16, 2016, at 12:40 PM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>> In my mind, the annotations would cause a build to inject code into class
>> files using the new traceEntry/Exit APIs. That's the easiest to understand
>> IMO. It would also generate the simplest code. It also does not force you
>> into using annotations if you want to "see" the real thing in your code.
>>
>> Gary
>>
>> On Tue, Feb 16, 2016 at 9:21 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> I'd much prefer the annotation approach.
>>>
>>> On 16 February 2016 at 10:35, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>>> SLF4J created XLogger to do this. I wasn’t really happy with that and
>>>> so added the methods to the Logger class when I started Log4j 2.
>>>>
>>>> The more I think about this I am wondering if the effort shouldn’t just
>>>> be spent on implementing the annotations rather than arguing about this
>>>> stuff. The annotations don’t actually require these methods to be able to
>>>> implement the functionality.
>>>>
>>>> Ralph
>>>>
>>>> On Feb 16, 2016, at 9:20 AM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>> Well, you just need one interface: FlowLogger and all traceEntry and
>>>> traceExit methods can live there. But that means that a user must hold on
>>>> to 2 loggers for a given class for example. Unless FlowLogger extends
>>>> Logger. Then you'd also need to add getFlowLogger methods to LogManager.
>>>>
>>>> Which is better?
>>>> On Feb 15, 2016 7:58 PM, "Paul Benedict" <pb...@apache.org> 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 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 <ga...@gmail.com> 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 a method once, not once per level. Then you say
>>>>> logger.alevel.log(...).
>>>>>
>>>>> Gary
>>>>> On Feb 15, 2016 3:47 PM, "Remko Popma" <re...@gmail.com> 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, ... (up to how many?) Especially
>>>>>> if we want to also prevent auto boxing in all possible combinations of the
>>>>>> primitive types boolean, long and double.
>>>>>>
>>>>>> There may be other ways to accomplish this. Let's think about this a
>>>>>> bit longer. I'll add a Jira for this in the no-GC epic.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>>>>>>
>>>>>> 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 <ga...@gmail.com>
>>>>>> 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
>>>>>>> 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 50 columns per row.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <bo...@gmail.com>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
--
Matt Sicker <bo...@gmail.com>
Re: traceExit and auto-boxing
Posted by Gary Gregory <ga...@gmail.com>.
I did not explain myself correctly because I am talking about editing class
files, not java files. Or being part of the byte code generation, however
that works.
Also the trace on finally you describe is a no go for me. I want to *not*
see a trace exit when an exception is thrown.
Gary
On Feb 16, 2016 12:53 PM, "Ralph Goers" <ra...@dslextreme.com> wrote:
> If it worked that way the annotation processor would have to act as
> pre-processor and generate new .java files that would then be compiled. My
> expectation is that this functionality would be built into the existing
> annotation processor and the logging would be added during the compilation
> process, so users wouldn’t actually be able to see the logging calls in
> their source code. As such they could just be logger.trace calls with the
> correct Marker, etc added. Essentially it would be as if the pattern
>
> logger.trace(…. entry);
> try {
> existing code
> } finally {
> logger.trace(… exit);
> }
>
> was injected into every method enabled for logging.
>
> Ralph
>
> On Feb 16, 2016, at 12:40 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> In my mind, the annotations would cause a build to inject code into class
> files using the new traceEntry/Exit APIs. That's the easiest to understand
> IMO. It would also generate the simplest code. It also does not force you
> into using annotations if you want to "see" the real thing in your code.
>
> Gary
>
> On Tue, Feb 16, 2016 at 9:21 AM, Matt Sicker <bo...@gmail.com> wrote:
>
>> I'd much prefer the annotation approach.
>>
>> On 16 February 2016 at 10:35, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> SLF4J created XLogger to do this. I wasn’t really happy with that and so
>>> added the methods to the Logger class when I started Log4j 2.
>>>
>>> The more I think about this I am wondering if the effort shouldn’t just
>>> be spent on implementing the annotations rather than arguing about this
>>> stuff. The annotations don’t actually require these methods to be able to
>>> implement the functionality.
>>>
>>> Ralph
>>>
>>> On Feb 16, 2016, at 9:20 AM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>> Well, you just need one interface: FlowLogger and all traceEntry and
>>> traceExit methods can live there. But that means that a user must hold on
>>> to 2 loggers for a given class for example. Unless FlowLogger extends
>>> Logger. Then you'd also need to add getFlowLogger methods to LogManager.
>>>
>>> Which is better?
>>> On Feb 15, 2016 7:58 PM, "Paul Benedict" <pb...@apache.org> 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 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 <ga...@gmail.com> 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 a method once, not once per level. Then you say
>>>> logger.alevel.log(...).
>>>>
>>>> Gary
>>>> On Feb 15, 2016 3:47 PM, "Remko Popma" <re...@gmail.com> 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, ... (up to how many?) Especially
>>>>> if we want to also prevent auto boxing in all possible combinations of the
>>>>> primitive types boolean, long and double.
>>>>>
>>>>> There may be other ways to accomplish this. Let's think about this a
>>>>> bit longer. I'll add a Jira for this in the no-GC epic.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> 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 <ga...@gmail.com>
>>>>> 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
>>>>>> 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 50 columns per row.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>> <http://www.manning.com/bauer3/>
>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>> Blog: http://garygregory.wordpress.com
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
Re: traceExit and auto-boxing
Posted by Ralph Goers <ra...@dslextreme.com>.
If it worked that way the annotation processor would have to act as pre-processor and generate new .java files that would then be compiled. My expectation is that this functionality would be built into the existing annotation processor and the logging would be added during the compilation process, so users wouldn’t actually be able to see the logging calls in their source code. As such they could just be logger.trace calls with the correct Marker, etc added. Essentially it would be as if the pattern
logger.trace(…. entry);
try {
existing code
} finally {
logger.trace(… exit);
}
was injected into every method enabled for logging.
Ralph
> On Feb 16, 2016, at 12:40 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> In my mind, the annotations would cause a build to inject code into class files using the new traceEntry/Exit APIs. That's the easiest to understand IMO. It would also generate the simplest code. It also does not force you into using annotations if you want to "see" the real thing in your code.
>
> Gary
>
> On Tue, Feb 16, 2016 at 9:21 AM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
> I'd much prefer the annotation approach.
>
> On 16 February 2016 at 10:35, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> SLF4J created XLogger to do this. I wasn’t really happy with that and so added the methods to the Logger class when I started Log4j 2.
>
> The more I think about this I am wondering if the effort shouldn’t just be spent on implementing the annotations rather than arguing about this stuff. The annotations don’t actually require these methods to be able to implement the functionality.
>
> Ralph
>
>> On Feb 16, 2016, at 9:20 AM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>
>> Well, you just need one interface: FlowLogger and all traceEntry and traceExit methods can live there. But that means that a user must hold on to 2 loggers for a given class for example. Unless FlowLogger extends Logger. Then you'd also need to add getFlowLogger methods to LogManager.
>>
>> Which is better?
>>
>> On Feb 15, 2016 7:58 PM, "Paul Benedict" <pbenedict@apache.org <ma...@apache.org>> 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 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 <garydgregory@gmail.com <ma...@gmail.com>> 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 a method once, not once per level. Then you say logger.alevel.log(...).
>>>
>>> Gary
>>>
>>> On Feb 15, 2016 3:47 PM, "Remko Popma" <remko.popma@gmail.com <ma...@gmail.com>> 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, ... (up to how many?) Especially if we want to also prevent auto boxing in all possible combinations of the primitive types boolean, long and double.
>>>
>>> There may be other ways to accomplish this. Let's think about this a bit longer. I'll add a Jira for this in the no-GC epic.
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/02/16, at 1:59, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>
>>>> 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 <garydgregory@gmail.com <ma...@gmail.com>> 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 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 50 columns per row.
>>>>
>>>> Thoughts?
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>>>> Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
>>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
> Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Re: traceExit and auto-boxing
Posted by Gary Gregory <ga...@gmail.com>.
In my mind, the annotations would cause a build to inject code into class
files using the new traceEntry/Exit APIs. That's the easiest to understand
IMO. It would also generate the simplest code. It also does not force you
into using annotations if you want to "see" the real thing in your code.
Gary
On Tue, Feb 16, 2016 at 9:21 AM, Matt Sicker <bo...@gmail.com> wrote:
> I'd much prefer the annotation approach.
>
> On 16 February 2016 at 10:35, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> SLF4J created XLogger to do this. I wasn’t really happy with that and so
>> added the methods to the Logger class when I started Log4j 2.
>>
>> The more I think about this I am wondering if the effort shouldn’t just
>> be spent on implementing the annotations rather than arguing about this
>> stuff. The annotations don’t actually require these methods to be able to
>> implement the functionality.
>>
>> Ralph
>>
>> On Feb 16, 2016, at 9:20 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> Well, you just need one interface: FlowLogger and all traceEntry and
>> traceExit methods can live there. But that means that a user must hold on
>> to 2 loggers for a given class for example. Unless FlowLogger extends
>> Logger. Then you'd also need to add getFlowLogger methods to LogManager.
>>
>> Which is better?
>> On Feb 15, 2016 7:58 PM, "Paul Benedict" <pb...@apache.org> 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 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 <ga...@gmail.com> 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 a method once, not once per level. Then you say
>>> logger.alevel.log(...).
>>>
>>> Gary
>>> On Feb 15, 2016 3:47 PM, "Remko Popma" <re...@gmail.com> 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, ... (up to how many?) Especially
>>>> if we want to also prevent auto boxing in all possible combinations of the
>>>> primitive types boolean, long and double.
>>>>
>>>> There may be other ways to accomplish this. Let's think about this a
>>>> bit longer. I'll add a Jira for this in the no-GC epic.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> 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 <ga...@gmail.com>
>>>> 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
>>>>> 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 50 columns per row.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Gary
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: traceExit and auto-boxing
Posted by Matt Sicker <bo...@gmail.com>.
I'd much prefer the annotation approach.
On 16 February 2016 at 10:35, Ralph Goers <ra...@dslextreme.com>
wrote:
> SLF4J created XLogger to do this. I wasn’t really happy with that and so
> added the methods to the Logger class when I started Log4j 2.
>
> The more I think about this I am wondering if the effort shouldn’t just be
> spent on implementing the annotations rather than arguing about this stuff.
> The annotations don’t actually require these methods to be able to
> implement the functionality.
>
> Ralph
>
> On Feb 16, 2016, at 9:20 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Well, you just need one interface: FlowLogger and all traceEntry and
> traceExit methods can live there. But that means that a user must hold on
> to 2 loggers for a given class for example. Unless FlowLogger extends
> Logger. Then you'd also need to add getFlowLogger methods to LogManager.
>
> Which is better?
> On Feb 15, 2016 7:58 PM, "Paul Benedict" <pb...@apache.org> 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 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 <ga...@gmail.com> 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 a method once, not once per level. Then you say
>> logger.alevel.log(...).
>>
>> Gary
>> On Feb 15, 2016 3:47 PM, "Remko Popma" <re...@gmail.com> 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, ... (up to how many?) Especially
>>> if we want to also prevent auto boxing in all possible combinations of the
>>> primitive types boolean, long and double.
>>>
>>> There may be other ways to accomplish this. Let's think about this a bit
>>> longer. I'll add a Jira for this in the no-GC epic.
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> 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 <ga...@gmail.com>
>>> 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
>>>> 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 50 columns per row.
>>>>
>>>> Thoughts?
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>
--
Matt Sicker <bo...@gmail.com>
Re: traceExit and auto-boxing
Posted by Ralph Goers <ra...@dslextreme.com>.
SLF4J created XLogger to do this. I wasn’t really happy with that and so added the methods to the Logger class when I started Log4j 2.
The more I think about this I am wondering if the effort shouldn’t just be spent on implementing the annotations rather than arguing about this stuff. The annotations don’t actually require these methods to be able to implement the functionality.
Ralph
> On Feb 16, 2016, at 9:20 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Well, you just need one interface: FlowLogger and all traceEntry and traceExit methods can live there. But that means that a user must hold on to 2 loggers for a given class for example. Unless FlowLogger extends Logger. Then you'd also need to add getFlowLogger methods to LogManager.
>
> Which is better?
>
> On Feb 15, 2016 7:58 PM, "Paul Benedict" <pbenedict@apache.org <ma...@apache.org>> 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 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 <garydgregory@gmail.com <ma...@gmail.com>> 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 a method once, not once per level. Then you say logger.alevel.log(...).
>>
>> Gary
>>
>> On Feb 15, 2016 3:47 PM, "Remko Popma" <remko.popma@gmail.com <ma...@gmail.com>> 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, ... (up to how many?) Especially if we want to also prevent auto boxing in all possible combinations of the primitive types boolean, long and double.
>>
>> There may be other ways to accomplish this. Let's think about this a bit longer. I'll add a Jira for this in the no-GC epic.
>>
>> Sent from my iPhone
>>
>> On 2016/02/16, at 1:59, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>
>>> 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 <garydgregory@gmail.com <ma...@gmail.com>> 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 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 50 columns per row.
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
>>> Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: traceExit and auto-boxing
Posted by Gary Gregory <ga...@gmail.com>.
Well, you just need one interface: FlowLogger and all traceEntry and
traceExit methods can live there. But that means that a user must hold on
to 2 loggers for a given class for example. Unless FlowLogger extends
Logger. Then you'd also need to add getFlowLogger methods to LogManager.
Which is better?
On Feb 15, 2016 7:58 PM, "Paul Benedict" <pb...@apache.org> 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 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 <ga...@gmail.com> 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 a method once, not once per level. Then you say
> logger.alevel.log(...).
>
> Gary
> On Feb 15, 2016 3:47 PM, "Remko Popma" <re...@gmail.com> 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, ... (up to how many?) Especially
>> if we want to also prevent auto boxing in all possible combinations of the
>> primitive types boolean, long and double.
>>
>> There may be other ways to accomplish this. Let's think about this a bit
>> longer. I'll add a Jira for this in the no-GC epic.
>>
>> Sent from my iPhone
>>
>> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>>
>> 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 <ga...@gmail.com>
>> 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
>>> 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 50 columns per row.
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
Re: traceExit and auto-boxing
Posted by Paul Benedict <pb...@apache.org>.
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 <ga...@gmail.com> 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 a method once, not once per level. Then you say
logger.alevel.log(...).
Gary
On Feb 15, 2016 3:47 PM, "Remko Popma" <re...@gmail.com> 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, ... (up to how many?) Especially
> if we want to also prevent auto boxing in all possible combinations of the
> primitive types boolean, long and double.
>
> There may be other ways to accomplish this. Let's think about this a bit
> longer. I'll add a Jira for this in the no-GC epic.
>
> Sent from my iPhone
>
> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>
> 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 <ga...@gmail.com> 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
>> 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 50 columns per row.
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
Re: traceExit and auto-boxing
Posted by Remko Popma <re...@gmail.com>.
Yep, that's definitely one of the candidates for a solution.
Sent from my iPhone
> On 2016/02/16, at 9:43, Gary Gregory <ga...@gmail.com> 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 a method once, not once per level. Then you say logger.alevel.log(...).
>
> Gary
>
>> On Feb 15, 2016 3:47 PM, "Remko Popma" <re...@gmail.com> 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, ... (up to how many?) Especially if we want to also prevent auto boxing in all possible combinations of the primitive types boolean, long and double.
>>
>> There may be other ways to accomplish this. Let's think about this a bit longer. I'll add a Jira for this in the no-GC epic.
>>
>> Sent from my iPhone
>>
>>> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> 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 <ga...@gmail.com> 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 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 50 columns per row.
>>>>
>>>> Thoughts?
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> JUnit in Action, Second Edition
>>>> Spring Batch in Action
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
Re: traceExit and auto-boxing
Posted by Gary Gregory <ga...@gmail.com>.
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" <re...@gmail.com> 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, ... (up to how many?) Especially
> if we want to also prevent auto boxing in all possible combinations of the
> primitive types boolean, long and double.
>
> There may be other ways to accomplish this. Let's think about this a bit
> longer. I'll add a Jira for this in the no-GC epic.
>
> Sent from my iPhone
>
> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>
> 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 <ga...@gmail.com> 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
>> 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 50 columns per row.
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
Re: traceExit and auto-boxing
Posted by Matt Sicker <bo...@gmail.com>.
Oh wow, I didn't realise it was so big already.
On 15 February 2016 at 17:46, Remko Popma <re...@gmail.com> 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, ... (up to how many?) Especially
> if we want to also prevent auto boxing in all possible combinations of the
> primitive types boolean, long and double.
>
> There may be other ways to accomplish this. Let's think about this a bit
> longer. I'll add a Jira for this in the no-GC epic.
>
> Sent from my iPhone
>
> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>
> 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 <ga...@gmail.com> 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
>> 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 50 columns per row.
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: traceExit and auto-boxing
Posted by Remko Popma <re...@gmail.com>.
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 primitive types boolean, long and double.
There may be other ways to accomplish this. Let's think about this a bit longer. I'll add a Jira for this in the no-GC epic.
Sent from my iPhone
> On 2016/02/16, at 1:59, Matt Sicker <bo...@gmail.com> wrote:
>
> 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 <ga...@gmail.com> 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 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 50 columns per row.
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: traceExit and auto-boxing
Posted by Matt Sicker <bo...@gmail.com>.
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 <ga...@gmail.com> 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
> 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 50 columns per row.
>
> Thoughts?
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>