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 <garydgreg...@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 <boa...@gmail.com
> <mailto:boa...@gmail.com>> wrote:
> I'd much prefer the annotation approach.
>
> On 16 February 2016 at 10:35, Ralph Goers <ralph.go...@dslextreme.com
> <mailto:ralph.go...@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 <garydgreg...@gmail.com
>> <mailto:garydgreg...@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" <pbened...@apache.org
>> <mailto:pbened...@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 <garydgreg...@gmail.com
>> <mailto:garydgreg...@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.po...@gmail.com
>>> <mailto:remko.po...@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 <boa...@gmail.com
>>> <mailto:boa...@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 <garydgreg...@gmail.com
>>>> <mailto:garydgreg...@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: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> |
>>>> ggreg...@apache.org <mailto:ggreg...@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 <boa...@gmail.com <mailto:boa...@gmail.com>>
>
>
>
>
> --
> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> |
> ggreg...@apache.org <mailto:ggreg...@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>
