True, but I should be able to save the method name and number in an object that can be used by the proxy.
Ralph > On Feb 9, 2016, at 10:25 AM, Paul Benedict <[email protected]> wrote: > > I think line numbers can only be done in weaving mode. When you're proxying, > OTOH, you don't have the line numbers of the target -- but you would have the > method name. > > Cheers, > Paul > > On Tue, Feb 9, 2016 at 10:39 AM, Ralph Goers <[email protected] > <mailto:[email protected]>> wrote: > 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] >> <mailto:[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> >> > >
