That was the plan. We already have one to detect the plugins. Ralph
> On Feb 11, 2016, at 2:48 AM, Mikael Ståldal <[email protected]> wrote: > > 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] >>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>>>>>> Spring Batch in Action >>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Matt Sicker <[email protected]> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> E-Mail: [email protected] | [email protected] >>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>>>> Spring Batch in Action >>>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> E-Mail: [email protected] | [email protected] >>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>> Spring Batch in Action >>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> E-Mail: [email protected] | [email protected] >>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>> JUnit in Action, Second Edition >>>>>>>>> Spring Batch in Action >>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>> Home: http://garygregory.com/ >>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> E-Mail: [email protected] | [email protected] >>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>> JUnit in Action, Second Edition >>>>>>> Spring Batch in Action >>>>>>> Blog: http://garygregory.wordpress.com >>>>>>> Home: http://garygregory.com/ >>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>> >>>>> >>>> >>> >> > > > > -- > > > 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. >
