I did not explain myself correctly because I am talking about editing class files, not java files. Or being part of the byte code generation, however that works.
Also the trace on finally you describe is a no go for me. I want to *not* see a trace exit when an exception is thrown. Gary On Feb 16, 2016 12:53 PM, "Ralph Goers" <[email protected]> wrote: > If it worked that way the annotation processor would have to act as > pre-processor and generate new .java files that would then be compiled. My > expectation is that this functionality would be built into the existing > annotation processor and the logging would be added during the compilation > process, so users wouldn’t actually be able to see the logging calls in > their source code. As such they could just be logger.trace calls with the > correct Marker, etc added. Essentially it would be as if the pattern > > logger.trace(…. entry); > try { > existing code > } finally { > logger.trace(… exit); > } > > was injected into every method enabled for logging. > > Ralph > > On Feb 16, 2016, at 12:40 PM, Gary Gregory <[email protected]> wrote: > > In my mind, the annotations would cause a build to inject code into class > files using the new traceEntry/Exit APIs. That's the easiest to understand > IMO. It would also generate the simplest code. It also does not force you > into using annotations if you want to "see" the real thing in your code. > > Gary > > On Tue, Feb 16, 2016 at 9:21 AM, Matt Sicker <[email protected]> wrote: > >> I'd much prefer the annotation approach. >> >> On 16 February 2016 at 10:35, Ralph Goers <[email protected]> >> wrote: >> >>> SLF4J created XLogger to do this. I wasn’t really happy with that and so >>> added the methods to the Logger class when I started Log4j 2. >>> >>> The more I think about this I am wondering if the effort shouldn’t just >>> be spent on implementing the annotations rather than arguing about this >>> stuff. The annotations don’t actually require these methods to be able to >>> implement the functionality. >>> >>> Ralph >>> >>> On Feb 16, 2016, at 9:20 AM, Gary Gregory <[email protected]> >>> wrote: >>> >>> Well, you just need one interface: FlowLogger and all traceEntry and >>> traceExit methods can live there. But that means that a user must hold on >>> to 2 loggers for a given class for example. Unless FlowLogger extends >>> Logger. Then you'd also need to add getFlowLogger methods to LogManager. >>> >>> Which is better? >>> On Feb 15, 2016 7:58 PM, "Paul Benedict" <[email protected]> wrote: >>> >>>> You could create special interfaces for these sets of special methods. >>>> There is not a design rule that says Logger must be the interface that does >>>> all things. >>>> Yep, that's definitely one of the candidates for a solution. >>>> >>>> Sent from my iPhone >>>> >>>> On 2016/02/16, at 9:43, Gary Gregory <[email protected]> wrote: >>>> >>>> Which is one of the reasons I proposed "level logging". I'm on my phone >>>> so I can't do more that say there is a branch and Jira for my proposal. You >>>> only add a method once, not once per level. Then you say >>>> logger.alevel.log(...). >>>> >>>> Gary >>>> On Feb 15, 2016 3:47 PM, "Remko Popma" <[email protected]> wrote: >>>> >>>>> A word of caution: the Logger API already has 209 method (and I think >>>>> a few just got added). This will explode if we just add "var-arg >>>>> unrolling" >>>>> methods for 1 param, 2 params, 3 params, ... (up to how many?) Especially >>>>> if we want to also prevent auto boxing in all possible combinations of the >>>>> primitive types boolean, long and double. >>>>> >>>>> There may be other ways to accomplish this. Let's think about this a >>>>> bit longer. I'll add a Jira for this in the no-GC epic. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On 2016/02/16, at 1:59, Matt Sicker <[email protected]> wrote: >>>>> >>>>> Considering the garbage-free epic, this sounds like a good idea to >>>>> bake in from the start. >>>>> >>>>> On 15 February 2016 at 10:39, Gary Gregory <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi All: >>>>>> >>>>>> My my custom flow logger, I avoid auto-boxing on traceExit() calls by >>>>>> having primitive versions of the APIs. We could do the same and avoid >>>>>> auto-boxing unless a logger's level is enabled. >>>>>> >>>>>> This generates a lot less garbage when, for example, we flow trace >>>>>> our JDBC APIs and get 50m rows and 50 columns per row. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matt Sicker <[email protected]> >>>>> >>>>> >>> >> >> >> -- >> Matt Sicker <[email protected]> >> > > > > -- > 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 > > >
