On Mon, Feb 8, 2016 at 12:25 PM, Ralph Goers <[email protected]> wrote:
> I added a FlowMessage and an EntryMessage and ExitMessage that extends it. > These are primarily to wrap a Message to add the “entry” and “exit” text, > but it would be interesting to see if you could come up with a different > way to use them that could do what you want. > Hi All, I'll keep digging and fiddling. I'm barely scratching the surface of this new code :-) I'm looking forward to see if I can toss out all of our custom Log4j extensions with this new API. > > Of course, you can’t capture the exit line number without looking up the > location information. > I've not had that need yet. > This is one area where I really miss C preprocessing. We used Macros for > logging that captured the line number and method name at compile time > inside the macro. > I'm missing it either (yet!) Thank you, Gary > > Ralph > > On Feb 8, 2016, at 12:58 PM, 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] > <[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
