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" <boa...@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 <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>
>

Reply via email to