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]> 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]> wrote: > > 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] >>>>>>>>> <[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] >>>>>>> <[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] >>>>> <[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] >>> <[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] > <[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 > > >
