RFR: JDK-8046565: Platform Logging API and Service (original) (raw)
Mandy Chung mandy.chung at oracle.com
Tue Oct 13 02:50:03 UTC 2015
- Previous message: RFR: JDK-8046565: Platform Logging API and Service
- Next message: RFR: JDK-8046565: Platform Logging API and Service
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Daniel,
On Oct 9, 2015, at 12:53 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
JEP: http://openjdk.java.net/jeps/264 https://bugs.openjdk.java.net/browse/JDK-8046565 specdiff: http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html webrev: http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/webrev.01/
This is very good work. I’m glad to see this work that enables the dependency on java.logging be eliminated. The sun.util.logging.PlatformLogger was a stop-gap approach.
There are many new tests that I will need time to review them all. I’m going to pass you my comments in several batches. This is the first batch.
LogManager.java 1938 if (caller.getClassLoader() == null) { 1939 return LogManager.getLogManager().demandSystemLogger(name, 1940 Logger.SYSTEM_LOGGER_RB_NAME, caller);
This only considers the classes loaded by the boot loader as system classes. We have deprivileged several modules to be loaded by the ext class loader such as JAX-WS, JAXB, CORBA etc. Loggers created by modules loaded by boot and ext class loader should be system.
In the absence of java.logging, the default provider implementation will be used to print the log messages to System.err. This is useful since most JDK log messages are for debugging. I expect that a component may want to turn on debug messages without requiring the presence of java.logging.
Is there any mechanism to change the default level of the default simple console loggers? It may be useful; otherwise it would need to run on an image with java.logging module. Maybe something to add in the future.
System.Logger 964 * Unless
- incomplete sentence?
1697 * @implSpec 1698 * Instances returned by this method route messages to loggers 1699 * obtained by calling {@link LoggerFinder#getLogger(java.lang.String, java.lang.Class) 1700 * LoggerFinder.getLogger(name, ca
Is this intended to be implementation specification but not API spec?
RuntimePermission(“LoggerFinder) is required in the provider constructor.
- is it time to define a ServiceProviderPermission for provider constructor security permission check? Rather than overloading RuntimePermission
public static final RuntimePermission LOGGERFINDER_PERMISSION = new RuntimePermission("loggerFinder”);
- is there any need to define this constant? Suggest this be implementation-details.
private LoggerFinderLoader() { throw new InternalError("LoggerFinderLoader cannot be instantiated"); }
- is throwing InternalError necessary? No one else except its enclosing class can construct it.
JdkLoggingProvider::LOGGING_CONTROL_PERMISSION
- I think this field is unused.
sun/management/ManagementFactoryHelper.java
Is LoggingMXBeanSupport intended to get java.management to remove its dependency on java.logging?
172 public interface LoggingMXBean 173 extends PlatformLoggingMXBean, java.util.logging.LoggingMXBean { 174 }
This static dependency will still keep the dependency on java.logging.
Mandy
- Previous message: RFR: JDK-8046565: Platform Logging API and Service
- Next message: RFR: JDK-8046565: Platform Logging API and Service
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]