That's normally how it would be implemented, yeah. The annotation processor allows you to generate java code, but I've never worked with that part of the API.
On 9 February 2016 at 10:07, 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]> > 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 >> >> >> > -- Matt Sicker <[email protected]>
