[jira] [Commented] (LOG4J2-2436) log4j-audit-maven-plugin should allow executions and binding to generate-test-sources phase
[
https://issues.apache.org/jira/browse/LOG4J2-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625352#comment-16625352
]
Remko Popma commented on LOG4J2-2436:
-
If users can easily do the wrong thing then there may be room for improvement
in the application.
For example abort with a clear error message that the specified configuration
is wrong because of and user should try instead.
> log4j-audit-maven-plugin should allow executions and binding to
> generate-test-sources phase
> ---
>
> Key: LOG4J2-2436
> URL: https://issues.apache.org/jira/browse/LOG4J2-2436
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Assignee: Ralph Goers
>Priority: Major
>
> I have a module that packages various +audit+ related classes and I want to
> make some tests for them and I thought of defining a test catalog in
> _src/test/resources_ and the tests would use the generated audit event
> classes.
> The problem is that the generated audit classes always end up in
> _target/classes_ and in the packaged jar.
> I've tried to define a separate execution, similar to this
> [example|https://stackoverflow.com/questions/8587353/maven-how-to-handle-generated-sources-for-testonly],
> but it doesn't help.
> The _log4j-audit-maven-plugin_ doesn't see the configuration if it's defined
> inside an _execution_ section and it always invokes
> {{project.addCompileSourceRoot}}, no matter which phase.
> {code:xml}
>
> org.apache.logging.log4j
> log4j-audit-maven-plugin
>
>
> generate-test-sources
> generate-test-sources
>
>
>
>
> test
>
> ${project.build.directory}/generated-test-sources/log4j-audit
>
> src/test/resources/audit-catalog.json
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (LOG4J2-2448) Allow usage of Versions in non-Spring environments
[
https://issues.apache.org/jira/browse/LOG4J2-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625339#comment-16625339
]
Ralph Goers edited comment on LOG4J2-2448 at 9/24/18 2:51 AM:
--
If you had to reimplement AuditController then the Versions class shouldn't be
much of a problem. Versions is used to declare the media type of the data to be
produced (i.e. - the value of the ACCEPT header). We are doing API versioning
using the media type. You simply need to emulate that in whatever way is
compatible with JAX-RS.
If you can come up with an alternate way to get the Spring MediaType or the
JAX-RS MediaType depending on which is being used I'd be open to hearing about
it.
was (Author: ralph.go...@dslextreme.com):
If you had to reimplement AuditController then the Versions class shouldn't be
much of a problem. Versions is used to declare the media type of the data to be
produced (i.e. - the value of the ACCEPT header). We are doing API versioning
using the media type. You simply need to emulate that in whatever way is
compatible with JAX-RS.
> Allow usage of Versions in non-Spring environments
> --
>
> Key: LOG4J2-2448
> URL: https://issues.apache.org/jira/browse/LOG4J2-2448
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
>
> As my application uses just JAX-RS, without Spring, I had to re-implement
> {{AuditController}} using plain JAX-RS.
> The problem is that {{Versions}} uses a Spring class, as seen [here|
> https://github.com/apache/logging-log4j-audit/blob/master/log4j-catalog/log4j-catalog-api/src/main/java/org/apache/logging/log4j/catalog/api/Versions.java#L34].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2448) Allow usage of Versions in non-Spring environments
[
https://issues.apache.org/jira/browse/LOG4J2-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625339#comment-16625339
]
Ralph Goers commented on LOG4J2-2448:
-
If you had to reimplement AuditController then the Versions class shouldn't be
much of a problem. Versions is used to declare the media type of the data to be
produced (i.e. - the value of the ACCEPT header). We are doing API versioning
using the media type. You simply need to emulate that in whatever way is
compatible with JAX-RS.
> Allow usage of Versions in non-Spring environments
> --
>
> Key: LOG4J2-2448
> URL: https://issues.apache.org/jira/browse/LOG4J2-2448
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
>
> As my application uses just JAX-RS, without Spring, I had to re-implement
> {{AuditController}} using plain JAX-RS.
> The problem is that {{Versions}} uses a Spring class, as seen [here|
> https://github.com/apache/logging-log4j-audit/blob/master/log4j-catalog/log4j-catalog-api/src/main/java/org/apache/logging/log4j/catalog/api/Versions.java#L34].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (LOG4J2-2436) log4j-audit-maven-plugin should allow executions and binding to generate-test-sources phase
[
https://issues.apache.org/jira/browse/LOG4J2-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-2436.
-
Resolution: Invalid
Marking this as invalid since it appears you tried using a configuration mixed
with an execution. Instead you need 2 executions.
> log4j-audit-maven-plugin should allow executions and binding to
> generate-test-sources phase
> ---
>
> Key: LOG4J2-2436
> URL: https://issues.apache.org/jira/browse/LOG4J2-2436
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Assignee: Ralph Goers
>Priority: Major
>
> I have a module that packages various +audit+ related classes and I want to
> make some tests for them and I thought of defining a test catalog in
> _src/test/resources_ and the tests would use the generated audit event
> classes.
> The problem is that the generated audit classes always end up in
> _target/classes_ and in the packaged jar.
> I've tried to define a separate execution, similar to this
> [example|https://stackoverflow.com/questions/8587353/maven-how-to-handle-generated-sources-for-testonly],
> but it doesn't help.
> The _log4j-audit-maven-plugin_ doesn't see the configuration if it's defined
> inside an _execution_ section and it always invokes
> {{project.addCompileSourceRoot}}, no matter which phase.
> {code:xml}
>
> org.apache.logging.log4j
> log4j-audit-maven-plugin
>
>
> generate-test-sources
> generate-test-sources
>
>
>
>
> test
>
> ${project.build.directory}/generated-test-sources/log4j-audit
>
> src/test/resources/audit-catalog.json
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2436) log4j-audit-maven-plugin should allow executions and binding to generate-test-sources phase
[
https://issues.apache.org/jira/browse/LOG4J2-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625336#comment-16625336
]
Ralph Goers commented on LOG4J2-2436:
-
After a bit of research I don't think there is anything to do here. I tested
this with the sample project the configuration below and it generated the
source to the correct location, although it generated the same classes since I
didn't provide an alternate catalog.
{code}
org.apache.logging.log4j
log4j-audit-maven-plugin
${log4j-audit.version}
generate
generate-sources
generate
org.apache.logging.log4j.audit.event
18060
generate-tests
generate-test-sources
generate
org.apache.logging.log4j.audit.event
18060
${project.build.directory}/generated-test-sources/log4j-audit
{code}
> log4j-audit-maven-plugin should allow executions and binding to
> generate-test-sources phase
> ---
>
> Key: LOG4J2-2436
> URL: https://issues.apache.org/jira/browse/LOG4J2-2436
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Assignee: Ralph Goers
>Priority: Major
>
> I have a module that packages various +audit+ related classes and I want to
> make some tests for them and I thought of defining a test catalog in
> _src/test/resources_ and the tests would use the generated audit event
> classes.
> The problem is that the generated audit classes always end up in
> _target/classes_ and in the packaged jar.
> I've tried to define a separate execution, similar to this
> [example|https://stackoverflow.com/questions/8587353/maven-how-to-handle-generated-sources-for-testonly],
> but it doesn't help.
> The _log4j-audit-maven-plugin_ doesn't see the configuration if it's defined
> inside an _execution_ section and it always invokes
> {{project.addCompileSourceRoot}}, no matter which phase.
> {code:xml}
>
> org.apache.logging.log4j
> log4j-audit-maven-plugin
>
>
> generate-test-sources
> generate-test-sources
>
>
>
>
> test
>
> ${project.build.directory}/generated-test-sources/log4j-audit
>
> src/test/resources/audit-catalog.json
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-1013) Log4j2 Main Arguments Lookup by name doesn't work
[
https://issues.apache.org/jira/browse/LOG4J2-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625273#comment-16625273
]
ASF GitHub Bot commented on LOG4J2-1013:
Github user fdiazgon commented on the issue:
https://github.com/apache/logging-log4j2/pull/159
Hey @garydgregory @remkop. Could anyone check the status of this PR? It
seems that Travis failed with an error not related to this code.
> Log4j2 Main Arguments Lookup by name doesn't work
> -
>
> Key: LOG4J2-1013
> URL: https://issues.apache.org/jira/browse/LOG4J2-1013
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core, Lookups
>Affects Versions: 2.2
> Environment: Windows 7 x64 Ultimate and Java 8U31 x64. Project
> created using Eclipse.
>Reporter: Ioan Mihaila
>Priority: Critical
> Attachments:
> LOG4J2_1013_select_underlying_StrLookup_before_stripping_off_potential_default_values.patch
>
>
> Accessing Main Arguments by using index based look up works : $\{main:0}
> Accessing Main Arguments by using name based look up doesn't work :
> $\{main:--file}
> When trying to access by name it doesn't retrieve the argument but retrieves
> "-file".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] logging-log4j2 issue #159: [LOG4J2-1013][Lookups] Allow variables with dashe...
Github user fdiazgon commented on the issue: https://github.com/apache/logging-log4j2/pull/159 Hey @garydgregory @remkop. Could anyone check the status of this PR? It seems that Travis failed with an error not related to this code. ---
[jira] [Closed] (LOG4NET-612) RollingFileAppender can't log to the same file from processes running under different accounts
[ https://issues.apache.org/jira/browse/LOG4NET-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin.Z closed LOG4NET-612. Resolution: Not A Problem > RollingFileAppender can't log to the same file from processes running under > different accounts > -- > > Key: LOG4NET-612 > URL: https://issues.apache.org/jira/browse/LOG4NET-612 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 2.0.8 > Environment: Tested on Windows 10 and Windows 2016 using .NET > Framework 4.6.1. >Reporter: Martin.Z >Priority: Major > Labels: RollingFileAppender > > RollingFileAppender uses a Mutex to try to prevent multiple processes from > rolling the same file. However, I think there is an issue with the > implementation. > The Mutex is created with default security. This means that if two processes > running under different accounts are configured to log to the same file, one > of them will get an UnauthorizedAccessException (caught by log4net) from the > Mutex constructor, as the default Mutex security doesn't allow other (non > administrator) users to use the Mutex. As a result, one of the processes will > be completely unable to log. > The problem can be reproduced by creating two services running under > different accounts and configured to log to the same file using > RollingFileAppender. If diagnostic logging is enabled, an > UnauthorizedAccessException with a stack trace will be logged. If the Mutex > were to be created with an access rule that allows everyone to use it, then > the exception should disappear. The downside is that others on the system > would be able to interfere by grabbing the Mutex, but that is partly possible > today if someone creates the Mutex before log4net. Note that trying to > reproduce the issue by starting a console application with different accounts > might fail, as the applications would share a logon session and be able to > use each other's Mutexes. Services run in separate sessions. > There might also be another, lesser issue. The Mutex is created with a name > that isn't explicitly in the global namespace. Services use the global > namespace by default, but client (user) applications default to an isolated > session namespace. This might be by design, but it means that a service and a > client application might try to roll the same file simultaneously. > Exception if a process running under a different account has created the > Mutex: > log4net:ERROR Could not create Appender [file] of type > [log4net.Appender.RollingFileAppender]. Reported error follows. > System.UnauthorizedAccessException: Access to the path > 'D__temp_Log4netMutexTest_Log' is denied. > at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) > at System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData) > at > System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode > code, CleanupCode backoutCode, Object userData) > at System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean > initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES > secAttrs) > at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name, > Boolean& createdNew, MutexSecurity mutexSecurity) > at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name) > at log4net.Appender.RollingFileAppender.ActivateOptions() > at > log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement > appenderElement) > Creating a Mutex with an access rule: > var sid = new SecurityIdentifier(WellKnownSidType.WorldSid, null); > var mutexSec = new MutexSecurity(); > var mutexRule = new MutexAccessRule(sid, MutexRights.FullControl, > AccessControlType.Allow); > mutexSec.AddAccessRule(mutexRule); > var mutex = new Mutex(false, "Log4netMutexServiceTest", out _, mutexSec); > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4NET-612) RollingFileAppender can't log to the same file from processes running under different accounts
[ https://issues.apache.org/jira/browse/LOG4NET-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625272#comment-16625272 ] Martin.Z commented on LOG4NET-612: -- Thanks for the reply, I'll close the issue. > RollingFileAppender can't log to the same file from processes running under > different accounts > -- > > Key: LOG4NET-612 > URL: https://issues.apache.org/jira/browse/LOG4NET-612 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 2.0.8 > Environment: Tested on Windows 10 and Windows 2016 using .NET > Framework 4.6.1. >Reporter: Martin.Z >Priority: Major > Labels: RollingFileAppender > > RollingFileAppender uses a Mutex to try to prevent multiple processes from > rolling the same file. However, I think there is an issue with the > implementation. > The Mutex is created with default security. This means that if two processes > running under different accounts are configured to log to the same file, one > of them will get an UnauthorizedAccessException (caught by log4net) from the > Mutex constructor, as the default Mutex security doesn't allow other (non > administrator) users to use the Mutex. As a result, one of the processes will > be completely unable to log. > The problem can be reproduced by creating two services running under > different accounts and configured to log to the same file using > RollingFileAppender. If diagnostic logging is enabled, an > UnauthorizedAccessException with a stack trace will be logged. If the Mutex > were to be created with an access rule that allows everyone to use it, then > the exception should disappear. The downside is that others on the system > would be able to interfere by grabbing the Mutex, but that is partly possible > today if someone creates the Mutex before log4net. Note that trying to > reproduce the issue by starting a console application with different accounts > might fail, as the applications would share a logon session and be able to > use each other's Mutexes. Services run in separate sessions. > There might also be another, lesser issue. The Mutex is created with a name > that isn't explicitly in the global namespace. Services use the global > namespace by default, but client (user) applications default to an isolated > session namespace. This might be by design, but it means that a service and a > client application might try to roll the same file simultaneously. > Exception if a process running under a different account has created the > Mutex: > log4net:ERROR Could not create Appender [file] of type > [log4net.Appender.RollingFileAppender]. Reported error follows. > System.UnauthorizedAccessException: Access to the path > 'D__temp_Log4netMutexTest_Log' is denied. > at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) > at System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData) > at > System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode > code, CleanupCode backoutCode, Object userData) > at System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean > initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES > secAttrs) > at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name, > Boolean& createdNew, MutexSecurity mutexSecurity) > at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name) > at log4net.Appender.RollingFileAppender.ActivateOptions() > at > log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement > appenderElement) > Creating a Mutex with an access rule: > var sid = new SecurityIdentifier(WellKnownSidType.WorldSid, null); > var mutexSec = new MutexSecurity(); > var mutexRule = new MutexAccessRule(sid, MutexRights.FullControl, > AccessControlType.Allow); > mutexSec.AddAccessRule(mutexRule); > var mutex = new Mutex(false, "Log4netMutexServiceTest", out _, mutexSec); > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4NET-611) Failed to create netstandard version of logger
[
https://issues.apache.org/jira/browse/LOG4NET-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625218#comment-16625218
]
Dominik Psenner commented on LOG4NET-611:
-
Would you like to pick up this issue and fix it? I wont find the time to do it
soon.
> Failed to create netstandard version of logger
> --
>
> Key: LOG4NET-611
> URL: https://issues.apache.org/jira/browse/LOG4NET-611
> Project: Log4net
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.8
> Environment: Windows Server 2010 R2
>Reporter: Andrei Stryia
>Priority: Critical
>
> I'm using netstandard version of the logger which is constantly fails wit
> error:
> {code:java}
> System.MethodAccessException: Attempt by security transparent method
> 'log4net.Appender.RollingFileAppender.ActivateOptions()' to access security
> critical method 'System.Threading.Mutex..ctor(Boolean, System.String)' failed.
> Assembly 'log4net, Version=2.0.8.0, Culture=neutral,
> PublicKeyToken=669e0ddf0bb1aa2a' is marked with the
> AllowPartiallyTrustedCallersAttribute, and uses the level 2 security
> transparency model. Level 2 transparency causes all methods in
> AllowPartiallyTrustedCallers assemblies to become security transparent by
> default, which may be the cause of this exception.
> at log4net.Appender.RollingFileAppender.ActivateOptions()
> at Log.CreateTimestampedFileAppender(LoggingSettings settings)
> at Log.InitForComponent(String componentName, LoggingSettings settings)
> ...
> {code}
> My logger assembly is a netstandard asembly which is using by .net framework
> console app.
> Error disappears, when I'm replacing log4net netstandard1.3 version by
> net45-full
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4NET-611) Failed to create netstandard version of logger
[
https://issues.apache.org/jira/browse/LOG4NET-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625217#comment-16625217
]
Dominik Psenner commented on LOG4NET-611:
-
This is unfortunate. We added the mutex to lock rolling over the same file
across multiple applications. Today I am convinced that people should not
configure their logging in this way and would prefer we had not added the mutex
at all. We do now have to make it at least configurable. This is already
tracked by another issue and therefore I consider this a duplicate of that
issue.
> Failed to create netstandard version of logger
> --
>
> Key: LOG4NET-611
> URL: https://issues.apache.org/jira/browse/LOG4NET-611
> Project: Log4net
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.8
> Environment: Windows Server 2010 R2
>Reporter: Andrei Stryia
>Priority: Critical
>
> I'm using netstandard version of the logger which is constantly fails wit
> error:
> {code:java}
> System.MethodAccessException: Attempt by security transparent method
> 'log4net.Appender.RollingFileAppender.ActivateOptions()' to access security
> critical method 'System.Threading.Mutex..ctor(Boolean, System.String)' failed.
> Assembly 'log4net, Version=2.0.8.0, Culture=neutral,
> PublicKeyToken=669e0ddf0bb1aa2a' is marked with the
> AllowPartiallyTrustedCallersAttribute, and uses the level 2 security
> transparency model. Level 2 transparency causes all methods in
> AllowPartiallyTrustedCallers assemblies to become security transparent by
> default, which may be the cause of this exception.
> at log4net.Appender.RollingFileAppender.ActivateOptions()
> at Log.CreateTimestampedFileAppender(LoggingSettings settings)
> at Log.InitForComponent(String componentName, LoggingSettings settings)
> ...
> {code}
> My logger assembly is a netstandard asembly which is using by .net framework
> console app.
> Error disappears, when I'm replacing log4net netstandard1.3 version by
> net45-full
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4NET-612) RollingFileAppender can't log to the same file from processes running under different accounts
[ https://issues.apache.org/jira/browse/LOG4NET-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625214#comment-16625214 ] Dominik Psenner commented on LOG4NET-612: - People may disagree, but I do not classify this as a bug. Writing to one file from different accounts on the same system is a very bad idea and not what I consider to be a sane application. I am not going to improve this appender to support this kind of configuration. You should fix your configuration to either log to different files or to a remote location. > RollingFileAppender can't log to the same file from processes running under > different accounts > -- > > Key: LOG4NET-612 > URL: https://issues.apache.org/jira/browse/LOG4NET-612 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 2.0.8 > Environment: Tested on Windows 10 and Windows 2016 using .NET > Framework 4.6.1. >Reporter: Martin.Z >Priority: Major > Labels: RollingFileAppender > > RollingFileAppender uses a Mutex to try to prevent multiple processes from > rolling the same file. However, I think there is an issue with the > implementation. > The Mutex is created with default security. This means that if two processes > running under different accounts are configured to log to the same file, one > of them will get an UnauthorizedAccessException (caught by log4net) from the > Mutex constructor, as the default Mutex security doesn't allow other (non > administrator) users to use the Mutex. As a result, one of the processes will > be completely unable to log. > The problem can be reproduced by creating two services running under > different accounts and configured to log to the same file using > RollingFileAppender. If diagnostic logging is enabled, an > UnauthorizedAccessException with a stack trace will be logged. If the Mutex > were to be created with an access rule that allows everyone to use it, then > the exception should disappear. The downside is that others on the system > would be able to interfere by grabbing the Mutex, but that is partly possible > today if someone creates the Mutex before log4net. Note that trying to > reproduce the issue by starting a console application with different accounts > might fail, as the applications would share a logon session and be able to > use each other's Mutexes. Services run in separate sessions. > There might also be another, lesser issue. The Mutex is created with a name > that isn't explicitly in the global namespace. Services use the global > namespace by default, but client (user) applications default to an isolated > session namespace. This might be by design, but it means that a service and a > client application might try to roll the same file simultaneously. > Exception if a process running under a different account has created the > Mutex: > log4net:ERROR Could not create Appender [file] of type > [log4net.Appender.RollingFileAppender]. Reported error follows. > System.UnauthorizedAccessException: Access to the path > 'D__temp_Log4netMutexTest_Log' is denied. > at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) > at System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(Object userData) > at > System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode > code, CleanupCode backoutCode, Object userData) > at System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean > initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES > secAttrs) > at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name, > Boolean& createdNew, MutexSecurity mutexSecurity) > at System.Threading.Mutex..ctor(Boolean initiallyOwned, String name) > at log4net.Appender.RollingFileAppender.ActivateOptions() > at > log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(XmlElement > appenderElement) > Creating a Mutex with an access rule: > var sid = new SecurityIdentifier(WellKnownSidType.WorldSid, null); > var mutexSec = new MutexSecurity(); > var mutexRule = new MutexAccessRule(sid, MutexRights.FullControl, > AccessControlType.Allow); > mutexSec.AddAccessRule(mutexRule); > var mutex = new Mutex(false, "Log4netMutexServiceTest", out _, mutexSec); > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4J2-2440) AuditEvents should provide some basic toString()
[
https://issues.apache.org/jira/browse/LOG4J2-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625209#comment-16625209
]
ASF subversion and git services commented on LOG4J2-2440:
-
Commit f4dee64be09c2614a4da834c67a89276ba4daa7b in logging-log4j-audit's branch
refs/heads/master from [~ralph.go...@dslextreme.com]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=f4dee64 ]
LOG4J2-2440 - AuditEvents should provide some basic toString()
> AuditEvents should provide some basic toString()
>
>
> Key: LOG4J2-2440
> URL: https://issues.apache.org/jira/browse/LOG4J2-2440
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
> Fix For: Log4j-Audit 1.0.1
>
>
> Currently invoking {{toString()}} on an event built by
> {{LogEventFactory.getEvent}} returns {{null}}.
> It would be nice to get something more meaningful than that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2420) RequestContextFilter logging cleanup
[
https://issues.apache.org/jira/browse/LOG4J2-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625208#comment-16625208
]
ASF subversion and git services commented on LOG4J2-2420:
-
Commit cb7bed47e2267c1a130be9df5eedfa3e7ec337e8 in logging-log4j-audit's branch
refs/heads/master from [~aivanov93]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=cb7bed4 ]
[LOG4J2-2420] use same formatting as surrounding lines
> RequestContextFilter logging cleanup
>
>
> Key: LOG4J2-2420
> URL: https://issues.apache.org/jira/browse/LOG4J2-2420
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
> Fix For: Log4j-Audit 1.0.1
>
>
> The {{RequestContextFilter}} logs some details that should be done on
> {{DEBUG}} or {{TRACE}} instead of {{INFO}}.
> {noformat}
> INFO [org.apache.logging.log4j.audit.rest.RequestContextFilter] - Starting
> request {}/productrepository/2594
> INFO [org.apache.logging.log4j.audit.rest.RequestContextFilter] - Request
> /productrepository/2594 completed in 0.139279500 seconds
> {noformat}
> There's even a small bug on the 1st
> [line|https://github.com/apache/logging-log4j-audit/blob/9bab5dad26e67642573cbc8257b6cbcafb23bf3c/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/rest/RequestContextFilter.java#L82]
> where concatenation was used.
> The calculation of the request duration should also be moved in an if block,
> to avoid it if it won't be logged.
> Same for the Maven plugin, I think it should print the name of the generated
> classes only on debug.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2440) AuditEvents should provide some basic toString()
[
https://issues.apache.org/jira/browse/LOG4J2-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625207#comment-16625207
]
ASF subversion and git services commented on LOG4J2-2440:
-
Commit 5e67a33704d0a768b6adb41533e7966489f4072f in logging-log4j-audit's branch
refs/heads/master from [~aivanov93]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=5e67a33 ]
[LOG4J2-2440]
> AuditEvents should provide some basic toString()
>
>
> Key: LOG4J2-2440
> URL: https://issues.apache.org/jira/browse/LOG4J2-2440
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
> Fix For: Log4j-Audit 1.0.1
>
>
> Currently invoking {{toString()}} on an event built by
> {{LogEventFactory.getEvent}} returns {{null}}.
> It would be nice to get something more meaningful than that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2440) AuditEvents should provide some basic toString()
[
https://issues.apache.org/jira/browse/LOG4J2-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625210#comment-16625210
]
ASF GitHub Bot commented on LOG4J2-2440:
Github user asfgit closed the pull request at:
https://github.com/apache/logging-log4j-audit/pull/11
> AuditEvents should provide some basic toString()
>
>
> Key: LOG4J2-2440
> URL: https://issues.apache.org/jira/browse/LOG4J2-2440
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
> Fix For: Log4j-Audit 1.0.1
>
>
> Currently invoking {{toString()}} on an event built by
> {{LogEventFactory.getEvent}} returns {{null}}.
> It would be nice to get something more meaningful than that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (LOG4J2-2440) AuditEvents should provide some basic toString()
[
https://issues.apache.org/jira/browse/LOG4J2-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-2440.
-
Resolution: Fixed
Fix Version/s: Log4j-Audit 1.0.1
Patch applied. Please verify and close.
> AuditEvents should provide some basic toString()
>
>
> Key: LOG4J2-2440
> URL: https://issues.apache.org/jira/browse/LOG4J2-2440
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
> Fix For: Log4j-Audit 1.0.1
>
>
> Currently invoking {{toString()}} on an event built by
> {{LogEventFactory.getEvent}} returns {{null}}.
> It would be nice to get something more meaningful than that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] logging-log4j-audit pull request #11: [LOG4J2-2440]
Github user asfgit closed the pull request at: https://github.com/apache/logging-log4j-audit/pull/11 ---
[jira] [Resolved] (LOG4J2-2429) Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext variable
[
https://issues.apache.org/jira/browse/LOG4J2-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-2429.
-
Resolution: Fixed
Fix Version/s: Log4j-Audit 1.0.1
Patch applied. Please verify and close.
> Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext
> variable
> --
>
> Key: LOG4J2-2429
> URL: https://issues.apache.org/jira/browse/LOG4J2-2429
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
> Fix For: Log4j-Audit 1.0.1
>
>
> Setting the \{{exceptionHandler}} on the \{{AuditEvent}} triggers [this
> code|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/LogEventFactory.java#L306],
> but it falls through after the set and ends up at line 315 and sets it as a
> \{{ThreadContext}} variable and ends up getting logged 🤦♂️
> {noformat}
> [AuditLogger] - Audit [cashPaymentOut amount="0.500"
> auditExceptionHandler="AuditEventLogger$$Lambda$137/1968918278@54de299"
> currency="CHF" reason="Cash return"
> salesTransaction="3b974661-d8ed-481d-b2fe-5f2979b40fa9"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2429) Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext variable
[
https://issues.apache.org/jira/browse/LOG4J2-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625205#comment-16625205
]
ASF GitHub Bot commented on LOG4J2-2429:
Github user asfgit closed the pull request at:
https://github.com/apache/logging-log4j-audit/pull/10
> Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext
> variable
> --
>
> Key: LOG4J2-2429
> URL: https://issues.apache.org/jira/browse/LOG4J2-2429
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
>
> Setting the \{{exceptionHandler}} on the \{{AuditEvent}} triggers [this
> code|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/LogEventFactory.java#L306],
> but it falls through after the set and ends up at line 315 and sets it as a
> \{{ThreadContext}} variable and ends up getting logged 🤦♂️
> {noformat}
> [AuditLogger] - Audit [cashPaymentOut amount="0.500"
> auditExceptionHandler="AuditEventLogger$$Lambda$137/1968918278@54de299"
> currency="CHF" reason="Cash return"
> salesTransaction="3b974661-d8ed-481d-b2fe-5f2979b40fa9"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2429) Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext variable
[
https://issues.apache.org/jira/browse/LOG4J2-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625202#comment-16625202
]
ASF subversion and git services commented on LOG4J2-2429:
-
Commit 3f3a56f43781d5d5735a2154bfddab4414778a92 in logging-log4j-audit's branch
refs/heads/master from [~aivanov93]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=3f3a56f ]
[LOG4J2-2429] use same formatting as surrounding lines
> Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext
> variable
> --
>
> Key: LOG4J2-2429
> URL: https://issues.apache.org/jira/browse/LOG4J2-2429
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
>
> Setting the \{{exceptionHandler}} on the \{{AuditEvent}} triggers [this
> code|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/LogEventFactory.java#L306],
> but it falls through after the set and ends up at line 315 and sets it as a
> \{{ThreadContext}} variable and ends up getting logged 🤦♂️
> {noformat}
> [AuditLogger] - Audit [cashPaymentOut amount="0.500"
> auditExceptionHandler="AuditEventLogger$$Lambda$137/1968918278@54de299"
> currency="CHF" reason="Cash return"
> salesTransaction="3b974661-d8ed-481d-b2fe-5f2979b40fa9"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2429) Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext variable
[
https://issues.apache.org/jira/browse/LOG4J2-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625204#comment-16625204
]
ASF subversion and git services commented on LOG4J2-2429:
-
Commit 8f460ee0208316becb12e343441700aec41339f1 in logging-log4j-audit's branch
refs/heads/master from [~ralph.go...@dslextreme.com]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=8f460ee ]
LOG4J2-2429 - Setting the exceptionHandler on the AuditEvent sets it as a
ThreadContext variable
> Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext
> variable
> --
>
> Key: LOG4J2-2429
> URL: https://issues.apache.org/jira/browse/LOG4J2-2429
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
>
> Setting the \{{exceptionHandler}} on the \{{AuditEvent}} triggers [this
> code|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/LogEventFactory.java#L306],
> but it falls through after the set and ends up at line 315 and sets it as a
> \{{ThreadContext}} variable and ends up getting logged 🤦♂️
> {noformat}
> [AuditLogger] - Audit [cashPaymentOut amount="0.500"
> auditExceptionHandler="AuditEventLogger$$Lambda$137/1968918278@54de299"
> currency="CHF" reason="Cash return"
> salesTransaction="3b974661-d8ed-481d-b2fe-5f2979b40fa9"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2429) Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext variable
[
https://issues.apache.org/jira/browse/LOG4J2-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625201#comment-16625201
]
ASF subversion and git services commented on LOG4J2-2429:
-
Commit 16fa48335b4ff7f06102689f237b5f4e7d398f79 in logging-log4j-audit's branch
refs/heads/master from [~aivanov93]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=16fa483 ]
[LOG4J2-2429] don't cascade on method invocations
> Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext
> variable
> --
>
> Key: LOG4J2-2429
> URL: https://issues.apache.org/jira/browse/LOG4J2-2429
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
>
> Setting the \{{exceptionHandler}} on the \{{AuditEvent}} triggers [this
> code|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/LogEventFactory.java#L306],
> but it falls through after the set and ends up at line 315 and sets it as a
> \{{ThreadContext}} variable and ends up getting logged 🤦♂️
> {noformat}
> [AuditLogger] - Audit [cashPaymentOut amount="0.500"
> auditExceptionHandler="AuditEventLogger$$Lambda$137/1968918278@54de299"
> currency="CHF" reason="Cash return"
> salesTransaction="3b974661-d8ed-481d-b2fe-5f2979b40fa9"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2429) Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext variable
[
https://issues.apache.org/jira/browse/LOG4J2-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625203#comment-16625203
]
ASF subversion and git services commented on LOG4J2-2429:
-
Commit da385005f631386b72255910db9579b84064b96c in logging-log4j-audit's branch
refs/heads/master from [~aivanov93]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=da38500 ]
[LOG4J2-2429] cleanup assertions
> Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext
> variable
> --
>
> Key: LOG4J2-2429
> URL: https://issues.apache.org/jira/browse/LOG4J2-2429
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
>
> Setting the \{{exceptionHandler}} on the \{{AuditEvent}} triggers [this
> code|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/LogEventFactory.java#L306],
> but it falls through after the set and ends up at line 315 and sets it as a
> \{{ThreadContext}} variable and ends up getting logged 🤦♂️
> {noformat}
> [AuditLogger] - Audit [cashPaymentOut amount="0.500"
> auditExceptionHandler="AuditEventLogger$$Lambda$137/1968918278@54de299"
> currency="CHF" reason="Cash return"
> salesTransaction="3b974661-d8ed-481d-b2fe-5f2979b40fa9"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] logging-log4j-audit pull request #10: [LOG4J2-2429]
Github user asfgit closed the pull request at: https://github.com/apache/logging-log4j-audit/pull/10 ---
[jira] [Commented] (LOG4J2-2452) Add verbose parameter to the Log4j audit Maven plugin
[
https://issues.apache.org/jira/browse/LOG4J2-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625195#comment-16625195
]
ASF GitHub Bot commented on LOG4J2-2452:
Github user asfgit closed the pull request at:
https://github.com/apache/logging-log4j-audit/pull/9
> Add verbose parameter to the Log4j audit Maven plugin
> -
>
> Key: LOG4J2-2452
> URL: https://issues.apache.org/jira/browse/LOG4J2-2452
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
> Fix For: Log4j-Audit 1.0.1
>
>
> The {{generate}} goal of the plugin prints to the standard output stream the
> full path of the generated files.
> This should be done conditionally of a new {{verbose}} parameter and maybe
> using the Maven logging facilities (I don't have any experience with Maven
> plugin internals).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (LOG4J2-2452) Add verbose parameter to the Log4j audit Maven plugin
[
https://issues.apache.org/jira/browse/LOG4J2-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-2452.
-
Resolution: Fixed
Fix Version/s: Log4j-Audit 1.0.1
Patch applied. Please verify and close.
> Add verbose parameter to the Log4j audit Maven plugin
> -
>
> Key: LOG4J2-2452
> URL: https://issues.apache.org/jira/browse/LOG4J2-2452
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
> Fix For: Log4j-Audit 1.0.1
>
>
> The {{generate}} goal of the plugin prints to the standard output stream the
> full path of the generated files.
> This should be done conditionally of a new {{verbose}} parameter and maybe
> using the Maven logging facilities (I don't have any experience with Maven
> plugin internals).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] logging-log4j-audit pull request #9: [LOG4J2-2452]
Github user asfgit closed the pull request at: https://github.com/apache/logging-log4j-audit/pull/9 ---
[jira] [Commented] (LOG4J2-2452) Add verbose parameter to the Log4j audit Maven plugin
[
https://issues.apache.org/jira/browse/LOG4J2-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625193#comment-16625193
]
ASF subversion and git services commented on LOG4J2-2452:
-
Commit 478dfb784fb14b2ba6aa013d56c075fe053f6315 in logging-log4j-audit's branch
refs/heads/master from [~aivanov93]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=478dfb7 ]
[LOG4J2-2452]
> Add verbose parameter to the Log4j audit Maven plugin
> -
>
> Key: LOG4J2-2452
> URL: https://issues.apache.org/jira/browse/LOG4J2-2452
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
>
> The {{generate}} goal of the plugin prints to the standard output stream the
> full path of the generated files.
> This should be done conditionally of a new {{verbose}} parameter and maybe
> using the Maven logging facilities (I don't have any experience with Maven
> plugin internals).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2452) Add verbose parameter to the Log4j audit Maven plugin
[
https://issues.apache.org/jira/browse/LOG4J2-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625194#comment-16625194
]
ASF subversion and git services commented on LOG4J2-2452:
-
Commit 9c8d514b663a840d2cfb52d9785c2b833e0582ec in logging-log4j-audit's branch
refs/heads/master from [~ralph.go...@dslextreme.com]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=9c8d514 ]
LOG4J2-2452 - Add verbose parameter to the Log4j audit Maven plugin
> Add verbose parameter to the Log4j audit Maven plugin
> -
>
> Key: LOG4J2-2452
> URL: https://issues.apache.org/jira/browse/LOG4J2-2452
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
>
> The {{generate}} goal of the plugin prints to the standard output stream the
> full path of the generated files.
> This should be done conditionally of a new {{verbose}} parameter and maybe
> using the Maven logging facilities (I don't have any experience with Maven
> plugin internals).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (LOG4J2-2421) AbstractEventLogger.logEvent doesn't check for missing required context attributes
[
https://issues.apache.org/jira/browse/LOG4J2-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-2421.
-
Resolution: Fixed
Fix Version/s: Log4j-Audit 1.0.1
Patch applied. Please verify and close.
> AbstractEventLogger.logEvent doesn't check for missing required context
> attributes
> --
>
> Key: LOG4J2-2421
> URL: https://issues.apache.org/jira/browse/LOG4J2-2421
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
> Fix For: Log4j-Audit 1.0.1
>
>
> Logging an event through {{LogEventFactory$AuditProxy}} validates the missing
> required context attributes:
> {noformat}
> org.apache.logging.log4j.catalog.api.exception.ConstraintValidationException:
> Event cashPaymentIn has errors :
> ThreadContext does not contain required key userName
> at
> org.apache.logging.log4j.audit.LogEventFactory$AuditProxy.invoke(LogEventFactory.java:294)
> ~[log4j-audit-api-1.0.0.jar:1.0.0]
> {noformat}
>
> Trying the same through the {{AuditLogger}}, as the {{AuditController}} does,
> doesn't trigger the same validation and the event gets through with a payload
> like this, partially adapted from the samples:
> {code:json}
> {
> "eventName": "CashPaymentIn",
> "requestContextMap": {
> "loginId": "rgoers",
> "corpAccountNumber": "12345",
> "ipAddress": "127.0.0.1"
> },
> "properties": {
> "salesTransaction": "52913b24-2459-416d-803d-e686e63761d0",
> "currency": "EUR",
> "amount": "100.00"
> }
> }
> {code}
> As far as I see in
> [AbstractEventLogger|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/AbstractEventLogger.java#L182],
> the validation of present {{requestContextAttributes}} starts, but there is
> no check to see if the required ones are present in the {{ThreadContext}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2421) AbstractEventLogger.logEvent doesn't check for missing required context attributes
[
https://issues.apache.org/jira/browse/LOG4J2-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625190#comment-16625190
]
ASF GitHub Bot commented on LOG4J2-2421:
Github user asfgit closed the pull request at:
https://github.com/apache/logging-log4j-audit/pull/8
> AbstractEventLogger.logEvent doesn't check for missing required context
> attributes
> --
>
> Key: LOG4J2-2421
> URL: https://issues.apache.org/jira/browse/LOG4J2-2421
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
> Fix For: Log4j-Audit 1.0.1
>
>
> Logging an event through {{LogEventFactory$AuditProxy}} validates the missing
> required context attributes:
> {noformat}
> org.apache.logging.log4j.catalog.api.exception.ConstraintValidationException:
> Event cashPaymentIn has errors :
> ThreadContext does not contain required key userName
> at
> org.apache.logging.log4j.audit.LogEventFactory$AuditProxy.invoke(LogEventFactory.java:294)
> ~[log4j-audit-api-1.0.0.jar:1.0.0]
> {noformat}
>
> Trying the same through the {{AuditLogger}}, as the {{AuditController}} does,
> doesn't trigger the same validation and the event gets through with a payload
> like this, partially adapted from the samples:
> {code:json}
> {
> "eventName": "CashPaymentIn",
> "requestContextMap": {
> "loginId": "rgoers",
> "corpAccountNumber": "12345",
> "ipAddress": "127.0.0.1"
> },
> "properties": {
> "salesTransaction": "52913b24-2459-416d-803d-e686e63761d0",
> "currency": "EUR",
> "amount": "100.00"
> }
> }
> {code}
> As far as I see in
> [AbstractEventLogger|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/AbstractEventLogger.java#L182],
> the validation of present {{requestContextAttributes}} starts, but there is
> no check to see if the required ones are present in the {{ThreadContext}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] logging-log4j-audit pull request #8: [LOG4J2-2421]
Github user asfgit closed the pull request at: https://github.com/apache/logging-log4j-audit/pull/8 ---
[jira] [Commented] (LOG4J2-2421) AbstractEventLogger.logEvent doesn't check for missing required context attributes
[
https://issues.apache.org/jira/browse/LOG4J2-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625188#comment-16625188
]
ASF subversion and git services commented on LOG4J2-2421:
-
Commit 138b8089db229698d1eee8ed0558c6c37d707877 in logging-log4j-audit's branch
refs/heads/master from [~aivanov93]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=138b808 ]
LOG4J2-2421: cleanup
> AbstractEventLogger.logEvent doesn't check for missing required context
> attributes
> --
>
> Key: LOG4J2-2421
> URL: https://issues.apache.org/jira/browse/LOG4J2-2421
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
>
> Logging an event through {{LogEventFactory$AuditProxy}} validates the missing
> required context attributes:
> {noformat}
> org.apache.logging.log4j.catalog.api.exception.ConstraintValidationException:
> Event cashPaymentIn has errors :
> ThreadContext does not contain required key userName
> at
> org.apache.logging.log4j.audit.LogEventFactory$AuditProxy.invoke(LogEventFactory.java:294)
> ~[log4j-audit-api-1.0.0.jar:1.0.0]
> {noformat}
>
> Trying the same through the {{AuditLogger}}, as the {{AuditController}} does,
> doesn't trigger the same validation and the event gets through with a payload
> like this, partially adapted from the samples:
> {code:json}
> {
> "eventName": "CashPaymentIn",
> "requestContextMap": {
> "loginId": "rgoers",
> "corpAccountNumber": "12345",
> "ipAddress": "127.0.0.1"
> },
> "properties": {
> "salesTransaction": "52913b24-2459-416d-803d-e686e63761d0",
> "currency": "EUR",
> "amount": "100.00"
> }
> }
> {code}
> As far as I see in
> [AbstractEventLogger|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/AbstractEventLogger.java#L182],
> the validation of present {{requestContextAttributes}} starts, but there is
> no check to see if the required ones are present in the {{ThreadContext}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2421) AbstractEventLogger.logEvent doesn't check for missing required context attributes
[
https://issues.apache.org/jira/browse/LOG4J2-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625189#comment-16625189
]
ASF subversion and git services commented on LOG4J2-2421:
-
Commit 8b56411dfd2ea36cc8f2f42d6c7494080dca5200 in logging-log4j-audit's branch
refs/heads/master from [~ralph.go...@dslextreme.com]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=8b56411 ]
LOG4J2-2421 - AbstractEventLogger.logEvent doesn't check for missing required
context attributes
> AbstractEventLogger.logEvent doesn't check for missing required context
> attributes
> --
>
> Key: LOG4J2-2421
> URL: https://issues.apache.org/jira/browse/LOG4J2-2421
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
>
> Logging an event through {{LogEventFactory$AuditProxy}} validates the missing
> required context attributes:
> {noformat}
> org.apache.logging.log4j.catalog.api.exception.ConstraintValidationException:
> Event cashPaymentIn has errors :
> ThreadContext does not contain required key userName
> at
> org.apache.logging.log4j.audit.LogEventFactory$AuditProxy.invoke(LogEventFactory.java:294)
> ~[log4j-audit-api-1.0.0.jar:1.0.0]
> {noformat}
>
> Trying the same through the {{AuditLogger}}, as the {{AuditController}} does,
> doesn't trigger the same validation and the event gets through with a payload
> like this, partially adapted from the samples:
> {code:json}
> {
> "eventName": "CashPaymentIn",
> "requestContextMap": {
> "loginId": "rgoers",
> "corpAccountNumber": "12345",
> "ipAddress": "127.0.0.1"
> },
> "properties": {
> "salesTransaction": "52913b24-2459-416d-803d-e686e63761d0",
> "currency": "EUR",
> "amount": "100.00"
> }
> }
> {code}
> As far as I see in
> [AbstractEventLogger|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/AbstractEventLogger.java#L182],
> the validation of present {{requestContextAttributes}} starts, but there is
> no check to see if the required ones are present in the {{ThreadContext}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2421) AbstractEventLogger.logEvent doesn't check for missing required context attributes
[
https://issues.apache.org/jira/browse/LOG4J2-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625185#comment-16625185
]
ASF subversion and git services commented on LOG4J2-2421:
-
Commit baa2d74d9e4437629d02f6670d87c5430d6e5e69 in logging-log4j-audit's branch
refs/heads/master from [~aivanov93]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=baa2d74 ]
[LOG4J2-2421] iterate only over the defined request context attributes as the
ThreadContext can have others extra
> AbstractEventLogger.logEvent doesn't check for missing required context
> attributes
> --
>
> Key: LOG4J2-2421
> URL: https://issues.apache.org/jira/browse/LOG4J2-2421
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
>
> Logging an event through {{LogEventFactory$AuditProxy}} validates the missing
> required context attributes:
> {noformat}
> org.apache.logging.log4j.catalog.api.exception.ConstraintValidationException:
> Event cashPaymentIn has errors :
> ThreadContext does not contain required key userName
> at
> org.apache.logging.log4j.audit.LogEventFactory$AuditProxy.invoke(LogEventFactory.java:294)
> ~[log4j-audit-api-1.0.0.jar:1.0.0]
> {noformat}
>
> Trying the same through the {{AuditLogger}}, as the {{AuditController}} does,
> doesn't trigger the same validation and the event gets through with a payload
> like this, partially adapted from the samples:
> {code:json}
> {
> "eventName": "CashPaymentIn",
> "requestContextMap": {
> "loginId": "rgoers",
> "corpAccountNumber": "12345",
> "ipAddress": "127.0.0.1"
> },
> "properties": {
> "salesTransaction": "52913b24-2459-416d-803d-e686e63761d0",
> "currency": "EUR",
> "amount": "100.00"
> }
> }
> {code}
> As far as I see in
> [AbstractEventLogger|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/AbstractEventLogger.java#L182],
> the validation of present {{requestContextAttributes}} starts, but there is
> no check to see if the required ones are present in the {{ThreadContext}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2421) AbstractEventLogger.logEvent doesn't check for missing required context attributes
[
https://issues.apache.org/jira/browse/LOG4J2-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625186#comment-16625186
]
ASF subversion and git services commented on LOG4J2-2421:
-
Commit 0c3a58a33923a4eabac20669a89b8cc7dbc21575 in logging-log4j-audit's branch
refs/heads/master from [~aivanov93]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=0c3a58a ]
[LOG4J2-2421] remove pointless creation of array
> AbstractEventLogger.logEvent doesn't check for missing required context
> attributes
> --
>
> Key: LOG4J2-2421
> URL: https://issues.apache.org/jira/browse/LOG4J2-2421
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
>
> Logging an event through {{LogEventFactory$AuditProxy}} validates the missing
> required context attributes:
> {noformat}
> org.apache.logging.log4j.catalog.api.exception.ConstraintValidationException:
> Event cashPaymentIn has errors :
> ThreadContext does not contain required key userName
> at
> org.apache.logging.log4j.audit.LogEventFactory$AuditProxy.invoke(LogEventFactory.java:294)
> ~[log4j-audit-api-1.0.0.jar:1.0.0]
> {noformat}
>
> Trying the same through the {{AuditLogger}}, as the {{AuditController}} does,
> doesn't trigger the same validation and the event gets through with a payload
> like this, partially adapted from the samples:
> {code:json}
> {
> "eventName": "CashPaymentIn",
> "requestContextMap": {
> "loginId": "rgoers",
> "corpAccountNumber": "12345",
> "ipAddress": "127.0.0.1"
> },
> "properties": {
> "salesTransaction": "52913b24-2459-416d-803d-e686e63761d0",
> "currency": "EUR",
> "amount": "100.00"
> }
> }
> {code}
> As far as I see in
> [AbstractEventLogger|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/AbstractEventLogger.java#L182],
> the validation of present {{requestContextAttributes}} starts, but there is
> no check to see if the required ones are present in the {{ThreadContext}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2421) AbstractEventLogger.logEvent doesn't check for missing required context attributes
[
https://issues.apache.org/jira/browse/LOG4J2-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625187#comment-16625187
]
ASF subversion and git services commented on LOG4J2-2421:
-
Commit 45884e0aa192954068d57b36e5539fdf66ceb052 in logging-log4j-audit's branch
refs/heads/master from [~aivanov93]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=45884e0 ]
Merge branch 'master' of https://github.com/apache/logging-log4j-audit into
LOG4J2-2421
> AbstractEventLogger.logEvent doesn't check for missing required context
> attributes
> --
>
> Key: LOG4J2-2421
> URL: https://issues.apache.org/jira/browse/LOG4J2-2421
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
>
> Logging an event through {{LogEventFactory$AuditProxy}} validates the missing
> required context attributes:
> {noformat}
> org.apache.logging.log4j.catalog.api.exception.ConstraintValidationException:
> Event cashPaymentIn has errors :
> ThreadContext does not contain required key userName
> at
> org.apache.logging.log4j.audit.LogEventFactory$AuditProxy.invoke(LogEventFactory.java:294)
> ~[log4j-audit-api-1.0.0.jar:1.0.0]
> {noformat}
>
> Trying the same through the {{AuditLogger}}, as the {{AuditController}} does,
> doesn't trigger the same validation and the event gets through with a payload
> like this, partially adapted from the samples:
> {code:json}
> {
> "eventName": "CashPaymentIn",
> "requestContextMap": {
> "loginId": "rgoers",
> "corpAccountNumber": "12345",
> "ipAddress": "127.0.0.1"
> },
> "properties": {
> "salesTransaction": "52913b24-2459-416d-803d-e686e63761d0",
> "currency": "EUR",
> "amount": "100.00"
> }
> }
> {code}
> As far as I see in
> [AbstractEventLogger|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/AbstractEventLogger.java#L182],
> the validation of present {{requestContextAttributes}} starts, but there is
> no check to see if the required ones are present in the {{ThreadContext}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2421) AbstractEventLogger.logEvent doesn't check for missing required context attributes
[
https://issues.apache.org/jira/browse/LOG4J2-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625184#comment-16625184
]
ASF subversion and git services commented on LOG4J2-2421:
-
Commit af89554f0d34ebd8263b0693cd8c6a6095b6b772 in logging-log4j-audit's branch
refs/heads/master from [~aivanov93]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-audit.git;h=af89554 ]
[LOG4J2-2421] check for the presence of required ThreadContext atributes
> AbstractEventLogger.logEvent doesn't check for missing required context
> attributes
> --
>
> Key: LOG4J2-2421
> URL: https://issues.apache.org/jira/browse/LOG4J2-2421
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
>
> Logging an event through {{LogEventFactory$AuditProxy}} validates the missing
> required context attributes:
> {noformat}
> org.apache.logging.log4j.catalog.api.exception.ConstraintValidationException:
> Event cashPaymentIn has errors :
> ThreadContext does not contain required key userName
> at
> org.apache.logging.log4j.audit.LogEventFactory$AuditProxy.invoke(LogEventFactory.java:294)
> ~[log4j-audit-api-1.0.0.jar:1.0.0]
> {noformat}
>
> Trying the same through the {{AuditLogger}}, as the {{AuditController}} does,
> doesn't trigger the same validation and the event gets through with a payload
> like this, partially adapted from the samples:
> {code:json}
> {
> "eventName": "CashPaymentIn",
> "requestContextMap": {
> "loginId": "rgoers",
> "corpAccountNumber": "12345",
> "ipAddress": "127.0.0.1"
> },
> "properties": {
> "salesTransaction": "52913b24-2459-416d-803d-e686e63761d0",
> "currency": "EUR",
> "amount": "100.00"
> }
> }
> {code}
> As far as I see in
> [AbstractEventLogger|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/AbstractEventLogger.java#L182],
> the validation of present {{requestContextAttributes}} starts, but there is
> no check to see if the required ones are present in the {{ThreadContext}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2440) AuditEvents should provide some basic toString()
[
https://issues.apache.org/jira/browse/LOG4J2-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625088#comment-16625088
]
ASF GitHub Bot commented on LOG4J2-2440:
GitHub user andrei-ivanov opened a pull request:
https://github.com/apache/logging-log4j-audit/pull/11
[LOG4J2-2440]
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/andrei-ivanov/logging-log4j-audit LOG4J2-2440
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/logging-log4j-audit/pull/11.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #11
commit 5e67a33704d0a768b6adb41533e7966489f4072f
Author: Andrei Ivanov
Date: 2018-09-23T12:17:02Z
[LOG4J2-2440]
commit cb7bed47e2267c1a130be9df5eedfa3e7ec337e8
Author: Andrei Ivanov
Date: 2018-09-23T12:18:36Z
[LOG4J2-2420] use same formatting as surrounding lines
> AuditEvents should provide some basic toString()
>
>
> Key: LOG4J2-2440
> URL: https://issues.apache.org/jira/browse/LOG4J2-2440
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
>
> Currently invoking {{toString()}} on an event built by
> {{LogEventFactory.getEvent}} returns {{null}}.
> It would be nice to get something more meaningful than that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] logging-log4j-audit pull request #11: [LOG4J2-2440]
GitHub user andrei-ivanov opened a pull request: https://github.com/apache/logging-log4j-audit/pull/11 [LOG4J2-2440] You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrei-ivanov/logging-log4j-audit LOG4J2-2440 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/logging-log4j-audit/pull/11.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #11 commit 5e67a33704d0a768b6adb41533e7966489f4072f Author: Andrei Ivanov Date: 2018-09-23T12:17:02Z [LOG4J2-2440] commit cb7bed47e2267c1a130be9df5eedfa3e7ec337e8 Author: Andrei Ivanov Date: 2018-09-23T12:18:36Z [LOG4J2-2420] use same formatting as surrounding lines ---
[jira] [Commented] (LOG4J2-2429) Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext variable
[
https://issues.apache.org/jira/browse/LOG4J2-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625085#comment-16625085
]
ASF GitHub Bot commented on LOG4J2-2429:
GitHub user andrei-ivanov opened a pull request:
https://github.com/apache/logging-log4j-audit/pull/10
[LOG4J2-2429]
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/andrei-ivanov/logging-log4j-audit LOG4J2-2429
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/logging-log4j-audit/pull/10.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #10
commit 16fa48335b4ff7f06102689f237b5f4e7d398f79
Author: Andrei Ivanov
Date: 2018-09-23T12:00:00Z
[LOG4J2-2429] don't cascade on method invocations
commit 3f3a56f43781d5d5735a2154bfddab4414778a92
Author: Andrei Ivanov
Date: 2018-09-23T12:02:52Z
[LOG4J2-2429] use same formatting as surrounding lines
commit da385005f631386b72255910db9579b84064b96c
Author: Andrei Ivanov
Date: 2018-09-23T12:04:36Z
[LOG4J2-2429] cleanup assertions
> Setting the exceptionHandler on the AuditEvent sets it as a ThreadContext
> variable
> --
>
> Key: LOG4J2-2429
> URL: https://issues.apache.org/jira/browse/LOG4J2-2429
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
>
> Setting the \{{exceptionHandler}} on the \{{AuditEvent}} triggers [this
> code|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/LogEventFactory.java#L306],
> but it falls through after the set and ends up at line 315 and sets it as a
> \{{ThreadContext}} variable and ends up getting logged 🤦♂️
> {noformat}
> [AuditLogger] - Audit [cashPaymentOut amount="0.500"
> auditExceptionHandler="AuditEventLogger$$Lambda$137/1968918278@54de299"
> currency="CHF" reason="Cash return"
> salesTransaction="3b974661-d8ed-481d-b2fe-5f2979b40fa9"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] logging-log4j-audit pull request #10: [LOG4J2-2429]
GitHub user andrei-ivanov opened a pull request: https://github.com/apache/logging-log4j-audit/pull/10 [LOG4J2-2429] You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrei-ivanov/logging-log4j-audit LOG4J2-2429 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/logging-log4j-audit/pull/10.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #10 commit 16fa48335b4ff7f06102689f237b5f4e7d398f79 Author: Andrei Ivanov Date: 2018-09-23T12:00:00Z [LOG4J2-2429] don't cascade on method invocations commit 3f3a56f43781d5d5735a2154bfddab4414778a92 Author: Andrei Ivanov Date: 2018-09-23T12:02:52Z [LOG4J2-2429] use same formatting as surrounding lines commit da385005f631386b72255910db9579b84064b96c Author: Andrei Ivanov Date: 2018-09-23T12:04:36Z [LOG4J2-2429] cleanup assertions ---
[jira] [Updated] (LOG4J2-2421) AbstractEventLogger.logEvent doesn't check for missing required context attributes
[
https://issues.apache.org/jira/browse/LOG4J2-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Ivanov updated LOG4J2-2421:
--
Flags: Patch
> AbstractEventLogger.logEvent doesn't check for missing required context
> attributes
> --
>
> Key: LOG4J2-2421
> URL: https://issues.apache.org/jira/browse/LOG4J2-2421
> Project: Log4j 2
> Issue Type: Bug
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Major
>
> Logging an event through {{LogEventFactory$AuditProxy}} validates the missing
> required context attributes:
> {noformat}
> org.apache.logging.log4j.catalog.api.exception.ConstraintValidationException:
> Event cashPaymentIn has errors :
> ThreadContext does not contain required key userName
> at
> org.apache.logging.log4j.audit.LogEventFactory$AuditProxy.invoke(LogEventFactory.java:294)
> ~[log4j-audit-api-1.0.0.jar:1.0.0]
> {noformat}
>
> Trying the same through the {{AuditLogger}}, as the {{AuditController}} does,
> doesn't trigger the same validation and the event gets through with a payload
> like this, partially adapted from the samples:
> {code:json}
> {
> "eventName": "CashPaymentIn",
> "requestContextMap": {
> "loginId": "rgoers",
> "corpAccountNumber": "12345",
> "ipAddress": "127.0.0.1"
> },
> "properties": {
> "salesTransaction": "52913b24-2459-416d-803d-e686e63761d0",
> "currency": "EUR",
> "amount": "100.00"
> }
> }
> {code}
> As far as I see in
> [AbstractEventLogger|https://github.com/apache/logging-log4j-audit/blob/master/log4j-audit/log4j-audit-api/src/main/java/org/apache/logging/log4j/audit/AbstractEventLogger.java#L182],
> the validation of present {{requestContextAttributes}} starts, but there is
> no check to see if the required ones are present in the {{ThreadContext}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2452) Add verbose parameter to the Log4j audit Maven plugin
[
https://issues.apache.org/jira/browse/LOG4J2-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625076#comment-16625076
]
ASF GitHub Bot commented on LOG4J2-2452:
Github user andrei-ivanov commented on the issue:
https://github.com/apache/logging-log4j-audit/pull/9
I couldn't pass and use the Maven plugin logger to the
`InterfacesGenerator` and `ClassGenerator` as they are not located in
`log4j-audit-maven-plugin`, but in `log4j-audit-api` and I'm not sure if it's
appropriate, as they seem to also be defined as Spring components.
I guess some sort of adapter should be used, but that complicates things 😟
> Add verbose parameter to the Log4j audit Maven plugin
> -
>
> Key: LOG4J2-2452
> URL: https://issues.apache.org/jira/browse/LOG4J2-2452
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
>
> The {{generate}} goal of the plugin prints to the standard output stream the
> full path of the generated files.
> This should be done conditionally of a new {{verbose}} parameter and maybe
> using the Maven logging facilities (I don't have any experience with Maven
> plugin internals).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] logging-log4j-audit issue #9: [LOG4J2-2452]
Github user andrei-ivanov commented on the issue: https://github.com/apache/logging-log4j-audit/pull/9 I couldn't pass and use the Maven plugin logger to the `InterfacesGenerator` and `ClassGenerator` as they are not located in `log4j-audit-maven-plugin`, but in `log4j-audit-api` and I'm not sure if it's appropriate, as they seem to also be defined as Spring components. I guess some sort of adapter should be used, but that complicates things ð ---
[jira] [Commented] (LOG4J2-2452) Add verbose parameter to the Log4j audit Maven plugin
[
https://issues.apache.org/jira/browse/LOG4J2-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625074#comment-16625074
]
ASF GitHub Bot commented on LOG4J2-2452:
GitHub user andrei-ivanov opened a pull request:
https://github.com/apache/logging-log4j-audit/pull/9
[LOG4J2-2452]
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/andrei-ivanov/logging-log4j-audit LOG4J2-2452
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/logging-log4j-audit/pull/9.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #9
commit 478dfb784fb14b2ba6aa013d56c075fe053f6315
Author: Andrei Ivanov
Date: 2018-09-23T11:25:41Z
[LOG4J2-2452]
> Add verbose parameter to the Log4j audit Maven plugin
> -
>
> Key: LOG4J2-2452
> URL: https://issues.apache.org/jira/browse/LOG4J2-2452
> Project: Log4j 2
> Issue Type: Improvement
> Components: Log4j-Audit
>Affects Versions: Log4j-Audit 1.0.0
>Reporter: Andrei Ivanov
>Priority: Minor
>
> The {{generate}} goal of the plugin prints to the standard output stream the
> full path of the generated files.
> This should be done conditionally of a new {{verbose}} parameter and maybe
> using the Maven logging facilities (I don't have any experience with Maven
> plugin internals).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] logging-log4j-audit pull request #9: [LOG4J2-2452]
GitHub user andrei-ivanov opened a pull request: https://github.com/apache/logging-log4j-audit/pull/9 [LOG4J2-2452] You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrei-ivanov/logging-log4j-audit LOG4J2-2452 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/logging-log4j-audit/pull/9.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #9 commit 478dfb784fb14b2ba6aa013d56c075fe053f6315 Author: Andrei Ivanov Date: 2018-09-23T11:25:41Z [LOG4J2-2452] ---
[jira] [Created] (LOG4J2-2452) Add verbose parameter to the Log4j audit Maven plugin
Andrei Ivanov created LOG4J2-2452:
-
Summary: Add verbose parameter to the Log4j audit Maven plugin
Key: LOG4J2-2452
URL: https://issues.apache.org/jira/browse/LOG4J2-2452
Project: Log4j 2
Issue Type: Improvement
Components: Log4j-Audit
Affects Versions: Log4j-Audit 1.0.0
Reporter: Andrei Ivanov
The {{generate}} goal of the plugin prints to the standard output stream the
full path of the generated files.
This should be done conditionally of a new {{verbose}} parameter and maybe
using the Maven logging facilities (I don't have any experience with Maven
plugin internals).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
