On Mon, Feb 8, 2016 at 12:22 PM, Paul Benedict <[email protected]> wrote:
> 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. > Hi Paul, I'm well aware of that. I'm far from convinced that this will end up being a workable solution. It is too easy to get your stacks to grow forever if your enter/exit calls are unbalanced. It's not an avenue I'm going to investigate today. Feel free to propose something more concrete though. Cheers to you as well! :-) Gary > > 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 >> > > -- 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
