Separate logging for JPMS module/layer

[Mandy Chung]

On 10/4/18 3:08 PM, Luke Hutchison wrote:
> If you need to read the stack in a manner that is backwards compatible 
> with JDK 8 or earlier, there's also the following mechanism for 
> getting the call stack, by creating a SecurityManager:
>
> https://github.com/classgraph/classgraph/blob/master/src/main/java/io/github/classgraph/utils/CallStackReader.java
>
> However, is there a reason to believe the above mechanism might stop 
> working in the future?
>
> Under what conditions might SecurityManager not allow 
> RuntimePermission("createSecurityManager") , and how common is this 
> likely to be?
>

It depends on whether the security manager is created with a 
doPrivileged and whether the permission is granted to the code source 
creating the security manager.

> Will there be situations where StackWalker will succeed in reading the 
> call stack but SecurityManager will fail, or vice versa?
>

SecurityManager::getClassContext is designed for the security permission 
check.  It's not for stack walking.

The stackwalker returns the frames it traverses and if not filtered.   
SM::getClassContext is for permission check and it may filter 
unnecessary frames as it wishes (for example native frames as I see).

Mandy

>
>
> On Thu, Oct 4, 2018 at 3:51 PM Mandy Chung <mandy.chung at oracle.com 
> <mailto:mandy.chung at 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, forax at univ-mlv.fr
>     <mailto:forax at 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.goers at dslextreme.com
>     <mailto:ralph.goers at dslextreme.com>>
>     >>> À: "Alex Sviridov" <ooo_saturn7 at mail.ru
>     <mailto:ooo_saturn7 at mail.ru>>
>     >>> Cc: "Remi Forax" <forax at univ-mlv.fr
>     <mailto:forax at univ-mlv.fr>>, "jigsaw-dev"
>     <jigsaw-dev at openjdk.java.net <mailto:jigsaw-dev at 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_saturn7 at mail.ru <mailto:ooo_saturn7 at 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
>     <forax at univ-mlv.fr <mailto:forax at 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_saturn7 at mail.ru
>     <mailto:ooo_saturn7 at mail.ru> >
>     >>>>>> À: "jigsaw-dev" < jigsaw-dev at openjdk.java.net
>     <mailto:jigsaw-dev at 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
>     >
>