I think this weaving can be done using a javac annotation processing plugin: http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javac.html#processing
On Tue, Feb 9, 2016 at 6:43 PM, Ralph Goers <[email protected]> wrote: > 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]> > 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]> 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 >>> >>> >>> >> >> > > -- [image: MagineTV] *Mikael Ståldal* Senior software developer *Magine TV* [email protected] Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email.
