I'd much prefer the annotation approach. On 16 February 2016 at 10:35, Ralph Goers <ralph.go...@dslextreme.com> 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 <garydgreg...@gmail.com> 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" <pbened...@apache.org> 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 <garydgreg...@gmail.com> 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" <remko.po...@gmail.com> 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 <boa...@gmail.com> 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 <garydgreg...@gmail.com> >>> 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: garydgreg...@gmail.com | ggreg...@apache.org >>>> 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 <boa...@gmail.com> >>> >>> > -- Matt Sicker <boa...@gmail.com>
