I didn’t write this particular test. I will have to find it. Ralph
> On Oct 5, 2018, at 11:28 AM, Mandy Chung <[email protected]> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> 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, [email protected] >>>>>> <mailto:[email protected]> 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" <[email protected]> >>>>>>> <mailto:[email protected]> >>>>>>> À: "Alex Sviridov" <[email protected]> <mailto:[email protected]> >>>>>>> Cc: "Remi Forax" <[email protected]> <mailto:[email protected]>, >>>>>>> "jigsaw-dev" <[email protected]> >>>>>>> <mailto:[email protected]> >>>>>>> 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 <[email protected]> >>>>>>>> <mailto:[email protected]> 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 <[email protected]> >>>>>>>>> <mailto:[email protected]>: >>>>>>>>> >>>>>>>>> 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" < [email protected] >>>>>>>>>> <mailto:[email protected]> > >>>>>>>>>> À: "jigsaw-dev" < [email protected] >>>>>>>>>> <mailto:[email protected]> > >>>>>>>>>> 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 >>>> >>> >> >
