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]> 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>
