On Mon, Feb 8, 2016 at 12:30 PM, Paul Benedict <[email protected]> wrote:
> 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. > We use a different hack. We have 100's of classes that need to do flow tracing so we just have a common superclass to cover 95% of our use-cases. Gary > > 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 >> > > -- 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
