You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Ralph Goers (JIRA)" <ji...@apache.org> on 2008/06/23 00:39:45 UTC
[jira] Created: (LOG4J2-17) Provide enhanced logger filtering
support.
Provide enhanced logger filtering support.
------------------------------------------
Key: LOG4J2-17
URL: https://issues.apache.org/jira/browse/LOG4J2-17
Project: Log4j 2
Issue Type: New Feature
Components: Core
Reporter: Ralph Goers
We wrote our own logging framework primarily because log4j didn't provide some of the features we needed. Our software runs on behalf of many companies, products and users all in the same JVM. We have a requirement to be able to enable logging based on some of these factors. For example, we might want to enable debug logging only for a specific company or even a specific user. All our requests store attributes, such as the companyId, product name and userid in the MDC.
So the real requirement here is to be able to filter log records early based on more information than just the log level. For example, our requirement could be met by a filter that could be configured to associate a log level with a company id. Then when debug is called a check would first be done to see if debug was enabled for that company id and then whether debug was enabled for that logger. These checks cannot be done as filters on Appenders as the performance of the system is dramatically impacted as isDebugLogging really needs to return false for all company ids other than the one that is enabled.
This feature is similar to LogBack's TurboFilter, except I would like it implemented differently. I would recommend that the filter be specified globally but referenced on each logger to which it applies, much as the specification of Appenders is done.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-17) Provide enhanced logger filtering
support.
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875100#action_12875100 ]
Ralph Goers commented on LOG4J2-17:
-----------------------------------
I should have added that, like Logback's TurboFilters, the filters need to be at a global level, on the logger, or both. Filters on Appenders would require too much configuration, would be fragile and would not perform well at all. Events that don't match the filtering criteria must be rejected asap.
> Provide enhanced logger filtering support.
> ------------------------------------------
>
> Key: LOG4J2-17
> URL: https://issues.apache.org/jira/browse/LOG4J2-17
> Project: Log4j 2
> Issue Type: New Feature
> Components: Core
> Reporter: Ralph Goers
>
> We wrote our own logging framework primarily because log4j didn't provide some of the features we needed. Our software runs on behalf of many companies, products and users all in the same JVM. We have a requirement to be able to enable logging based on some of these factors. For example, we might want to enable debug logging only for a specific company or even a specific user. All our requests store attributes, such as the companyId, product name and userid in the MDC.
> So the real requirement here is to be able to filter log records early based on more information than just the log level. For example, our requirement could be met by a filter that could be configured to associate a log level with a company id. Then when debug is called a check would first be done to see if debug was enabled for that company id and then whether debug was enabled for that logger. These checks cannot be done as filters on Appenders as the performance of the system is dramatically impacted as isDebugLogging really needs to return false for all company ids other than the one that is enabled.
> This feature is similar to LogBack's TurboFilter, except I would like it implemented differently. I would recommend that the filter be specified globally but referenced on each logger to which it applies, much as the specification of Appenders is done.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-17) Provide enhanced logger filtering
support.
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867814#action_12867814 ]
Ralph Goers commented on LOG4J2-17:
-----------------------------------
In my experimental branch I have enhanced Filters so that they can be configured globally as well as on a logger in addition to on an appender. The branch contains a couple of example filters.
> Provide enhanced logger filtering support.
> ------------------------------------------
>
> Key: LOG4J2-17
> URL: https://issues.apache.org/jira/browse/LOG4J2-17
> Project: Log4j 2
> Issue Type: New Feature
> Components: Core
> Reporter: Ralph Goers
>
> We wrote our own logging framework primarily because log4j didn't provide some of the features we needed. Our software runs on behalf of many companies, products and users all in the same JVM. We have a requirement to be able to enable logging based on some of these factors. For example, we might want to enable debug logging only for a specific company or even a specific user. All our requests store attributes, such as the companyId, product name and userid in the MDC.
> So the real requirement here is to be able to filter log records early based on more information than just the log level. For example, our requirement could be met by a filter that could be configured to associate a log level with a company id. Then when debug is called a check would first be done to see if debug was enabled for that company id and then whether debug was enabled for that logger. These checks cannot be done as filters on Appenders as the performance of the system is dramatically impacted as isDebugLogging really needs to return false for all company ids other than the one that is enabled.
> This feature is similar to LogBack's TurboFilter, except I would like it implemented differently. I would recommend that the filter be specified globally but referenced on each logger to which it applies, much as the specification of Appenders is done.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-17) Provide enhanced logger filtering
support.
Posted by "Scott Deboy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4J2-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607136#action_12607136 ]
Scott Deboy commented on LOG4J2-17:
-----------------------------------
It sounds like ExpressionFilter logic could be repurposed to support this capability.
> Provide enhanced logger filtering support.
> ------------------------------------------
>
> Key: LOG4J2-17
> URL: https://issues.apache.org/jira/browse/LOG4J2-17
> Project: Log4j 2
> Issue Type: New Feature
> Components: Core
> Reporter: Ralph Goers
>
> We wrote our own logging framework primarily because log4j didn't provide some of the features we needed. Our software runs on behalf of many companies, products and users all in the same JVM. We have a requirement to be able to enable logging based on some of these factors. For example, we might want to enable debug logging only for a specific company or even a specific user. All our requests store attributes, such as the companyId, product name and userid in the MDC.
> So the real requirement here is to be able to filter log records early based on more information than just the log level. For example, our requirement could be met by a filter that could be configured to associate a log level with a company id. Then when debug is called a check would first be done to see if debug was enabled for that company id and then whether debug was enabled for that logger. These checks cannot be done as filters on Appenders as the performance of the system is dramatically impacted as isDebugLogging really needs to return false for all company ids other than the one that is enabled.
> This feature is similar to LogBack's TurboFilter, except I would like it implemented differently. I would recommend that the filter be specified globally but referenced on each logger to which it applies, much as the specification of Appenders is done.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org