[jira] [Commented] (LOG4J2-2299) Using "asyncLogger" with AsyncLoggerContextSelector loses some event data
[ https://issues.apache.org/jira/browse/LOG4J2-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423451#comment-16423451 ] Carter Kozak commented on LOG4J2-2299: -- Implementation of the proposal for the memento change: [https://github.com/cakofony/logging-log4j2/commit/e12cd25b741b424485d7aef9ff78a1bc5883] Would it be preferable if I filed a separate ticket to track that? > Using "asyncLogger" with AsyncLoggerContextSelector loses some event data > - > > Key: LOG4J2-2299 > URL: https://issues.apache.org/jira/browse/LOG4J2-2299 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.11.0 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > > Using mixed style "asyncLogger" definitions when AsyncLoggerContextSelector > is selected and reusable messages are enabled causes parameterized message > data to be lost (Guessing we memento the message handing it off between > disruptors). > Proposal: > Would it be objectionable to parse AsyncLoggerConfigs as standard > LoggerConfig when global async mode is enabled? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (LOG4J2-2301) gc-free mixed async loging loses parameter values after the first appender
[ https://issues.apache.org/jira/browse/LOG4J2-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423340#comment-16423340 ] Carter Kozak edited comment on LOG4J2-2301 at 4/3/18 3:48 AM: -- Perfect, will do! Edit: Holding off just a bit for LOG4J-2299, commit for that issue provides utilities I'd like to use in this test was (Author: ckozak): Perfect, will do! > gc-free mixed async loging loses parameter values after the first appender > -- > > Key: LOG4J2-2301 > URL: https://issues.apache.org/jira/browse/LOG4J2-2301 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.11.0 >Reporter: Carter Kozak >Priority: Major > > When gc-free logging is used with mixed synchronous/asynchronous loggers, > parameter values are replaced with "null" after the first AsyncLoggerConfig. > The message format is still present, as well as the parameter count, however > all values are nulls. > It appears that Log4jEventWrapperHandler.onEvent invokes > MutableLogEvent.clear, which nulls out the parameter array. > I have constructed a failing test (which I need to clean up and deduplicate > some code from the fix for LOG4J2-2299): > https://github.com/cakofony/logging-log4j2/commit/b9c03f5c6881bfe778f8e2d75d046ce6e021c4f1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4J2-2299) Using "asyncLogger" with AsyncLoggerContextSelector loses some event data
[ https://issues.apache.org/jira/browse/LOG4J2-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423408#comment-16423408 ] Carter Kozak commented on LOG4J2-2299: -- My initial change is here: [https://github.com/cakofony/logging-log4j2/commit/3d69e449c2dd17dc97b148ae5eece5070d68b4e5] We begin on the AsyncLoggerDisruptor, but when AsnycLoggerConfig elements are encountered we pass them the result of RingBufferLogEvent.createMemento, which is always the string value of the formatted text with no parameters or format string: [https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/async/AsyncLoggerConfigDisruptor.java#L383-L391] I think this unpacks into two issues: #1: Our memento doesn't track the original format or parameters Proposed solution: I'd like to create a MementoMessage type which takes the formatted message string (to avoid losing data from custom messages), format, and parameter array, which can be produced by RingBufferLogEvent/MutableLogEvent/etc #2: Ideally AsyncLoggers shouldn't require memento allocation when we've enabled global asynchronous logging. The simplest solution is to force all logging from into the AsyncLogger path rather than AsyncLoggerConfig, otherwise threading gets quite tricky (which may tie into LOG4J2-2301) and difficult to test/maintain. I'm very open to other ideas :-) > Using "asyncLogger" with AsyncLoggerContextSelector loses some event data > - > > Key: LOG4J2-2299 > URL: https://issues.apache.org/jira/browse/LOG4J2-2299 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.11.0 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > > Using mixed style "asyncLogger" definitions when AsyncLoggerContextSelector > is selected and reusable messages are enabled causes parameterized message > data to be lost (Guessing we memento the message handing it off between > disruptors). > Proposal: > Would it be objectionable to parse AsyncLoggerConfigs as standard > LoggerConfig when global async mode is enabled? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4J2-2301) gc-free mixed async loging loses parameter values after the first appender
[ https://issues.apache.org/jira/browse/LOG4J2-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423340#comment-16423340 ] Carter Kozak commented on LOG4J2-2301: -- Perfect, will do! > gc-free mixed async loging loses parameter values after the first appender > -- > > Key: LOG4J2-2301 > URL: https://issues.apache.org/jira/browse/LOG4J2-2301 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.11.0 >Reporter: Carter Kozak >Priority: Major > > When gc-free logging is used with mixed synchronous/asynchronous loggers, > parameter values are replaced with "null" after the first AsyncLoggerConfig. > The message format is still present, as well as the parameter count, however > all values are nulls. > It appears that Log4jEventWrapperHandler.onEvent invokes > MutableLogEvent.clear, which nulls out the parameter array. > I have constructed a failing test (which I need to clean up and deduplicate > some code from the fix for LOG4J2-2299): > https://github.com/cakofony/logging-log4j2/commit/b9c03f5c6881bfe778f8e2d75d046ce6e021c4f1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4J2-2299) Using "asyncLogger" with AsyncLoggerContextSelector loses some event data
[ https://issues.apache.org/jira/browse/LOG4J2-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423338#comment-16423338 ] Remko Popma commented on LOG4J2-2299: - In principle when AsyncLoggerContextSelector is selected, all loggers are async, so having a distinction between "AsyncLogger" and "Logger" in the configuration no longer makes sense. Parsing AsyncLoggerConfigs as standard LoggerConfig when global async mode is enabled should be okay. That said, it would be better if we could identify and fix the underlying cause of the problem. Do the AsyncLogger and the AsyncLoggerConfig share the same data structure? If the application thread hands over the same mutable/reusable object to both the AsyncLogger background thread and the AsyncLoggerConfig background thread, then this will cause problems... > Using "asyncLogger" with AsyncLoggerContextSelector loses some event data > - > > Key: LOG4J2-2299 > URL: https://issues.apache.org/jira/browse/LOG4J2-2299 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.11.0 >Reporter: Carter Kozak >Assignee: Carter Kozak >Priority: Major > > Using mixed style "asyncLogger" definitions when AsyncLoggerContextSelector > is selected and reusable messages are enabled causes parameterized message > data to be lost (Guessing we memento the message handing it off between > disruptors). > Proposal: > Would it be objectionable to parse AsyncLoggerConfigs as standard > LoggerConfig when global async mode is enabled? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOGCXX-494) Provide a windows build environment for the project
[ https://issues.apache.org/jira/browse/LOGCXX-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423238#comment-16423238 ] James E. King, III commented on LOGCXX-494: --- Thanks for the speedy reply! Visual studio projects were checked in up to 0.9.7: [https://github.com/apache/logging-log4cxx/tree/v0_9_7/msvc] I would highly recommend that you consider deprecating the ant build system for windows in favor of cmake. cmake is what many projects are using for windows C++ builds. It allows the end-user to generate full Visual Studio projects for any supported version of Visual Studio from 2010 through 2017 as well as make it easy to configure and build. The "apr" project that log4cxx relies on has moved on considerably and this allows the windows build to consume apr-2 which is the upcoming replacement to the separate apr + apr-util libraries, as apr-util merged into apr. Thanks for the dist link, that could be useful to folks looking for a project file; or cmake build support for the project. I crafted it in a way that it just reads the version out of the configure.ac file so there wouldn't be any additional work on your end. Okay, so I will leave this PR here but I am not going to check up on its progress unless I end up making changes to it somehow. Thanks. > Provide a windows build environment for the project > --- > > Key: LOGCXX-494 > URL: https://issues.apache.org/jira/browse/LOGCXX-494 > Project: Log4cxx > Issue Type: Improvement > Components: Build >Affects Versions: 0.10.0 > Environment: Windows, any flavor >Reporter: James E. King, III >Priority: Major > > In version 0.10.0 all windows project files were removed from the repository. > The apr project which log4cxx depends on provides both a static project file > (which I would discourage) as well as a cmake build environment for windows > (which can generate a solution for any version of Visual Studio). > The improvement request is to provide a cmake build environment for log4cxx. > I believe it would be acceptable to tie this to the apr-2 project, given that > apr-util folded into apr about 5 years ago... when will apr-2 be released? > The web site documentation for building on Visual Studio is ancient (10+ > years old): > https://logging.apache.org/log4cxx/latest_stable/building/vstudio.html > This should also be updated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (LOG4J2-2303) Add release distribution script
[ https://issues.apache.org/jira/browse/LOG4J2-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-2303: Description: There don't seem to be any similar sbt plugins to maven-assembly-plugin (sbt-native-packager seems similar, but it's focused on creating applications, not library distributions). A shell script would also work. (was: Using the [universal package format|https://sbt-native-packager.readthedocs.io/en/stable/formats/universal.html] of sbt-native-packager, the usual Apache distribution artifacts (source and binary zips and tarballs) can all be created and signed.) > Add release distribution script > --- > > Key: LOG4J2-2303 > URL: https://issues.apache.org/jira/browse/LOG4J2-2303 > Project: Log4j 2 > Issue Type: Sub-task > Components: Scala API >Affects Versions: 11.0 >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Major > Fix For: 11.1 > > > There don't seem to be any similar sbt plugins to maven-assembly-plugin > (sbt-native-packager seems similar, but it's focused on creating > applications, not library distributions). A shell script would also work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (LOG4J2-2303) Add release distribution script
[ https://issues.apache.org/jira/browse/LOG4J2-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-2303: Summary: Add release distribution script (was: Add release distribution config to sbt) > Add release distribution script > --- > > Key: LOG4J2-2303 > URL: https://issues.apache.org/jira/browse/LOG4J2-2303 > Project: Log4j 2 > Issue Type: Sub-task > Components: Scala API >Affects Versions: 11.0 >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Major > Fix For: 11.1 > > > Using the [universal package > format|https://sbt-native-packager.readthedocs.io/en/stable/formats/universal.html] > of sbt-native-packager, the usual Apache distribution artifacts (source and > binary zips and tarballs) can all be created and signed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (LOG4J2-2303) Add release distribution config to sbt
Matt Sicker created LOG4J2-2303: --- Summary: Add release distribution config to sbt Key: LOG4J2-2303 URL: https://issues.apache.org/jira/browse/LOG4J2-2303 Project: Log4j 2 Issue Type: Sub-task Components: Scala API Affects Versions: 11.0 Reporter: Matt Sicker Assignee: Matt Sicker Fix For: 11.1 Using the [universal package format|https://sbt-native-packager.readthedocs.io/en/stable/formats/universal.html] of sbt-native-packager, the usual Apache distribution artifacts (source and binary zips and tarballs) can all be created and signed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOGCXX-494) Provide a windows build environment for the project
[ https://issues.apache.org/jira/browse/LOGCXX-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423118#comment-16423118 ] ASF GitHub Bot commented on LOGCXX-494: --- Github user tschoening commented on the issue: https://github.com/apache/logging-log4cxx/pull/3 > Any update on this? It's almost 3 months old now and no updates from the log4cxx team. Because I responded on the mailing list: http://mail-archives.apache.org/mod_mbox/logging-dev/201801.mbox/<1913119533.2018072120%40am-soft.de> At least I don't have any plans to deal with such a major change in the build currently, I simply don't have the time to do so. > Not recommending a change in the overall build system. It's either about the addition of CMAKE to what is already there or the replacement of something which is already there, both are major changes from my understanding. And we already have Autotools, Maven, Shell Scripts, ANT and none of those is properly integrated with each other to support everything which is needed, like development iteration, version number updates, release date updates, site generation etc. > The complete lack of windows build support at all in the project trunk is what worries me the most. Build support in trunk was/is available using ANT and cpptasks and at least for some recent versions of Visual Studio this worked: https://logging.apache.org/log4cxx/latest_stable/building/index.html > The instructions on the web site tell people to go to a directory that does not exist and use a project file that is not there. Because those instructions addressed a release. > Version 0.10.0 eliminated all visual studio project files from the project[...] I'm somewhat sure they have never been in trunk, but only in the release package and have been generated during the release process. If you look at the following packages, some generated projects are still available: https://dist.apache.org/repos/dist/dev/logging/log4cxx/ > Provide a windows build environment for the project > --- > > Key: LOGCXX-494 > URL: https://issues.apache.org/jira/browse/LOGCXX-494 > Project: Log4cxx > Issue Type: Improvement > Components: Build >Affects Versions: 0.10.0 > Environment: Windows, any flavor >Reporter: James E. King, III >Priority: Major > > In version 0.10.0 all windows project files were removed from the repository. > The apr project which log4cxx depends on provides both a static project file > (which I would discourage) as well as a cmake build environment for windows > (which can generate a solution for any version of Visual Studio). > The improvement request is to provide a cmake build environment for log4cxx. > I believe it would be acceptable to tie this to the apr-2 project, given that > apr-util folded into apr about 5 years ago... when will apr-2 be released? > The web site documentation for building on Visual Studio is ancient (10+ > years old): > https://logging.apache.org/log4cxx/latest_stable/building/vstudio.html > This should also be updated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] logging-log4cxx issue #3: LOGCXX-494: windows cmake build for log4cxx agains...
Github user tschoening commented on the issue: https://github.com/apache/logging-log4cxx/pull/3 > Any update on this? It's almost 3 months old now and no updates from the log4cxx team. Because I responded on the mailing list: http://mail-archives.apache.org/mod_mbox/logging-dev/201801.mbox/<1913119533.2018072120%40am-soft.de> At least I don't have any plans to deal with such a major change in the build currently, I simply don't have the time to do so. > Not recommending a change in the overall build system. It's either about the addition of CMAKE to what is already there or the replacement of something which is already there, both are major changes from my understanding. And we already have Autotools, Maven, Shell Scripts, ANT and none of those is properly integrated with each other to support everything which is needed, like development iteration, version number updates, release date updates, site generation etc. > The complete lack of windows build support at all in the project trunk is what worries me the most. Build support in trunk was/is available using ANT and cpptasks and at least for some recent versions of Visual Studio this worked: https://logging.apache.org/log4cxx/latest_stable/building/index.html > The instructions on the web site tell people to go to a directory that does not exist and use a project file that is not there. Because those instructions addressed a release. > Version 0.10.0 eliminated all visual studio project files from the project[...] I'm somewhat sure they have never been in trunk, but only in the release package and have been generated during the release process. If you look at the following packages, some generated projects are still available: https://dist.apache.org/repos/dist/dev/logging/log4cxx/ ---
[jira] [Closed] (LOG4J2-2292) Configure GPG key signing for releases
[ https://issues.apache.org/jira/browse/LOG4J2-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-2292. --- Resolution: Fixed Figured out how to configure this locally using the instructions [on the sbt-pgp docs|https://www.scala-sbt.org/sbt-pgp/usage.html]. > Configure GPG key signing for releases > -- > > Key: LOG4J2-2292 > URL: https://issues.apache.org/jira/browse/LOG4J2-2292 > Project: Log4j 2 > Issue Type: Sub-task > Components: Scala API >Affects Versions: 11.0 >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Major > Fix For: 11.1 > > > Artifacts uploaded to dist.a.o or repository.a.o require GPG signatures. Use > an SBT plugin such as [sbt-pgp|https://www.scala-sbt.org/sbt-pgp/]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] logging-log4cxx issue #3: LOGCXX-494: windows cmake build for log4cxx agains...
Github user jeking3 commented on the issue: https://github.com/apache/logging-log4cxx/pull/3 Any update on this? It's almost 3 months old now and no updates from the log4cxx team. ---
[jira] [Closed] (LOG4J2-2302) Status logger should show the Log4j name and version when initializing itself.
[
https://issues.apache.org/jira/browse/LOG4J2-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LOG4J2-2302.
Resolution: Fixed
Fix Version/s: 2.11.1
3.0.0
> Status logger should show the Log4j name and version when initializing itself.
> --
>
> Key: LOG4J2-2302
> URL: https://issues.apache.org/jira/browse/LOG4J2-2302
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.0.0, 2.11.1
>
>
> Status logger should show the Log4j name and version when initializing itself.
> Instead of a status logger message like:
> {noformat}
> 2018-04-01 11:39:22,615 main DEBUG Initializing configuration
> XmlConfiguration[location=C:\Users\ggregory\workspaces\centipede\DevTests\target\test-classes\log4j2.xml]
> {noformat}
> I'd like to see:
> {noformat}
> 2018-04-01 11:39:22,615 main DEBUG Apache Log4j 2.11.0 initializing
> configuration
> XmlConfiguration[location=C:\Users\ggregory\workspaces\centipede\DevTests\target\test-classes\log4j2.xml]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2302) Status logger should show the Log4j name and version when initializing itself.
[
https://issues.apache.org/jira/browse/LOG4J2-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422968#comment-16422968
]
ASF subversion and git services commented on LOG4J2-2302:
-
Commit 3930ee8337bac09cab3b6613c9cb94514ed21f87 in logging-log4j2's branch
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=3930ee8 ]
[LOG4J2-2302]Status logger should show the Log4j name and version when
initializing itself.
> Status logger should show the Log4j name and version when initializing itself.
> --
>
> Key: LOG4J2-2302
> URL: https://issues.apache.org/jira/browse/LOG4J2-2302
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Status logger should show the Log4j name and version when initializing itself.
> Instead of a status logger message like:
> {noformat}
> 2018-04-01 11:39:22,615 main DEBUG Initializing configuration
> XmlConfiguration[location=C:\Users\ggregory\workspaces\centipede\DevTests\target\test-classes\log4j2.xml]
> {noformat}
> I'd like to see:
> {noformat}
> 2018-04-01 11:39:22,615 main DEBUG Apache Log4j 2.11.0 initializing
> configuration
> XmlConfiguration[location=C:\Users\ggregory\workspaces\centipede\DevTests\target\test-classes\log4j2.xml]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LOG4J2-2302) Status logger should show the Log4j name and version when initializing itself.
[
https://issues.apache.org/jira/browse/LOG4J2-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422961#comment-16422961
]
ASF subversion and git services commented on LOG4J2-2302:
-
Commit c0f1400c347cf30d9b36d3ed07a28772bba93b93 in logging-log4j2's branch
refs/heads/release-2.x from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=c0f1400 ]
[LOG4J2-2302] Status logger should show the Log4j name and version when
initializing itself.
> Status logger should show the Log4j name and version when initializing itself.
> --
>
> Key: LOG4J2-2302
> URL: https://issues.apache.org/jira/browse/LOG4J2-2302
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> Status logger should show the Log4j name and version when initializing itself.
> Instead of a status logger message like:
> {noformat}
> 2018-04-01 11:39:22,615 main DEBUG Initializing configuration
> XmlConfiguration[location=C:\Users\ggregory\workspaces\centipede\DevTests\target\test-classes\log4j2.xml]
> {noformat}
> I'd like to see:
> {noformat}
> 2018-04-01 11:39:22,615 main DEBUG Apache Log4j 2.11.0 initializing
> configuration
> XmlConfiguration[location=C:\Users\ggregory\workspaces\centipede\DevTests\target\test-classes\log4j2.xml]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (LOG4J2-2302) Status logger should show the Log4j name and version when initializing itself.
Gary Gregory created LOG4J2-2302:
Summary: Status logger should show the Log4j name and version when
initializing itself.
Key: LOG4J2-2302
URL: https://issues.apache.org/jira/browse/LOG4J2-2302
Project: Log4j 2
Issue Type: Improvement
Components: Core
Reporter: Gary Gregory
Assignee: Gary Gregory
Status logger should show the Log4j name and version when initializing itself.
Instead of a status logger message like:
{noformat}
2018-04-01 11:39:22,615 main DEBUG Initializing configuration
XmlConfiguration[location=C:\Users\ggregory\workspaces\centipede\DevTests\target\test-classes\log4j2.xml]
{noformat}
I'd like to see:
{noformat}
2018-04-01 11:39:22,615 main DEBUG Apache Log4j 2.11.0 initializing
configuration
XmlConfiguration[location=C:\Users\ggregory\workspaces\centipede\DevTests\target\test-classes\log4j2.xml]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (LOG4J2-2295) Add OSGi metadata
[ https://issues.apache.org/jira/browse/LOG4J2-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved LOG4J2-2295. - Resolution: Fixed > Add OSGi metadata > - > > Key: LOG4J2-2295 > URL: https://issues.apache.org/jira/browse/LOG4J2-2295 > Project: Log4j 2 > Issue Type: Sub-task > Components: Scala API >Affects Versions: 11.0 >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Major > Fix For: 11.1 > > > Add a plugin such as [sbt-osgi|https://github.com/sbt/sbt-osgi] to enable > OSGi metadata in the output artifacts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4J2-2295) Add OSGi metadata
[ https://issues.apache.org/jira/browse/LOG4J2-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422659#comment-16422659 ] ASF subversion and git services commented on LOG4J2-2295: - Commit 59f47b878d1a80978653e2b790d581717a180afc in logging-log4j-scala's branch refs/heads/sbt from [~jvz] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j-scala.git;h=59f47b8 ] LOG4J2-2295: Add OSGi metadata to release jars > Add OSGi metadata > - > > Key: LOG4J2-2295 > URL: https://issues.apache.org/jira/browse/LOG4J2-2295 > Project: Log4j 2 > Issue Type: Sub-task > Components: Scala API >Affects Versions: 11.0 >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Major > Fix For: 11.1 > > > Add a plugin such as [sbt-osgi|https://github.com/sbt/sbt-osgi] to enable > OSGi metadata in the output artifacts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (LOG4J2-2301) gc-free mixed async loging loses parameter values after the first appender
Carter Kozak created LOG4J2-2301: Summary: gc-free mixed async loging loses parameter values after the first appender Key: LOG4J2-2301 URL: https://issues.apache.org/jira/browse/LOG4J2-2301 Project: Log4j 2 Issue Type: Bug Components: Core Affects Versions: 2.11.0 Reporter: Carter Kozak When gc-free logging is used with mixed synchronous/asynchronous loggers, parameter values are replaced with "null" after the first AsyncLoggerConfig. The message format is still present, as well as the parameter count, however all values are nulls. It appears that Log4jEventWrapperHandler.onEvent invokes MutableLogEvent.clear, which nulls out the parameter array. I have constructed a failing test (which I need to clean up and deduplicate some code from the fix for LOG4J2-2299): https://github.com/cakofony/logging-log4j2/commit/b9c03f5c6881bfe778f8e2d75d046ce6e021c4f1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4J2-1705) Kotlin wrapper for Log4j 2 API
[ https://issues.apache.org/jira/browse/LOG4J2-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422582#comment-16422582 ] Matt Sicker commented on LOG4J2-1705: - Of course! I've been trying AsciiDoc with the Scala site in [my branch|https://github.com/apache/logging-log4j-scala/tree/sbt], so that might be a place to start (though you'll need a maven asciidoc plugin of course). Another option would be using the maven-site-plugin that we use for the log4j site, but I've found that difficult to merge multiple physically separated projects together (see for example the current CSS problems with the existing Log4j Scala API site). > Kotlin wrapper for Log4j 2 API > -- > > Key: LOG4J2-1705 > URL: https://issues.apache.org/jira/browse/LOG4J2-1705 > Project: Log4j 2 > Issue Type: New Feature > Components: API >Reporter: Raman Gupta >Assignee: Matt Sicker >Priority: Major > > Similar to LOG4J2-1181 for Scala, provide a Kotlin wrapper for the Log4j 2 > API that makes use of Kotlin features like delegates and string interpolation. > If there is interest in this, I'd like to contribute a patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4J2-1705) Kotlin wrapper for Log4j 2 API
[ https://issues.apache.org/jira/browse/LOG4J2-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422528#comment-16422528 ] Raman Gupta commented on LOG4J2-1705: - [~jvz] Can I help with that? > Kotlin wrapper for Log4j 2 API > -- > > Key: LOG4J2-1705 > URL: https://issues.apache.org/jira/browse/LOG4J2-1705 > Project: Log4j 2 > Issue Type: New Feature > Components: API >Reporter: Raman Gupta >Assignee: Matt Sicker >Priority: Major > > Similar to LOG4J2-1181 for Scala, provide a Kotlin wrapper for the Log4j 2 > API that makes use of Kotlin features like delegates and string interpolation. > If there is interest in this, I'd like to contribute a patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
