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 <garydgreg...@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" <ralph.go...@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 <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> wrote:
>>
>>> I'd much prefer the annotation approach.
>>>
>>> On 16 February 2016 at 10:35, Ralph Goers <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>
>>>> 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> 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> 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> 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> 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>
>>>>>> 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 | 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
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matt Sicker <boa...@gmail.com>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <boa...@gmail.com>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | 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
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
--
Matt Sicker <boa...@gmail.com>
