Gary, anything you want tied to a thread can be done by utilizing ThreadLocal: https://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html
Log4J is known to use this in the NDC implementation: https://logging.apache.org/log4j/2.x/manual/thread-context.html So just do something similar. Cheers, Paul On Mon, Feb 8, 2016 at 2:19 PM, Gary Gregory <[email protected]> wrote: > 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 >
