logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: traceExit and auto-boxing
Date Tue, 16 Feb 2016 19:40:26 GMT
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> wrote:

> I'd much prefer the annotation approach.
>
> On 16 February 2016 at 10:35, Ralph Goers <ralph.goers@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> 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> 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> 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> 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> 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>
>>>> 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 <boards@gmail.com>
>>>>
>>>>
>>
>
>
> --
> Matt Sicker <boards@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

Mime
View raw message