Since tracing is orthogonal to speed, 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. 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.
Cheers, Paul On Mon, Feb 8, 2016 at 2:05 PM, Gary Gregory <[email protected]> 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 <[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 >
