When I have implemented trace logging, I have done it with EJB 3 or Spring because I can proxy my objects. It takes out all the logging code and encapsulates it into one class, which is preferable, because method tracing is (1) repetitive/duplicate code and (2) ancillary to the method's purpose.
Gary, if you can proxy your object and encapsulate your method entry/exit code, that would be ideal. Cheers, Paul On Mon, Feb 8, 2016 at 2:26 PM, Gary Gregory <[email protected]> wrote: > 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 >
