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
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 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>
À: "Alex Sviridov"<ooo_satu...@mail.ru>
Cc: "Remi Forax"<fo...@univ-mlv.fr>, "jigsaw-dev"<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> 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>:
You can use the StackWalker
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 >
À: "jigsaw-dev" <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
