On Mon, Feb 8, 2016 at 12:09 PM, Paul Benedict <[email protected]> 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 <[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 >> > > -- 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
