I didn’t write this particular test. I will have to find it. Ralph
> On Oct 5, 2018, at 11:28 AM, Mandy Chung <mandy.ch...@oracle.com> wrote: > > I recalled at one point you showed your benchmark that > actually walks the entire stack. So does your benchmark > compare walking N number of frames with different Ns and > also entire stack? > > Mandy > > On 10/4/18 9:46 PM, Ralph Goers wrote: >> I should have rephrased this. We cannot assume that the caller of the Log4j >> API method is the caller we need. It might be another Log4j API method or >> another logging Adapter. Since walking the stack trace is relatively slow we >> have to defer doing it until we absolutely need to. This generally means we >> are not walking only a few frames. We have run benchmarks that show using >> SecurityManager to find the caller class is faster than using StackWalker. >> >> https://lists.apache.org/thread.html/29ca67b98c8a508f2836301ac33747b72ca0ce86f69f466073412bfc@%3Cdev.logging.apache.org%3E >> >> <https://lists.apache.org/thread.html/29ca67b98c8a508f2836301ac33747b72ca0ce86f69f466073412bfc@%3Cdev.logging.apache.org%3E> >> >> Ralph >> >>> On Oct 4, 2018, at 9:25 PM, Ralph Goers <rgo...@apache.org >>> <mailto:rgo...@apache.org>> wrote: >>> >>> Unfortunately, we can’t use getCallerClass. Some API methods can be called >>> by users of the API or by other methods in the API class. >>> >>> Ralph >>> >>>> On Oct 4, 2018, at 2:50 PM, Mandy Chung <mandy.ch...@oracle.com >>>> <mailto:mandy.ch...@oracle.com>> wrote: >>>> >>>> If you are looking for the immediate caller, you can try >>>> StackWalker::getCallerClass which only walks the top few >>>> frames and intends to be lower cost. >>>> >>>> Mandy >>>> >>>> On 10/4/18 2:04 PM, Ralph Goers wrote: >>>>> Hmm, it would probably be a safe assumption that a Logger will never be >>>>> used outside of the module. That isn’t true of the class name, method >>>>> name and line number though. I’m not sure how much extra overhead there >>>>> is in collecting the module name when you have to collect those to. >>>>> >>>>> I should add that when printing exceptions we do cache the file >>>>> name/location as we are processing the classes for an extended stack >>>>> trace. We probably will want to add the module name to the extended stack >>>>> trace as well. >>>>> >>>>> Ralph >>>>> >>>>>> On Oct 4, 2018, at 10:26 AM, fo...@univ-mlv.fr >>>>>> <mailto:fo...@univ-mlv.fr> wrote: >>>>>> >>>>>> I was thinking about capturing the call stack when you create the logger >>>>>> (to get the module), not when you call the logger. >>>>>> >>>>>> cheers, >>>>>> Rémi >>>>>> >>>>>> ----- Mail original ----- >>>>>>> De: "Ralph Goers" <ralph.go...@dslextreme.com> >>>>>>> <mailto:ralph.go...@dslextreme.com> >>>>>>> À: "Alex Sviridov" <ooo_satu...@mail.ru> <mailto:ooo_satu...@mail.ru> >>>>>>> Cc: "Remi Forax" <fo...@univ-mlv.fr> <mailto:fo...@univ-mlv.fr>, >>>>>>> "jigsaw-dev" <jigsaw-dev@openjdk.java.net> >>>>>>> <mailto:jigsaw-dev@openjdk.java.net> >>>>>>> Envoyé: Mercredi 3 Octobre 2018 05:08:27 >>>>>>> Objet: Re: Separate logging for JPMS module/layer >>>>>>> Log4j handles this by capturing the fully qualified class name of the >>>>>>> logging >>>>>>> adapter. Obviously, this doesn’t work if the adapter doesn’t pass Log4j >>>>>>> the >>>>>>> FQCN, but it does work for the adapters we support. That said, it is >>>>>>> very slow >>>>>>> to capture this and is probably the biggest pain point. Log4j >>>>>>> recommends not >>>>>>> capturing this information in production environments because it is so >>>>>>> slow. >>>>>>> Unfortunately, it seems to have gotten even slower in Java 9+. In an >>>>>>> ideal >>>>>>> world we would be able to capture the caller information at compile >>>>>>> time but >>>>>>> Java provides no good way to do this. Wouldn’t it be great if I could >>>>>>> just code >>>>>>> something like logger.error(_CallerInfo_, “hello”) and the compiler >>>>>>> would >>>>>>> provide the caller info data structure that was generated by the >>>>>>> compiler? >>>>>>> >>>>>>> FWIW, I do plan to add the module information to the caller information >>>>>>> provided >>>>>>> with Log4j but just haven’t gotten to it. You are more than welcome to >>>>>>> provide >>>>>>> a patch. >>>>>>> >>>>>>> Ralph >>>>>>> >>>>>>>> On Oct 2, 2018, at 3:20 PM, Alex Sviridov <ooo_satu...@mail.ru> >>>>>>>> <mailto:ooo_satu...@mail.ru> wrote: >>>>>>>> >>>>>>>> Thank you for you suggestion. But can this be used when some library >>>>>>>> uses one logging system and for another uses some bridge. Because of >>>>>>>> this >>>>>>>> bridging >>>>>>>> LoggerFactory.getLogger is called somewhere in bridge, as I understand, >>>>>>>> >>>>>>>> >>>>>>>>> Среда, 3 октября 2018, 1:12 +03:00 от Remi Forax <fo...@univ-mlv.fr> >>>>>>>>> <mailto:fo...@univ-mlv.fr>: >>>>>>>>> >>>>>>>>> You can use the StackWalker >>>>>>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/StackWalker.html >>>>>>>>> >>>>>>>>> <https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/StackWalker.html> >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> Rémi >>>>>>>>> >>>>>>>>> ----- Mail original ----- >>>>>>>>>> De: "Alex Sviridov" < ooo_satu...@mail.ru >>>>>>>>>> <mailto:ooo_satu...@mail.ru> > >>>>>>>>>> À: "jigsaw-dev" < jigsaw-dev@openjdk.java.net >>>>>>>>>> <mailto:jigsaw-dev@openjdk.java.net> > >>>>>>>>>> Envoyé: Mardi 2 Octobre 2018 23:54:48 >>>>>>>>>> Objet: Separate logging for JPMS module/layer >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Could anyone say how the following problem can be solved. I want to >>>>>>>>>> create >>>>>>>>>> separate >>>>>>>>>> log file for every JPMS module/layer. The problem is that many >>>>>>>>>> libraries/programs >>>>>>>>>> use LoggerFactory.getLogger(String className) so in getLogger I have >>>>>>>>>> only >>>>>>>>>> the name of the class as String, so I can't get module and layer. >>>>>>>>>> >>>>>>>>>> If I had not String className, but Class klass then the problem >>>>>>>>>> would be easily >>>>>>>>>> solved. >>>>>>>>>> As I understand I can't load class by name because it would require >>>>>>>>>> all modules >>>>>>>>>> export >>>>>>>>>> their packages to logging framework that has no sense. >>>>>>>>>> >>>>>>>>>> Are there any solutions for such problem? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Alex Sviridov >>>>>>>> -- >>>>>>>> Alex Sviridov >>>> >>> >> >
