Repository navigation
feat: Enable access to LogRecord in LoggingEnhancer (e.g., for access to flogger LogSite) #747
Description
Activity
- changed the title
[-]Enable access to LogRecord in LoggingEnhancer (e.g., for access to flogger LogSite)[/-][+]feat: Enable access to LogRecord in LoggingEnhancer (e.g., for access to flogger LogSite)[/+]on Nov 14, 2021 Hi, the information from the LogRecord is translated to LogEntry:
If there is any information that is not captured, a user can develop an enhancer and register it to enhance resulted LogEntry instance. It will help us to understand better your request if you can provide an example of the data that you are trying to log with JUL and what data you eventually expect to see in Log Explorer.
Right the problem is that the enhancer doesn't get any access to the LogRecord.
Here's specifically what I'm after: the flogger library subclasses
LogRecord. I want to to implement an Enhancer which downcasts theLogRecordto get to theAbstractLogRecord, so I can callgetLogData(), because there's a bunch of information there that isn't in the baseLogRecord. Unfortunately, the Enhancer interface has no access to the originalLogRecord, so this is not possible.Do you effectively try customize the current logic of translating
LogRecordtoLogEntrythatLoggingHandlerclass implements?Yeah you could definitely put it that way.
Since this logic requires a dependency on the Google flogger library, I would suspect you don't want to do exactly that translation in this library, but the
LogEnhancerinterface is almost ideal for enabling the caller to add it. Almost.We do not plan to introduce this level of customization at the moment.
Would you consider to inherit fromcom.google.cloud.logging.LoggingHandlerand just override the currentpublish()implementation?Sure! But I think we'd need to make
logEntryForprotected (it's currently private) and/or refactor it out into its own reusable class.We will look into refactoring the current implementation to support inheritance 👍
Oh, yeah, I didn't see that one! Looks like what we'd do with it, to slightly modify dansiviter@'s example, is:
public interface LoggingEventEnhancer extends com.google.cloud.logging.LoggingEventEnhancer<java.util.logging.LogRecord> { ... }I will close this issue then. We will work to implement #32. However, the change like that is a breaking change. It cannot be implemented without either creating a parallel flow for logs enhancing or by breaking the existing API. It means this change can be introduced only within the next major release.
Is your feature request related to a problem? Please describe.
The
LoggingEnhancerinterface enables an implementer to add extra content to aLogEntry. However, theLoggingEnhanceris not itself given any context about the underlyingLogRecord, so any added content must essentially be static and unrelated to the specific log record.Some logging systems, like flogger, subclass
java.util.logging.LogRecord(e.g., flogger makes acom.google.common.flogger.backend.system.AbstractLogRecord) and add extra information (e.g., in the case of flogger, theAbstractLogRecordhasgetLogData().getLogSite()which offers a much more efficient and less hassle-free mechanism of retrieving log site information thancom.google.cloud.logging.SourceLocation.fromCurrentContext).Describe the solution you'd like
Can we add a
LogRecordparameter toLoggingEnhancer.enhanceLogEntry? This would be a breaking change; if it's too late for such a change, maybe we need aLoggingEnhancerWithRecordorLoggingEnhancer2.Then as a follow-on, some library can supply the glue for flogger and this library: a stock
LoggingEnhancerto supply theLogSite.Describe alternatives you've considered
We currently have a logging handler which downcasts the
LogRecord, but it has its ownjava.util.logging.LogHandlerimplementation and thus doesn't useLoggingHandleror thejava-logginglibrary. I'm filing this feature request in hopes of replacing that internal implementation.Additional context
Contact me for the internal example of downcasting
LogRecord. :)