I’d have to let Gary comment on what he does or doesn’t want. I could envision using a proxy for this that should perform fairly well. I believe It could inject method names and line numbers where appropriate, saving the overhead of walking the stack.
Ralph > On Feb 9, 2016, at 9:07 AM, Paul Benedict <[email protected]> wrote: > > Ralph, doesn't that require weaving or proxying? I think Gary was trying to > avoid both of those solutions. > > Cheers, > Paul > > On Tue, Feb 9, 2016 at 9:56 AM, Ralph Goers <[email protected] > <mailto:[email protected]>> wrote: > One thing I would really like to to is to create compile time annotations > that we could use as an alternative to entry and exit tracing. As Bruce > Brouwer mentioned in LOG4J2-33 we could do something like: > > > public class LogExample { > private static final Logger LOGGER = LogManager.getLogger(); > > @LogEntryExit > public void handleRequest(@Log(format=“json”) Request request) { > // do something > } > } > > I could imagine that this could be made to be even more flexible. > > Ralph > > > >> On Feb 8, 2016, at 2:39 PM, Gary Gregory <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Mon, Feb 8, 2016 at 12:30 PM, Paul Benedict <[email protected] >> <mailto:[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] >> <mailto:[email protected]>> wrote: >> On Mon, Feb 8, 2016 at 12:22 PM, Paul Benedict <[email protected] >> <mailto:[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 >> <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 >> <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] >> <mailto:[email protected]>> wrote: >> On Mon, Feb 8, 2016 at 12:09 PM, Paul Benedict <[email protected] >> <mailto:[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] >> <mailto:[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] >> <mailto:[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] >> <mailto:[email protected]>> wrote: >> On Mon, Feb 8, 2016 at 9:29 AM, Ralph Goers <[email protected] >> <mailto:[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] >> > <mailto:[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] <mailto:[email protected]> | >> > [email protected] <mailto:[email protected]> >> > Java Persistence with Hibernate, Second Edition >> > <http://www.manning.com/bauer3/ <http://www.manning.com/bauer3/>> >> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/ >> > <http://www.manning.com/tahchiev/>> >> > Spring Batch in Action <http://www.manning.com/templier/ >> > <http://www.manning.com/templier/>> >> > Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> >> > Home: http://garygregory.com/ <http://garygregory.com/> >> > Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> <mailto:[email protected]> >> For additional commands, e-mail: [email protected] >> <mailto:[email protected]> >> >> >> >> >> -- >> E-Mail: [email protected] <mailto:[email protected]> | >> [email protected] <mailto:[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 <http://garygregory.wordpress.com/> >> Home: http://garygregory.com/ <http://garygregory.com/> >> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >> >> >> -- >> Matt Sicker <[email protected] <mailto:[email protected]>> >> >> >> >> -- >> E-Mail: [email protected] <mailto:[email protected]> | >> [email protected] <mailto:[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 <http://garygregory.wordpress.com/> >> Home: http://garygregory.com/ <http://garygregory.com/> >> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >> >> >> >> -- >> E-Mail: [email protected] <mailto:[email protected]> | >> [email protected] <mailto:[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 <http://garygregory.wordpress.com/> >> Home: http://garygregory.com/ <http://garygregory.com/> >> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >> >> >> >> -- >> E-Mail: [email protected] <mailto:[email protected]> | >> [email protected] <mailto:[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 <http://garygregory.wordpress.com/> >> Home: http://garygregory.com/ <http://garygregory.com/> >> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >> >> >> >> -- >> E-Mail: [email protected] <mailto:[email protected]> | >> [email protected] <mailto:[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 <http://garygregory.wordpress.com/> >> Home: http://garygregory.com/ <http://garygregory.com/> >> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >
