[JBoss JIRA] (LOGMGR-52) Add option to WriterHandler to collapse repeated messages
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-52?page=com.atlassian.jira.plugin.... ]
David Lloyd updated LOGMGR-52:
------------------------------
Fix Version/s: 1.4.0.Beta3
(was: 1.4.0.Beta2)
> Add option to WriterHandler to collapse repeated messages
> ---------------------------------------------------------
>
> Key: LOGMGR-52
> URL: https://issues.jboss.org/browse/LOGMGR-52
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.4.0.Beta3
>
>
> The WriterHandler could have a time interval configured wherein a repeated message would be collapsed.
> The last message would be stored in a field for comparison along with a nanoTime tag (the timestamp on the message is not adequate because the clock can have skew or be reset completely at any time). If the current message string equals the last message string, and collapsing is enabled, then instead of logging the message, a count is incremented. If the current message is not equal, then the stored message is logged with a tag indicating the number of repeats (i18n?) and then the next submitted message is logged.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (LOGMGR-30) Support automatic log file compression in FileHandler (for compressing all files in real time) and PeriodicRotatingFileHandler (for compressing upon rotation)
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-30?page=com.atlassian.jira.plugin.... ]
David Lloyd updated LOGMGR-30:
------------------------------
Fix Version/s: 1.4.0.Beta3
(was: 1.4.0.Beta2)
> Support automatic log file compression in FileHandler (for compressing all files in real time) and PeriodicRotatingFileHandler (for compressing upon rotation)
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LOGMGR-30
> URL: https://issues.jboss.org/browse/LOGMGR-30
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Aleksander Adamowski
> Assignee: David Lloyd
> Fix For: 1.4.0.Beta3
>
>
> This is a follow up to JBAS-6917.
> It would be nice to have an automatic compression of log files similar to the one implemented in Log4j extras:
> http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4...
> "TimeBasedRollingPolicy supports automatic file compression. This feature is enabled if the value of the FileNamePattern option ends with .gz or .zip."
> In JBoss Logging, I suppose this could be implemented on 2 levels:
> 1) In the FileHandler (http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk/src/main/jav...) so that, with proper configuration, each log file is compressed in real time, and it exists only in compressed form from the moment of its creation.
> 2) In the PeriodicRotatingFileHandler (http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk/src/main/jav...) so that with proper configuration, archival log files can be compressed the moment they are rotated (e.g. server.log.2010-05-06.gz is created instead of server.log.2010-05-06), but the current log file should be plain text.
> In PeriodicRotatingFileHandler, the implementation must take into account that compression of rotated log files may take considerable time and should be performed in the background - the handler should be able to process log records at any time, particularly during rotation, without losing any.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (LOGMGR-52) Add option to WriterHandler to collapse repeated messages
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-52?page=com.atlassian.jira.plugin.... ]
David Lloyd updated LOGMGR-52:
------------------------------
Fix Version/s: 1.4.0.Beta2
(was: 1.4.0.Beta1)
> Add option to WriterHandler to collapse repeated messages
> ---------------------------------------------------------
>
> Key: LOGMGR-52
> URL: https://issues.jboss.org/browse/LOGMGR-52
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.4.0.Beta2
>
>
> The WriterHandler could have a time interval configured wherein a repeated message would be collapsed.
> The last message would be stored in a field for comparison along with a nanoTime tag (the timestamp on the message is not adequate because the clock can have skew or be reset completely at any time). If the current message string equals the last message string, and collapsing is enabled, then instead of logging the message, a count is incremented. If the current message is not equal, then the stored message is logged with a tag indicating the number of repeats (i18n?) and then the next submitted message is logged.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (LOGMGR-30) Support automatic log file compression in FileHandler (for compressing all files in real time) and PeriodicRotatingFileHandler (for compressing upon rotation)
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-30?page=com.atlassian.jira.plugin.... ]
David Lloyd updated LOGMGR-30:
------------------------------
Fix Version/s: 1.4.0.Beta2
(was: 1.4.0.Beta1)
> Support automatic log file compression in FileHandler (for compressing all files in real time) and PeriodicRotatingFileHandler (for compressing upon rotation)
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LOGMGR-30
> URL: https://issues.jboss.org/browse/LOGMGR-30
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Aleksander Adamowski
> Assignee: David Lloyd
> Fix For: 1.4.0.Beta2
>
>
> This is a follow up to JBAS-6917.
> It would be nice to have an automatic compression of log files similar to the one implemented in Log4j extras:
> http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4...
> "TimeBasedRollingPolicy supports automatic file compression. This feature is enabled if the value of the FileNamePattern option ends with .gz or .zip."
> In JBoss Logging, I suppose this could be implemented on 2 levels:
> 1) In the FileHandler (http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk/src/main/jav...) so that, with proper configuration, each log file is compressed in real time, and it exists only in compressed form from the moment of its creation.
> 2) In the PeriodicRotatingFileHandler (http://anonsvn.jboss.org/repos/common/jboss-logmanager/trunk/src/main/jav...) so that with proper configuration, archival log files can be compressed the moment they are rotated (e.g. server.log.2010-05-06.gz is created instead of server.log.2010-05-06), but the current log file should be plain text.
> In PeriodicRotatingFileHandler, the implementation must take into account that compression of rotated log files may take considerable time and should be performed in the background - the handler should be able to process log records at any time, particularly during rotation, without losing any.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-5897) Allow user applications to introduce server side non-EE interceptors for EE invocations
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/AS7-5897?page=com.atlassian.jira.plugin.s... ]
jaikiran pai commented on AS7-5897:
-----------------------------------
Here the documentation for this feature https://docs.jboss.org/author/display/AS72/Container+interceptors
> Allow user applications to introduce server side non-EE interceptors for EE invocations
> ---------------------------------------------------------------------------------------
>
> Key: AS7-5897
> URL: https://issues.jboss.org/browse/AS7-5897
> Project: Application Server 7
> Issue Type: Feature Request
> Components: EE, EJB
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: jaikiran pai
> Assignee: jaikiran pai
> Fix For: 7.2.0.Alpha1
>
>
> One of the topics that we discussed in the AS meeting was the use case where users have been demanding for a way to run their application specific interceptors before some of the server side app server specific interceptors and user application specific EE interceptors are run. This will allow for the user applications to have a way to pass in additional information (like security related info) to the server side interceptors (like the security interceptor) so that the information can then be made use for deciding whether or not the call should be allowed to happen or not. We used to allow to do this in previous versions of a AS via AOP but there's no current way to do it in AS7. The EE interceptors come into picture too late.
> Some approaches have been discussed around this, during the meeting, with the goal that whatever approach we introduce should be something that we should be able to "support" for a long time without having to ask the users to migrate to a newer way of doing this, in every other major release:
> 1) Allow the interceptors to use jboss-invocation library to use the interceptor API and implement their interceptors. The advantage of this approach as compared with the other approaches below, is that the semantics of this interceptor interface is something that "we" can decide and wouldn't matter if it conflicts with the semantics of the EE specific interceptors (for ex: EE specific interceptors have a invocationCtx.getTarget() which won't make sense for server side interceptors which are being invoked *before* the application component has been created)
> 2) Allow the user applications to just use the EE interceptor API for these intereceptors and we explicitly state that certain APIs like invocationCtx.getTarget() will have different semantics when run as a "system interceptor"
> 3) Introduce a very small/tiny API (EarlyEEInvocationContext as David calls it :)) which exposes limited semantics that the interceptors can rely on.
> We are leaning more towards #2 since that wouldn't need any new library or API for these interceptors, but would only require an explicit documentation of what's allowed and what's not in such interceptors.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months