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 <[email protected]> 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 <[email protected]> wrote:
>
>> On Mon, Feb 8, 2016 at 9:29 AM, Ralph Goers <[email protected]>
>> 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 <[email protected]>
>>> 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: [email protected] | [email protected]
>>> > 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: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>>
>> --
>> E-Mail: [email protected] | [email protected]
>> 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 <[email protected]>
>



-- 
E-Mail: [email protected] | [email protected]
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

Reply via email to