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: New traceEntry code
Date Mon, 08 Feb 2016 20:19:31 GMT
On Mon, Feb 8, 2016 at 12:09 PM, Paul Benedict <pbenedict@apache.org> wrote:

> Since tracing is orthogonal to speed,
>

Sure, but we should strive to avoid sub-optimal design choices. Tracing
will be slower and no logging, but we can make it less painful hopefully.


> I think logging method entry/exit points should be done in a stack
> push/pop fashion. Rather than have traceEntry() return the string, the
> logger should keep track of the entry so it can pop it.
>

How would that work when a logger is used from multiple threads? You'd need
a per-thread-stack? Sounds heavy; can you flush out this idea please?


> Otherwise, there isn't much use at all, I think, to what's being proposed.
> I think the method needs much more provided value for it to be useful.
>

For example?

Thank you,
Gary


>
> Cheers,
> Paul
>
> On Mon, Feb 8, 2016 at 2:05 PM, Gary Gregory <garydgregory@gmail.com>
> wrote:
>
>> We use flow tracing *only* for the APIs in the JDBC specification we
>> implement (and a small select handful of other method).
>>
>> Using flow tracing everywhere would be silly IMO, for this use case,
>> implementing a JDBC driver.
>>
>> AspectJ is too heavy IMO anyway and a PITA to debug.
>>
>> Gary
>>
>> On Mon, Feb 8, 2016 at 12:00 PM, Matt Sicker <boards@gmail.com> wrote:
>>
>>> Have you ever tried using AspectJ to insert entry and exit log messages
>>> everywhere? You get the arg list in a join point.
>>>
>>> On 8 February 2016 at 13:58, Gary Gregory <garydgregory@gmail.com>
>>> wrote:
>>>
>>>> On Mon, Feb 8, 2016 at 9:29 AM, Ralph Goers <ralph.goers@dslextreme.com
>>>> > wrote:
>>>>
>>>>> First, this probably should be on the dev list, not the users list.
>>>>>
>>>>> Second, the sample methods you provided all take a method parameter.
>>>>> Log4j’s don’t as they rely on the caller’s location information
to get
>>>>> that, so traceExit doesn’t take a method parameter as you show below.
>>>>>
>>>>
>>>> Hi All,
>>>>
>>>> Right, I did that since I had to invent my own flow tracing and get the
>>>> behavior that we need. I also avoided looking at the stack to find the
>>>> method name, which is obviously faster but quite error prone. It's a shame
>>>> to look at the stack twice, on entry AND on exit to capture the method
>>>> name. I want to avoid that. A goal for us at work is to use trace logging
>>>> in our CI builds and log everything, we are not there yet for a number of
>>>> reasons.
>>>>
>>>> I want to capture everything on method entry, then the traceExit call
>>>> can reuse the object (for me a String, for the new feature this could be
a
>>>> Message that carries the method name.) That would lighten flow tracing
>>>> since we would only look at the stack once.
>>>>
>>>> I'll keep playing with it...
>>>>
>>>> Gary
>>>>
>>>>
>>>>>
>>>>> I’ll add the @since tags and make sure more unit tests are present.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>> > On Feb 8, 2016, at 10:17 AM, Gary Gregory <garydgregory@gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > Hi All:
>>>>> >
>>>>> > The pattern I've had to implement for our product is close to what
>>>>> this
>>>>> > does, but not quite, so I'd like to propose changes.
>>>>> >
>>>>> > The key part is for the new traceEntry methods to return the String
>>>>> message
>>>>> > it built so I can reuse it in the traceExit() call. This is how
I do
>>>>> it now:
>>>>> >
>>>>> > public int doFoo(int a, int b) {
>>>>> >  final String method = traceEntry("doFoo(a=%,d, b=%,d", a, b);
>>>>> >  // do Foo impl
>>>>> >  int result = ...
>>>>> >  return traceExit(method, result);
>>>>> > }
>>>>> >
>>>>> > This allows the Entry/Exit log events to match nicely, especially
in
>>>>> our
>>>>> > multi-threaded use cases. It's easier to tell which exit matches
>>>>> which
>>>>> > entry. You do not want to compute the method String more than once
of
>>>>> > course.
>>>>> >
>>>>> > (I use the String.format() message factory to get nice looking
>>>>> numbers, and
>>>>> > so on. We allow that to be set up at the logger level, which is
>>>>> nice.)
>>>>> >
>>>>> > I've had to cookup my own my own traceEntry/traceExit, otherwise
the
>>>>> code
>>>>> > would be logger.traceEntry(...).
>>>>> >
>>>>> > The verbiage I use is also different: I use a verb: "Enter", as
>>>>> opposed to
>>>>> > the noun "entry", which looks really weird in English to me. "Entry
>>>>> > methodName"? That does not sound good to me "Entry of methodName"
>>>>> OK. For
>>>>> > me it's "Enter methodName..." and "Exit methodName". Sentences start
>>>>> with a
>>>>> > cap too.
>>>>> >
>>>>> > It's too late to change the API names but the wording should be
fixed
>>>>> > (calling it broken is my opinion of course) or configurable.
>>>>> >
>>>>> > The new methods are missing @since Javadoc tags
>>>>> >
>>>>> > I could only find a unit for 1 of the new APIs, did I miss the
>>>>> others?
>>>>> >
>>>>> > I'll experiment unless I hear howls of horror...
>>>>> >
>>>>> > 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
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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>
>>>
>>
>>
>>
>> --
>> 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
>>
>
>


-- 
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