[jira] [Updated] (LOG4J2-1879) Update JAnsi from 1.14 to 1.15
[ https://issues.apache.org/jira/browse/LOG4J2-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-1879: - Summary: Update JAnsi from 1.14 to 1.15 (was: Update Jansi from 1.14 to 1.15) > Update JAnsi from 1.14 to 1.15 > -- > > Key: LOG4J2-1879 > URL: https://issues.apache.org/jira/browse/LOG4J2-1879 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.8.2 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.9 > > > Update Jansi from 1.14 to 1.15 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1879) Update JAnsi from 1.14 to 1.15
[ https://issues.apache.org/jira/browse/LOG4J2-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-1879: - Description: Update JAnsi from 1.14 to 1.15 (was: Update Jansi from 1.14 to 1.15) > Update JAnsi from 1.14 to 1.15 > -- > > Key: LOG4J2-1879 > URL: https://issues.apache.org/jira/browse/LOG4J2-1879 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.8.2 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.9 > > > Update JAnsi from 1.14 to 1.15 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1879) Update JAnsi from 1.14 to 1.15
[ https://issues.apache.org/jira/browse/LOG4J2-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1879. Resolution: Fixed Fix Version/s: 2.9 In Git master. > Update JAnsi from 1.14 to 1.15 > -- > > Key: LOG4J2-1879 > URL: https://issues.apache.org/jira/browse/LOG4J2-1879 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.8.2 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.9 > > > Update JAnsi from 1.14 to 1.15 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1879) Update Jansi from 1.14 to 1.15
Gary Gregory created LOG4J2-1879: Summary: Update Jansi from 1.14 to 1.15 Key: LOG4J2-1879 URL: https://issues.apache.org/jira/browse/LOG4J2-1879 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.8.2 Reporter: Gary Gregory Assignee: Gary Gregory Update Jansi from 1.14 to 1.15 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1873) Implement UTF-8 encoding that doesn't use CharsetEncoder
[ https://issues.apache.org/jira/browse/LOG4J2-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15963050#comment-15963050 ] Gary Gregory commented on LOG4J2-1873: -- ICU4J might have something we can optionally depend on or copy. > Implement UTF-8 encoding that doesn't use CharsetEncoder > > > Key: LOG4J2-1873 > URL: https://issues.apache.org/jira/browse/LOG4J2-1873 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Roman Leventov > > CharsetEncoder accepts only CharBuffers, and for the sake of being entirely > garbage-free we don't want to use CharBuffer.wrap(stringBuilder), when > encoding an event. > That forces us to make additional data copy from StringBuilder to a > thread-local CharBuffer. > This could be avoided by implementing UTF-8 encoding logic in log4j-core > itself, and not using CharsetEncoder. > This issue is specifically about UTF-8 because it is used predominantly and > it's relatively easy to implement. There are also likely some open-source > Apache 2-compatible implementations in Java out there already that we could > just copy and adapt. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1864) Support capped collection for MongoDB Log-Provider
[ https://issues.apache.org/jira/browse/LOG4J2-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15963043#comment-15963043 ] Gary Gregory commented on LOG4J2-1864: -- The old factory method does not come into play if you remove its annotation, which is what I have done in the past when adding a builder. > Support capped collection for MongoDB Log-Provider > -- > > Key: LOG4J2-1864 > URL: https://issues.apache.org/jira/browse/LOG4J2-1864 > Project: Log4j 2 > Issue Type: New Feature > Components: Appenders >Reporter: Matt > > MongoDB supports sth. called capped collections. If the > nosql-mongodb-appender supports this feature, the mongodb-collection could > never "overflow" and stick to a defined maximum size. > see [pull request 62|https://github.com/apache/logging-log4j2/pull/62] for > more details. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1872) Update JavaMail from 1.5.5 to 1.5.6
[ https://issues.apache.org/jira/browse/LOG4J2-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1872. Resolution: Fixed Fix Version/s: 2.9 In Git master. > Update JavaMail from 1.5.5 to 1.5.6 > --- > > Key: LOG4J2-1872 > URL: https://issues.apache.org/jira/browse/LOG4J2-1872 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.8.2 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.9 > > > Update JavaMail from 1.5.5 to 1.5.6. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1869) Update Kafka client from 0.10.1.1 to 0.10.2.0
[ https://issues.apache.org/jira/browse/LOG4J2-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1869. Resolution: Fixed Fix Version/s: 2.9 Marking for 2.9. > Update Kafka client from 0.10.1.1 to 0.10.2.0 > - > > Key: LOG4J2-1869 > URL: https://issues.apache.org/jira/browse/LOG4J2-1869 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.8.2 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.9 > > > Update Kafka client from 0.10.1.1 to 0.10.2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Reopened] (LOG4J2-1869) Update Kafka client from 0.10.1.1 to 0.10.2.0
[ https://issues.apache.org/jira/browse/LOG4J2-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory reopened LOG4J2-1869: -- > Update Kafka client from 0.10.1.1 to 0.10.2.0 > - > > Key: LOG4J2-1869 > URL: https://issues.apache.org/jira/browse/LOG4J2-1869 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.8.2 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.9 > > > Update Kafka client from 0.10.1.1 to 0.10.2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1872) Update JavaMail from 1.5.5 to 1.5.6
Gary Gregory created LOG4J2-1872: Summary: Update JavaMail from 1.5.5 to 1.5.6 Key: LOG4J2-1872 URL: https://issues.apache.org/jira/browse/LOG4J2-1872 Project: Log4j 2 Issue Type: Bug Components: Appenders Affects Versions: 2.8.2 Reporter: Gary Gregory Assignee: Gary Gregory Update JavaMail from 1.5.5 to 1.5.6. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1869) Update Kafka client from 0.10.1.1 to 0.10.2.0
[ https://issues.apache.org/jira/browse/LOG4J2-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1869. Resolution: Fixed Assignee: Gary Gregory In Git master. > Update Kafka client from 0.10.1.1 to 0.10.2.0 > - > > Key: LOG4J2-1869 > URL: https://issues.apache.org/jira/browse/LOG4J2-1869 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.8.2 >Reporter: Gary Gregory >Assignee: Gary Gregory > > Update Kafka client from 0.10.1.1 to 0.10.2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1869) Update Kafka client from 0.10.1.1 to 0.10.2.0
Gary Gregory created LOG4J2-1869: Summary: Update Kafka client from 0.10.1.1 to 0.10.2.0 Key: LOG4J2-1869 URL: https://issues.apache.org/jira/browse/LOG4J2-1869 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.8.2 Reporter: Gary Gregory Update Kafka client from 0.10.1.1 to 0.10.2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1868) Update ZeroMQ's JeroMQ from 0.3.6 to 0.4.0
Gary Gregory created LOG4J2-1868: Summary: Update ZeroMQ's JeroMQ from 0.3.6 to 0.4.0 Key: LOG4J2-1868 URL: https://issues.apache.org/jira/browse/LOG4J2-1868 Project: Log4j 2 Issue Type: Improvement Affects Versions: 2.8.2 Reporter: Gary Gregory Update ZeroMQ's JeroMQ from 0.3.6 to 0.4.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1866) Add default value to MdcPatternConverter
[
https://issues.apache.org/jira/browse/LOG4J2-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15959186#comment-15959186
]
Gary Gregory commented on LOG4J2-1866:
--
Patches with unit tests are welcome :-)
> Add default value to MdcPatternConverter
> -
>
> Key: LOG4J2-1866
> URL: https://issues.apache.org/jira/browse/LOG4J2-1866
> Project: Log4j 2
> Issue Type: Bug
> Components: Pattern Converters
>Affects Versions: 2.8.2
>Reporter: Izek Greenfield
> Labels: converter, mdc, pattern
>
> When using %X in a pattern I can't define default value if the value does not
> exist in MDC.
> I will be great to be able to define one like:
> {code:title=pattern|borderStyle=solid}
> %X{key}{hello}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1856) Update Jackson from 2.8.6 to 2.8.7.
[ https://issues.apache.org/jira/browse/LOG4J2-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1856. Resolution: Fixed Fix Version/s: 2.8.2 In Git master. > Update Jackson from 2.8.6 to 2.8.7. > --- > > Key: LOG4J2-1856 > URL: https://issues.apache.org/jira/browse/LOG4J2-1856 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.8.1 >Reporter: Gary Gregory > Fix For: 2.8.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1856) Update Jackson from 2.8.6 to 2.8.7.
Gary Gregory created LOG4J2-1856: Summary: Update Jackson from 2.8.6 to 2.8.7. Key: LOG4J2-1856 URL: https://issues.apache.org/jira/browse/LOG4J2-1856 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.8.1 Reporter: Gary Gregory -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1071) Allow for bufferSize=0 in SMTP appender
[ https://issues.apache.org/jira/browse/LOG4J2-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942130#comment-15942130 ] Gary Gregory commented on LOG4J2-1071: -- Patches welcome :-) > Allow for bufferSize=0 in SMTP appender > --- > > Key: LOG4J2-1071 > URL: https://issues.apache.org/jira/browse/LOG4J2-1071 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.3 >Reporter: Benjamin Jaton >Priority: Minor > > From the doc: > "The number of logging events delivered in this e-mail depend on the value of > BufferSize option. The SMTPAppender keeps only the last BufferSize logging > events in its cyclic buffer. This keeps memory requirements at a reasonable > level while still delivering useful application context. All events in the > buffer are included in the email. The buffer will contain the most recent > events of level TRACE to WARN preceding the event that triggered the email." > https://logging.apache.org/log4j/2.x/manual/appenders.html#SMTPAppender > The bufferSize is the number of messages preceding the message that triggered > the event. They might be completely unrelated. One may not want to include > them in the email at all, so having a bufferSize of 0 makes sense. > This is however disallowed in the code: > Caused by: java.lang.IllegalArgumentException: The maxSize argument (0) is > not a positive integer. > at > org.apache.logging.log4j.core.util.CyclicBuffer.(CyclicBuffer.java:41) > at > org.apache.logging.log4j.core.net.SmtpManager.(SmtpManager.java:70) > at > org.apache.logging.log4j.core.net.SmtpManager$SMTPManagerFactory.createManager(SmtpManager.java:338) > at > org.apache.logging.log4j.core.net.SmtpManager$SMTPManagerFactory.createManager(SmtpManager.java:299) > at > org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:71) > at > org.apache.logging.log4j.core.net.SmtpManager.getSMTPManager(SmtpManager.java:124) > at > org.apache.logging.log4j.core.appender.SmtpAppender.createAppender(SmtpAppender.java:142) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1853) The default value of RandomAccessFileAppender.Builder append field is wrong
[ https://issues.apache.org/jira/browse/LOG4J2-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved LOG4J2-1853. -- Resolution: Fixed Fix Version/s: 2.8.2 Closes #66. Please verify and close this Jira. > The default value of RandomAccessFileAppender.Builder append field is wrong > --- > > Key: LOG4J2-1853 > URL: https://issues.apache.org/jira/browse/LOG4J2-1853 > Project: Log4j 2 > Issue Type: Bug >Reporter: wangyuntao > Fix For: 2.8.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1753) java.lang.ClassNotFoundException: org.apache.logging.log4j.core.util.ExecutorServices when running the OSGi tests
[
https://issues.apache.org/jira/browse/LOG4J2-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15900861#comment-15900861
]
Gary Gregory commented on LOG4J2-1753:
--
[~jvz] The tests pass now so that solves the reported issue. Let's see what
[~lhochet] says.
> java.lang.ClassNotFoundException:
> org.apache.logging.log4j.core.util.ExecutorServices when running the OSGi
> tests
> -
>
> Key: LOG4J2-1753
> URL: https://issues.apache.org/jira/browse/LOG4J2-1753
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Ludovic HOCHET
> Attachments: patch-log4j2-1753.diff
>
>
> When running the OSGi tests for LOG4J2-1664, a new
> java.lang.ClassNotFoundException:
> org.apache.logging.log4j.core.util.ExecutorServices (for both Felix and
> Equinox) appeared recently.
> Here is the Felix stack trace:
> {noformat}
> ERROR StatusLogger Failed to preload ExecutorServices class.
> java.lang.ClassNotFoundException: *** Class
> 'org.apache.logging.log4j.core.util.ExecutorServices' was not found because
> bundle org.apache.logging.log4j.api [1] does not import
> 'org.apache.logging.log4j.core.util' even though bundle
> org.apache.logging.log4j.core [2] does export it. To resolve this issue, add
> an import for 'org.apache.logging.log4j.core.util' to bundle
> org.apache.logging.log4j.api [1]. ***
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2011)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at
> org.apache.logging.log4j.util.LoaderUtil.loadClass(LoaderUtil.java:141)
> at
> org.apache.logging.log4j.core.LoggerContext.(LoggerContext.java:74)
> at
> org.apache.logging.log4j.core.osgi.BundleContextSelector.locateContext(BundleContextSelector.java:67)
> at
> org.apache.logging.log4j.core.osgi.BundleContextSelector.getContext(BundleContextSelector.java:53)
> at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:57)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:147)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.logging.log4j.osgi.tests.AbstractLoadBundleTest.log(AbstractLoadBundleTest.java:100)
> at
> org.apache.logging.log4j.osgi.tests.AbstractLoadBundleTest.testSimpleLogInAnOsgiContext(AbstractLoadBundleTest.java:279)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
>
[jira] [Closed] (LOG4J2-1804) Rolling file %i based rolling broken in 2.8
[
https://issues.apache.org/jira/browse/LOG4J2-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LOG4J2-1804.
Closing as fixed in 2.8.1.
> Rolling file %i based rolling broken in 2.8
> ---
>
> Key: LOG4J2-1804
> URL: https://issues.apache.org/jira/browse/LOG4J2-1804
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.8
>Reporter: Brendan Miller
>Assignee: Ralph Goers
> Fix For: 2.8.1
>
> Attachments: LOG4J2-1804.junit.and.fix.patch, LOG4J2-1804.junit.patch
>
>
> Log files do not seem to be rolling up to the max number of files as
> specified in DefaultRolloverStrategy while utilizing a
> SizeBasedTriggeringPolicy. It is just rolling just to 1 file.
> Simple repro:
> log4j2.xml
> {code}
>
>
>
> fileName="__logs__/rolling.log"
> filePattern="__logs__/rolling.log.%i"
> immediateFlush="true">
>
>
>
>
>
>
>
>
>
>
>
> {code}
> MyApp.scala:
> {code}
> import scala.util.Random
> import org.apache.logging.log4j.LogManager
> object MyApp extends App {
> val log = LogManager.getLogger(this.getClass)
> var counter = 0L
> var bytes = new Array[Byte](1000)
> while (true) {
> Random.nextBytes(bytes)
> log.info(f"Log statement: $counter%08x ${bytes.mkString}")
> counter += 1
> Thread.sleep(5)
> }
> }
> {code}
> If you run that against 2.7, things roll fine. If you run that against 2.8,
> you'll only see rolling.log & rolling.log.1 in the __logs__ folder.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1834) Handle when LogEvent.getLoggerName() returns null properly
[
https://issues.apache.org/jira/browse/LOG4J2-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894007#comment-15894007
]
Gary Gregory commented on LOG4J2-1834:
--
Not sure, the Javadoc for the method says {{null}} is an expected value though.
> Handle when LogEvent.getLoggerName() returns null properly
> --
>
> Key: LOG4J2-1834
> URL: https://issues.apache.org/jira/browse/LOG4J2-1834
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.8.1
>Reporter: Mikael Ståldal
>
> * KafkaAppender
> * LoggerNameLevelRewritePolicy
> * LoggerPatternConverter
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1820) Log4j 2.8 can lose exceptions when a security manager is present
[ https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15891505#comment-15891505 ] Gary Gregory commented on LOG4J2-1820: -- The bottom line is that we use GitHub as a read-only mirror for now as most Apache projects do. If there is some git command line incantation to use with the patch URL, please do post it here so we can document this someplace. > Log4j 2.8 can lose exceptions when a security manager is present > > > Key: LOG4J2-1820 > URL: https://issues.apache.org/jira/browse/LOG4J2-1820 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Jason Tedor >Assignee: Gary Gregory > Fix For: 2.8.2 > > Attachments: > 0001-Handle-security-exception-on-getting-class-loader.patch, > 0002-Handle-security-exception-on-getting-class-loader.patch > > > When Log4j is rendering an exception, it can attempt to access a class loader > that it does not have permissions to access when a security manager is > present. > I have a patch and a failing test case for this; I will submit it shortly. > This is similar to LOG4J2-1560. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1820) Log4j 2.8 can lose exceptions when a security manager is present
[ https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15891172#comment-15891172 ] Gary Gregory commented on LOG4J2-1820: -- Yes, I just got the patch from the URL, copied it to the clipboard and applied the patch in Eclipse (EGit). > Log4j 2.8 can lose exceptions when a security manager is present > > > Key: LOG4J2-1820 > URL: https://issues.apache.org/jira/browse/LOG4J2-1820 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Jason Tedor >Assignee: Gary Gregory > Fix For: 2.8.2 > > Attachments: > 0001-Handle-security-exception-on-getting-class-loader.patch, > 0002-Handle-security-exception-on-getting-class-loader.patch > > > When Log4j is rendering an exception, it can attempt to access a class loader > that it does not have permissions to access when a security manager is > present. > I have a patch and a failing test case for this; I will submit it shortly. > This is similar to LOG4J2-1560. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1820) Log4j 2.8 can lose exceptions when a security manager is present
[ https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved LOG4J2-1820. -- Resolution: Fixed Assignee: Gary Gregory Fix Version/s: 2.8.2 Please verify and close. > Log4j 2.8 can lose exceptions when a security manager is present > > > Key: LOG4J2-1820 > URL: https://issues.apache.org/jira/browse/LOG4J2-1820 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Jason Tedor >Assignee: Gary Gregory > Fix For: 2.8.2 > > Attachments: > 0001-Handle-security-exception-on-getting-class-loader.patch, > 0002-Handle-security-exception-on-getting-class-loader.patch > > > When Log4j is rendering an exception, it can attempt to access a class loader > that it does not have permissions to access when a security manager is > present. > I have a patch and a failing test case for this; I will submit it shortly. > This is similar to LOG4J2-1560. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1831) NullPointerException in HtmlLayout
[
https://issues.apache.org/jira/browse/LOG4J2-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15890872#comment-15890872
]
Gary Gregory commented on LOG4J2-1831:
--
I can see the problem and it's simple to fix. There might be other places in
log4j in general where
{{org.apache.logging.log4j.core.LogEvent.getLoggerName()}} returns {{null}} and
causes problems.
> NullPointerException in HtmlLayout
> --
>
> Key: LOG4J2-1831
> URL: https://issues.apache.org/jira/browse/LOG4J2-1831
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.8
>Reporter: Edward Serebrinskiy
> Fix For: 2.8.2
>
>
> Got following NullPointerException by using SMTP appender.
> {code}
> AsyncLogger error handling event seq=233, value='[ERROR calling class
> org.apache.logging.log4j.core.async.RingBufferLogEvent.toString():
> java.lang.NullPointerException]':
> org.apache.logging.log4j.core.appender.AppenderLoggingException: An exception
> occurred processing Appender Mail
> at
> org.apache.logging.log4j.core.appender.DefaultErrorHandler.error(DefaultErrorHandler.java:75)
> at
> org.apache.logging.log4j.core.config.AppenderControl.handleAppenderError(AppenderControl.java:165)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:158)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:448)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:433)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:417)
> at
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:79)
> at
> org.apache.logging.log4j.core.async.AsyncLogger.actualAsyncLog(AsyncLogger.java:337)
> at
> org.apache.logging.log4j.core.async.RingBufferLogEvent.execute(RingBufferLogEvent.java:156)
> at
> org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:45)
> at
> org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:29)
> at
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:129)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.logging.log4j.LoggingException: Error occurred while
> sending email
> at
> org.apache.logging.log4j.core.net.SmtpManager.sendEvents(SmtpManager.java:175)
> at
> org.apache.logging.log4j.core.appender.SmtpAppender.append(SmtpAppender.java:181)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> ... 15 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.logging.log4j.core.layout.HtmlLayout.toSerializable(HtmlLayout.java:170)
> at
> org.apache.logging.log4j.core.layout.HtmlLayout.toSerializable(HtmlLayout.java:50)
> at
> org.apache.logging.log4j.core.layout.AbstractStringLayout.toByteArray(AbstractStringLayout.java:301)
> at
> org.apache.logging.log4j.core.net.SmtpManager.writeBuffer(SmtpManager.java:204)
> at
> org.apache.logging.log4j.core.net.SmtpManager.writeContent(SmtpManager.java:190)
> at
> org.apache.logging.log4j.core.net.SmtpManager.formatContentToBytes(SmtpManager.java:182)
> at
> org.apache.logging.log4j.core.net.SmtpManager.sendEvents(SmtpManager.java:163)
> ... 17 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1831) NullPointerException in HtmlLayout
[
https://issues.apache.org/jira/browse/LOG4J2-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-1831.
--
Resolution: Fixed
Assignee: Gary Gregory
Fix Version/s: 2.8.2
Please verify and close.
> NullPointerException in HtmlLayout
> --
>
> Key: LOG4J2-1831
> URL: https://issues.apache.org/jira/browse/LOG4J2-1831
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.8
>Reporter: Edward Serebrinskiy
>Assignee: Gary Gregory
> Fix For: 2.8.2
>
>
> Got following NullPointerException by using SMTP appender.
> {code}
> AsyncLogger error handling event seq=233, value='[ERROR calling class
> org.apache.logging.log4j.core.async.RingBufferLogEvent.toString():
> java.lang.NullPointerException]':
> org.apache.logging.log4j.core.appender.AppenderLoggingException: An exception
> occurred processing Appender Mail
> at
> org.apache.logging.log4j.core.appender.DefaultErrorHandler.error(DefaultErrorHandler.java:75)
> at
> org.apache.logging.log4j.core.config.AppenderControl.handleAppenderError(AppenderControl.java:165)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:158)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:448)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:433)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:417)
> at
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:79)
> at
> org.apache.logging.log4j.core.async.AsyncLogger.actualAsyncLog(AsyncLogger.java:337)
> at
> org.apache.logging.log4j.core.async.RingBufferLogEvent.execute(RingBufferLogEvent.java:156)
> at
> org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:45)
> at
> org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:29)
> at
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:129)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.logging.log4j.LoggingException: Error occurred while
> sending email
> at
> org.apache.logging.log4j.core.net.SmtpManager.sendEvents(SmtpManager.java:175)
> at
> org.apache.logging.log4j.core.appender.SmtpAppender.append(SmtpAppender.java:181)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> ... 15 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.logging.log4j.core.layout.HtmlLayout.toSerializable(HtmlLayout.java:170)
> at
> org.apache.logging.log4j.core.layout.HtmlLayout.toSerializable(HtmlLayout.java:50)
> at
> org.apache.logging.log4j.core.layout.AbstractStringLayout.toByteArray(AbstractStringLayout.java:301)
> at
> org.apache.logging.log4j.core.net.SmtpManager.writeBuffer(SmtpManager.java:204)
> at
> org.apache.logging.log4j.core.net.SmtpManager.writeContent(SmtpManager.java:190)
> at
> org.apache.logging.log4j.core.net.SmtpManager.formatContentToBytes(SmtpManager.java:182)
> at
> org.apache.logging.log4j.core.net.SmtpManager.sendEvents(SmtpManager.java:163)
> ... 17 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1828) add support for prudent mode in Log4j 2
[ https://issues.apache.org/jira/browse/LOG4J2-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15888682#comment-15888682 ] Gary Gregory commented on LOG4J2-1828: -- Is this just having a "lock" mode on/off? > add support for prudent mode in Log4j 2 > --- > > Key: LOG4J2-1828 > URL: https://issues.apache.org/jira/browse/LOG4J2-1828 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Erik Weathers >Priority: Minor > > As discussed in LOG4J2-174, there is a feature from logback called ["prudent > mode"|https://logback.qos.ch/manual/appenders.html#prudent] which is not > available in Log4j 2. This feature allows multiple JVMs to write to the same > log file at the same time, albeit with a [few > restrictions|https://logback.qos.ch/manual/appenders.html#prudentWithRolling]. > Please see LOG4J2-174 for a discussion on some alternative approaches you > might consider if you want prudent mode but this ticket isn't yet fixed in > the version of Log4j 2 you are using. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.toImmutable()
[
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884304#comment-15884304
]
Gary Gregory commented on LOG4J2-1807:
--
Sounds reasonable.
> [core] Add and implement LogEvent.toImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
> Issue Type: New Feature
>Affects Versions: 2.8.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
> * Returns an immutable version of this log event, which MAY BE a copy of
> this event.
> *
> * @return an immutable version of this log event
> */
> LogEvent asImmutable();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1820) Log4j 2.8 can lose exceptions when a security manager is present
[ https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15883407#comment-15883407 ] Gary Gregory commented on LOG4J2-1820: -- When I apply the patch I get this failure: Tests in error: ThrowableProxyTest.testLogStackTraceWithClassLoaderThatWithCauseSecurityException:179 ╗ NoSuchAlgorithm I ran: mvn clean install -pl !log4j-nosql I am on Windows and Java 7: Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) Maven home: C:\Java\apache-maven-3.3.9\bin\.. Java version: 1.7.0_80, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_80\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows" > Log4j 2.8 can lose exceptions when a security manager is present > > > Key: LOG4J2-1820 > URL: https://issues.apache.org/jira/browse/LOG4J2-1820 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Jason Tedor > Attachments: > 0001-Handle-security-exception-on-getting-class-loader.patch > > > When Log4j is rendering an exception, it can attempt to access a class loader > that it does not have permissions to access when a security manager is > present. > I have a patch and a failing test case for this; I will submit it shortly. > This is similar to LOG4J2-1560. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1820) Log4j 2.8 can lose exceptions when a security manager is present
[ https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15879767#comment-15879767 ] Gary Gregory commented on LOG4J2-1820: -- [~jvz]: Do you feel we have consensus that [~jasontedor]'s patch is OK? > Log4j 2.8 can lose exceptions when a security manager is present > > > Key: LOG4J2-1820 > URL: https://issues.apache.org/jira/browse/LOG4J2-1820 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Jason Tedor > Attachments: > 0001-Handle-security-exception-on-getting-class-loader.patch > > > When Log4j is rendering an exception, it can attempt to access a class loader > that it does not have permissions to access when a security manager is > present. > I have a patch and a failing test case for this; I will submit it shortly. > This is similar to LOG4J2-1560. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1820) Log4j 2.8 can lose exceptions when a security manager is present
[ https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877459#comment-15877459 ] Gary Gregory commented on LOG4J2-1820: -- More generally, how can we parameterize the unit tests to run a second time (optionally I suppose) with a security manager? It seems like we need something more than a JUnit Rule. > Log4j 2.8 can lose exceptions when a security manager is present > > > Key: LOG4J2-1820 > URL: https://issues.apache.org/jira/browse/LOG4J2-1820 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Jason Tedor > Attachments: > 0001-Handle-security-exception-on-getting-class-loader.patch > > > When Log4j is rendering an exception, it can attempt to access a class loader > that it does not have permissions to access when a security manager is > present. > I have a patch and a failing test case for this; I will submit it shortly. > This is similar to LOG4J2-1560. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1820) Log4j 2.8 can lose exceptions when a security manager is present
[
https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877457#comment-15877457
]
Gary Gregory commented on LOG4J2-1820:
--
Hi All,
It seems that we do not need to worry about cases like
{{org.apache.logging.log4j.core.config.xml.XmlConfiguration.XmlConfiguration(LoggerContext,
ConfigurationSource):152}}
But what about
{{org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(String,
ClassLoader, boolean, URI):74}}, should that go through LoaderUtils or be in a
try/catch?
Could
{{org.apache.logging.log4j.web.Log4jWebInitializerImpl.initializeJndi(String)}}
be trouble then?
Gary
> Log4j 2.8 can lose exceptions when a security manager is present
>
>
> Key: LOG4J2-1820
> URL: https://issues.apache.org/jira/browse/LOG4J2-1820
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Jason Tedor
> Attachments:
> 0001-Handle-security-exception-on-getting-class-loader.patch
>
>
> When Log4j is rendering an exception, it can attempt to access a class loader
> that it does not have permissions to access when a security manager is
> present.
> I have a patch and a failing test case for this; I will submit it shortly.
> This is similar to LOG4J2-1560.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1820) Log4j 2.8 can lose exceptions when a security manager is present
[
https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877426#comment-15877426
]
Gary Gregory commented on LOG4J2-1820:
--
What about the other 31 call sites we have to {{Class.getClassLoader()}}?
Wouldn't these need special care as well? Should the try/catch be abstracted in
a utility method?
> Log4j 2.8 can lose exceptions when a security manager is present
>
>
> Key: LOG4J2-1820
> URL: https://issues.apache.org/jira/browse/LOG4J2-1820
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Jason Tedor
> Attachments:
> 0001-Handle-security-exception-on-getting-class-loader.patch
>
>
> When Log4j is rendering an exception, it can attempt to access a class loader
> that it does not have permissions to access when a security manager is
> present.
> I have a patch and a failing test case for this; I will submit it shortly.
> This is similar to LOG4J2-1560.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-1820) Log4j 2.8 can lose exceptions when a security manager is present
[
https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877426#comment-15877426
]
Gary Gregory edited comment on LOG4J2-1820 at 2/22/17 3:53 AM:
---
What about the other 31 call sites we have to {{Class.getClassLoader()}}?
Wouldn't these need special care as well? Should the try/catch be abstracted in
a utility method? (I'm not separating test from main in the 31 count, it's just
what Eclipse reports.)
was (Author: garydgregory):
What about the other 31 call sites we have to {{Class.getClassLoader()}}?
Wouldn't these need special care as well? Should the try/catch be abstracted in
a utility method?
> Log4j 2.8 can lose exceptions when a security manager is present
>
>
> Key: LOG4J2-1820
> URL: https://issues.apache.org/jira/browse/LOG4J2-1820
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Jason Tedor
> Attachments:
> 0001-Handle-security-exception-on-getting-class-loader.patch
>
>
> When Log4j is rendering an exception, it can attempt to access a class loader
> that it does not have permissions to access when a security manager is
> present.
> I have a patch and a failing test case for this; I will submit it shortly.
> This is similar to LOG4J2-1560.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1820) Log4j 2.8 can lose exceptions when a security manager is present
[ https://issues.apache.org/jira/browse/LOG4J2-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15877130#comment-15877130 ] Gary Gregory commented on LOG4J2-1820: -- I'll try to take a look tonight, Does a full build pass? Like 'mvn clean install'? > Log4j 2.8 can lose exceptions when a security manager is present > > > Key: LOG4J2-1820 > URL: https://issues.apache.org/jira/browse/LOG4J2-1820 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Jason Tedor > Attachments: > 0001-Handle-security-exception-on-getting-class-loader.patch > > > When Log4j is rendering an exception, it can attempt to access a class loader > that it does not have permissions to access when a security manager is > present. > I have a patch and a failing test case for this; I will submit it shortly. > This is similar to LOG4J2-1560. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-548) Log4j 2.0 with JBoss EAP 6.2
[ https://issues.apache.org/jira/browse/LOG4J2-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872725#comment-15872725 ] Gary Gregory commented on LOG4J2-548: - Thank you for your patch Eric. Did you try a full build to make sure all the unit tests pass? 'mvn clean install' Thank you, Gary > Log4j 2.0 with JBoss EAP 6.2 > - > > Key: LOG4J2-548 > URL: https://issues.apache.org/jira/browse/LOG4J2-548 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.0-rc1, 2.1 > Environment: EJB 3.1 , JBoss EAP 6.2 , Windows 7 , Eclipse Kepler >Reporter: Shehata >Assignee: Ralph Goers > Attachments: LOG4J2-548 - evictors.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > When trying to use log4j 2.0-rc1 with EJB3.1 i got Error Message: > "ERROR StatusLogger Could not search jar file > 'jboss-eap-6.2\standalone\deployments\Log4J2Ear.ear\lib\log4j-core-2.0-rc1.jar\org\apache\logging\log4j\core' > for classes matching criteria: annotated with @Plugin file not found" > after debugging the application found that the problem is located in : > org.apache.logging.log4j.core.config.plugins.ResolverUtil > method: findInPackage --> line number 247 > the protocol used in the jar is vfs not vfszip -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.toImmutable()
[
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872252#comment-15872252
]
Gary Gregory commented on LOG4J2-1807:
--
I agree that it is not perfect. What do you suggest?
> [core] Add and implement LogEvent.toImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
> Issue Type: New Feature
>Affects Versions: 2.8.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
> * Returns an immutable version of this log event, which MAY BE a copy of
> this event.
> *
> * @return an immutable version of this log event
> */
> LogEvent asImmutable();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1819) Update Jackson from 2.8.5 to 2.8.6
[ https://issues.apache.org/jira/browse/LOG4J2-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1819. Resolution: Fixed In Git master. > Update Jackson from 2.8.5 to 2.8.6 > -- > > Key: LOG4J2-1819 > URL: https://issues.apache.org/jira/browse/LOG4J2-1819 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.8 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.8.1 > > > Update Jackson from 2.8.5 to 2.8.6. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Reopened] (LOG4J2-1819) Update Jackson from 2.8.5 to 2.8.6
[ https://issues.apache.org/jira/browse/LOG4J2-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory reopened LOG4J2-1819: -- > Update Jackson from 2.8.5 to 2.8.6 > -- > > Key: LOG4J2-1819 > URL: https://issues.apache.org/jira/browse/LOG4J2-1819 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.8 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.8.1 > > > Update Jackson from 2.8.5 to 2.8.6. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1819) Update Jackson from 2.8.5 to 2.8.6
[ https://issues.apache.org/jira/browse/LOG4J2-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-1819: - Affects Version/s: (was: 2.7) 2.8 > Update Jackson from 2.8.5 to 2.8.6 > -- > > Key: LOG4J2-1819 > URL: https://issues.apache.org/jira/browse/LOG4J2-1819 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.8 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.8.1 > > > Update Jackson from 2.8.5 to 2.8.6. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1819) Update Jackson from 2.8.5 to 2.8.6
[ https://issues.apache.org/jira/browse/LOG4J2-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1819. Resolution: Fixed Fix Version/s: 2.8.1 > Update Jackson from 2.8.5 to 2.8.6 > -- > > Key: LOG4J2-1819 > URL: https://issues.apache.org/jira/browse/LOG4J2-1819 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.8 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.8.1 > > > Update Jackson from 2.8.5 to 2.8.6. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1819) Update Jackson from 2.8.5 to 2.8.6
Gary Gregory created LOG4J2-1819: Summary: Update Jackson from 2.8.5 to 2.8.6 Key: LOG4J2-1819 URL: https://issues.apache.org/jira/browse/LOG4J2-1819 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.7 Reporter: Gary Gregory Assignee: Gary Gregory Update Jackson from 2.8.5 to 2.8.6. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1807) [core] Add and implement LogEvent.toImmutable()
[
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-1807.
--
Resolution: Fixed
In git master.
[~rem...@yahoo.com], would you care to review?
Gary
> [core] Add and implement LogEvent.toImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
> Issue Type: New Feature
>Affects Versions: 2.8.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
> * Returns an immutable version of this log event, which MAY BE a copy of
> this event.
> *
> * @return an immutable version of this log event
> */
> LogEvent asImmutable();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1807) [core] Add and implement LogEvent.toImmutable()
[
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-1807:
-
Affects Version/s: 2.8.1
> [core] Add and implement LogEvent.toImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
> Issue Type: New Feature
>Affects Versions: 2.8.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
> * Returns an immutable version of this log event, which MAY BE a copy of
> this event.
> *
> * @return an immutable version of this log event
> */
> LogEvent asImmutable();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1818) Fix rollover to work when filePattern contains no directory components
[
https://issues.apache.org/jira/browse/LOG4J2-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-1818.
--
Resolution: Fixed
Fix Version/s: 2.8.1
Fixed in Git master.
> Fix rollover to work when filePattern contains no directory components
> --
>
> Key: LOG4J2-1818
> URL: https://issues.apache.org/jira/browse/LOG4J2-1818
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.8
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.8.1
>
>
> See https://github.com/apache/logging-log4j2/pull/59
> Prior to this patch, the following config threw NPE at parent.mkdirs()
> because parent was null when using e.g.:
> {code:xml}
> fileName="foo.log"
> filePattern="foo-%d{-MM-dd}-%i.log.gz"
> immediateFlush="false">
> {code}
> while this config did not:
> {code:xml}
> fileName="foo.log"
> filePattern="./foo-%d{-MM-dd}-%i.log.gz"
> immediateFlush="false">
> {code}
> e.g. by adding ./ in front of the filePattern value.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1818) Fix rollover to work when filePattern contains no directory components
Gary Gregory created LOG4J2-1818:
Summary: Fix rollover to work when filePattern contains no
directory components
Key: LOG4J2-1818
URL: https://issues.apache.org/jira/browse/LOG4J2-1818
Project: Log4j 2
Issue Type: Bug
Components: Appenders
Affects Versions: 2.8
Reporter: Gary Gregory
Assignee: Gary Gregory
See https://github.com/apache/logging-log4j2/pull/59
Prior to this patch, the following config threw NPE at parent.mkdirs() because
parent was null when using e.g.:
{code:xml}
{code}
while this config did not:
{code:xml}
{code}
e.g. by adding ./ in front of the filePattern value.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1814) Wrapper Generate$ExtendedLogger name inconvenient on Linux
[
https://issues.apache.org/jira/browse/LOG4J2-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865090#comment-15865090
]
Gary Gregory commented on LOG4J2-1814:
--
Can we just cut to the chase and give the class a decent name, maybe
{{ExtendedLoggerGenerator}}? It could just turn around and call
{{Generate$ExtendedLogger}} if the design for that is all good.
> Wrapper Generate$ExtendedLogger name inconvenient on Linux
> ---
>
> Key: LOG4J2-1814
> URL: https://issues.apache.org/jira/browse/LOG4J2-1814
> Project: Log4j 2
> Issue Type: Improvement
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> The $ExtendedLogger is interpreted as an environment variable.
> {code}
> $ java -cp log4j-core-2.8.jar
> org.apache.logging.log4j.core.tools.Generate$ExtendedLogger \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> com/mycomp/ExtLogger.java
> Error: Main method not found in class
> org.apache.logging.log4j.core.tools.Generate, please define the main method
> {code}
> The workaround is to quote the class name:
> {code}
> $ java -cp log4j-core-2.8.jar
> "org.apache.logging.log4j.core.tools.Generate$ExtendedLogger" \
> com.mycomp.ExtLogger DIAG=350 NOTICE=450 VERBOSE=550 >
> com/mycomp/ExtLogger.java
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1813) Provide shorter and more intuitive way to switch on Log4j internal debug logging
[
https://issues.apache.org/jira/browse/LOG4J2-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15863148#comment-15863148
]
Gary Gregory commented on LOG4J2-1813:
--
Yeah, the "EBUG" is not pretty.
I had a question about this topic recently from a co-worker who was baffled by
our crazy long property name instead of a Log4j 1-like "log4j2.debug"
> Provide shorter and more intuitive way to switch on Log4j internal debug
> logging
>
>
> Key: LOG4J2-1813
> URL: https://issues.apache.org/jira/browse/LOG4J2-1813
> Project: Log4j 2
> Issue Type: Improvement
> Components: Configurators
>Affects Versions: 2.8
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> People find it difficult to troubleshoot Log4j 2 configuration issues. Many
> people don't know what the "status" attribute is for at the beginning of the
> configuration:
> {code}
> ...
> {code}
> In addition, the above setting does not take effect until the configuration
> file is found. If users have trouble making Log4j 2 find their configuration
> file, the above does not help.
> In such cases, users can enable internal status logging by setting system
> property {{org.apache.logging.log4j.simplelog.StatusLogger.level}} to
> {{TRACE}}.
> This is problematic because:
> * It is not well-known (documented in the FAQ and on the configuration page
> but many people don't know about this feature)
> * The name is a bit... lengthy :-)
> * Apparently people don't intuitively grasp that "status logging" means the
> internal log4j 2 debug logging facility.
> * It is confusing that there are two phases (before config file found and
> after), and the status logger level can be different and needs to be
> specified separately
> I propose we add a short, intuitive system property that results in _all_
> internal Log4j 2 status logging to be printed to the console. When set, this
> property should even override the configuration status attribute in my
> opinion.
> Something like {{-Dlog4j2.debug}} (without even requiring a value) would be
> good, but I'm open to any suggestions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1809) Add global configuration environment SPI
[ https://issues.apache.org/jira/browse/LOG4J2-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853316#comment-15853316 ] Gary Gregory commented on LOG4J2-1809: -- It seems we are entering Apache Commons Configuration territory here. Should we have a bridge to it? > Add global configuration environment SPI > > > Key: LOG4J2-1809 > URL: https://issues.apache.org/jira/browse/LOG4J2-1809 > Project: Log4j 2 > Issue Type: New Feature > Components: API >Reporter: Matt Sicker >Assignee: Matt Sicker > > Create a service provider interface for global configuration property > sources. Currently, we support two built in sources: properties loaded from a > classpath resource file named "log4j2.component.properties" and from system > properties. This feature will abstract those two sources into an SPI with > default implementations of those two sources as well as environment variables. > This SPI should be specified through the standard > [ServiceLoader|https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html] > API so as to make this simpler to support for users in any environment. > Related to LOG4J2-1431. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1807) [core] Add and implement LogEvent.toImmutable()
[
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-1807:
-
Summary: [core] Add and implement LogEvent.toImmutable() (was: [core] Add
and implement LogEvent.asImmutable())
> [core] Add and implement LogEvent.toImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
> * Returns an immutable version of this log event, which MAY BE a copy of
> this event.
> *
> * @return an immutable version of this log event
> */
> LogEvent asImmutable();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1807) [core] Add and implement LogEvent.asImmutable()
[
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-1807:
-
Attachment: logging-log4j2.patch
> [core] Add and implement LogEvent.asImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: logging-log4j2.patch
>
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
> * Returns an immutable version of this log event, which MAY BE a copy of
> this event.
> *
> * @return an immutable version of this log event
> */
> LogEvent asImmutable();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1807) [core] Add and implement LogEvent.asImmutable()
[
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850806#comment-15850806
]
Gary Gregory commented on LOG4J2-1807:
--
Sure, we can do {{toImmutable()}}.
Are we ok with adding a method to the Core LogEvent interface?
I have a patch coming today.
> [core] Add and implement LogEvent.asImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
> * Returns an immutable version of this log event, which MAY BE a copy of
> this event.
> *
> * @return an immutable version of this log event
> */
> LogEvent asImmutable();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1807) [core] Add and implement LogEvent.asImmutable()
[
https://issues.apache.org/jira/browse/LOG4J2-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-1807:
-
Description:
[core] Add and implement LogEvent.asImmutable()
{code:java}
/**
* Returns an immutable version of this log event, which MAY BE a copy of
this event.
*
* @return an immutable version of this log event
*/
LogEvent asImmutable();
{code}
was:
[core] Add and implement LogEvent.asImmutable()
{code:java}
/**
* Returns an immutable version of this log event, which MAY BE a copy if
this event.
*
* @return an immutable version of this log event
*/
LogEvent asImmutable();
{code}
> [core] Add and implement LogEvent.asImmutable()
> ---
>
> Key: LOG4J2-1807
> URL: https://issues.apache.org/jira/browse/LOG4J2-1807
> Project: Log4j 2
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> [core] Add and implement LogEvent.asImmutable()
> {code:java}
> /**
> * Returns an immutable version of this log event, which MAY BE a copy of
> this event.
> *
> * @return an immutable version of this log event
> */
> LogEvent asImmutable();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1807) [core] Add and implement LogEvent.asImmutable()
Gary Gregory created LOG4J2-1807:
Summary: [core] Add and implement LogEvent.asImmutable()
Key: LOG4J2-1807
URL: https://issues.apache.org/jira/browse/LOG4J2-1807
Project: Log4j 2
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
[core] Add and implement LogEvent.asImmutable()
{code:java}
/**
* Returns an immutable version of this log event, which MAY BE a copy if
this event.
*
* @return an immutable version of this log event
*/
LogEvent asImmutable();
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] (LOG4J2-1431) Simplify log4j system property naming scheme
Title: Message Title Gary Gregory commented on LOG4J2-1431 Re: Simplify log4j system property naming scheme I like simplification and consistency Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
[jira] [Commented] (LOG4J2-1780) LoggerContext does not shut down old executor services when creating new ones during reconfiguration
[
https://issues.apache.org/jira/browse/LOG4J2-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15819340#comment-15819340
]
Gary Gregory commented on LOG4J2-1780:
--
Maybe the {{ConfigurationScheduler}} is misnamed because in my noggin, it does
not sound right that the "RollingFileManager should use the
ConfigurationScheduler to run the compression task."; that sounds like reuse
for convenience, not by design; a round hole/square peg deal.
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration
>
>
> Key: LOG4J2-1780
> URL: https://issues.apache.org/jira/browse/LOG4J2-1780
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
>Reporter: Mikael Ståldal
>
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration in {{LoggerContext.setConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816578#comment-15816578
]
Gary Gregory commented on LOG4J2-1748:
--
Yep, IIRC, that is why I did it that way.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
>Assignee: Remko Popma
> Labels: RollingFile, bug
> Fix For: 2.8
>
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncLoggerRingBuffer'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=Loggers,name=*,subtype=RingBuffer'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Stopping
> XmlConfiguration[location=C:\Users\danidemi\workspace\bug-log4j2-hanging-up-before-shutdown\target\classes\log4j2.xml]...
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE XmlConfiguration notified 3
>
[jira] [Commented] (LOG4J2-1780) LoggerContext does not shut down old executor services when creating new ones during reconfiguration
[
https://issues.apache.org/jira/browse/LOG4J2-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15816238#comment-15816238
]
Gary Gregory commented on LOG4J2-1780:
--
What I think we need to consider here is if reconfiguring a {{LoggerContext}}
means that we should:
- stop it
- reconfigure it
- start it
The {{org.apache.logging.log4j.core.LoggerContext.stop(long, TimeUnit)}} method
stops all executors.
Right now, reconfiguring does not do that.
Callers of {{setConfiguration}} like the {{reconfigure}} methods could stop (if
needed) and start itself.
Needs more thought...
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration
>
>
> Key: LOG4J2-1780
> URL: https://issues.apache.org/jira/browse/LOG4J2-1780
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
>Reporter: Mikael Ståldal
>
> LoggerContext does not shut down old executor services when creating new ones
> during reconfiguration in {{LoggerContext.setConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1775) Add boot pom files for dependency management
[ https://issues.apache.org/jira/browse/LOG4J2-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-1775: - Summary: Add boot pom files for dependency management (was: Add starter pom files for dependency management) > Add boot pom files for dependency management > > > Key: LOG4J2-1775 > URL: https://issues.apache.org/jira/browse/LOG4J2-1775 > Project: Log4j 2 > Issue Type: Epic > Components: Boot, Documentation, Plugins >Reporter: Matt Sicker > Labels: build, documentation, features, maven, test > > Create what is essentially Log4j Boot for adding necessary dependencies to > support the various plugins while at the same time promoting the use of > log4j-api as a general purpose logging API standard. These modules would > categorise all the various natural dependency barriers for a sort of pseudo > module system that could also help in any necessary module metadata needed to > support Java 9 and OSGi, categorise integration style unit tests to help test > the starters themselves in an automated way, and organise the site in such a > way as to make it easier to integrate different git repositories as we > modularise the core in general. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1768) MDC.clear() is broken in Log4j-1_2-api = 2.4
[ https://issues.apache.org/jira/browse/LOG4J2-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15813191#comment-15813191 ] Gary Gregory commented on LOG4J2-1768: -- Please do try 2.7. Gary > MDC.clear() is broken in Log4j-1_2-api = 2.4 > > > Key: LOG4J2-1768 > URL: https://issues.apache.org/jira/browse/LOG4J2-1768 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.4 >Reporter: A >Priority: Blocker > > MDC.clear() seems to be broken in Log4j-1_2-api = 2.4 as it is not clearing > the entries in MDC. > Though, I have not tried in higher versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1776) log4j-starter pom modules for dependency management
[
https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15813100#comment-15813100
]
Gary Gregory commented on LOG4J2-1776:
--
Would the prefix "log4j-start" also be acceptable? It's a wee bit shorter.
Gary
> log4j-starter pom modules for dependency management
> ---
>
> Key: LOG4J2-1776
> URL: https://issues.apache.org/jira/browse/LOG4J2-1776
> Project: Log4j 2
> Issue Type: New Feature
> Components: Starters
>Reporter: Matt Sicker
>
> This is the main feature for the Log4j Starter epic (LOG4J2-1775).
> {code}
> groupId: org.apache.logging.log4j.starter
> artifactId: log4j-starter-*
> {code}
> * core: just log4j-core basically
> * async (for AsyncLogger; brings in LMAX disruptor)
> * log4j-spi: log4j-slf4j-impl, log4j-jul, log4j-jcl, log4j-1.2-api
> * slf4j-spi: slf4j-impl, jcl-over-slf4j, jul-to-slf4j (same dependency set as
> spring-boot-starter-log4j2)
> * logback (for log4j-to-slf4j, slf4j-spi, logback; this helps aid migration
> to log4j-api and promotes it as a general use logging API)
> * appender-async-conversant
> * appender-async-jctools
> * appender-cassandra
> * appender-couchdb
> * appender-jms
> * appender-jpa
> * appender-kafka
> * appender-mongodb
> * appender-smtp
> * appender-zeromq
> * config-json
> * config-yaml
> * layout-csv
> * layout-jansi (for windows users and coloured log messages)
> * layout-json (unless this has been ported to not require jackson anymore?)
> * layout-xml
> * layout-yaml
> * script-groovy
> I may have missed a few, but the base set of starters should at least
> correspond to all optional dependencies in log4j-core or the addon modules.
> For the jms, jpa, and smtp (log4j-core) appenders, we could either make add
> in a default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively)
> or split those into provider-specific starters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1713) Allow for more general serialization of Log4j2 configurations
[ https://issues.apache.org/jira/browse/LOG4J2-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15802454#comment-15802454 ] Gary Gregory commented on LOG4J2-1713: -- I've not gone through your whole post but errors like "ERROR StatusLogger Unrecognized format specifier [n]" are usually due to the fact that Log4j cannot find the DAT file that is embedded in the Log4j Core jar file (log4j-core). This is probably yet another class loader issue. > Allow for more general serialization of Log4j2 configurations > - > > Key: LOG4J2-1713 > URL: https://issues.apache.org/jira/browse/LOG4J2-1713 > Project: Log4j 2 > Issue Type: New Feature > Components: Configurators >Affects Versions: 2.7 >Reporter: Steve Cohen > > We want to implement the following system: > We would like to write an external program that reads several Log4j > Configuration Files, combines the configurations, and then outputs the > combined configuration to a new Log4j configuration file. This file can then > simply be dropped on a running log4j instance on a server, and cause an > update of the running configuration. > Existing APIs do not support this use case. There is nothing that supports > the serialization to XML of a loaded configuration. There is the new > ConfigurationBuilder.writeToXml() method in 2.7, but that's on > ConfigurationBuilder, not Configuration. Nor is it possible to take a > Configuration, and get a ConfigurationBuilder from it. Another way it could > work is having some sort of ConfigurationBuilder that accepted parameters of > type Logger, Appender, etc. These would enable Loggers and Appenders and > other Log4j2 objects to be copied from an existing configuration to a new one > being built. But this doesn't exist either. One would have to drill down > into each component, extract the necessary data, and add it to a builder. > In other words (H/T to Gary Gregory) > c1 = load config from XML file 1 (but do not apply the c1 configuration) > c2 = load config from XML file 2 (but do not apply the c2 configuration) > c3 = c1 + c2 (but do not apply the c3 configuration) write c3 to disk > In case you wonder, there is actually a use case behind this: > Imagine a Servlet web-app that, depending on request parameters, invokes one > of a number of possible EJBs (they could also be non-EJB POJOs, but for the > purposes of this discussion, we assume EJBs), in order to produce a response. > This is not a shopping cart but a back end system. We do NOT wish to deploy > these into a single EAR file but want separate deployment of each component, > and each component to have a separate logging configuration, deployable at > the same time as the component. Since Log4j allows only one configuration > context per class-loader, the ideal scheme would be there can only be one > configuration file. The only way to update it non-programatically is to drop > a new configuration in the correct location. In order to produce this, we > would like the separate logging configs deployed to some directory. A > separate program would read in all of these and add the loggers and appenders > to a new master configuration which would then be written out to disk and > copied to the proper location. The usual change mechanism would then load > the new configuration. The current configuration of the running system would > always match what is in this master configuration file, which is not the case > with programmatic configuration. > Without something like this, how is it possible to run multiple EJBs out of a > web-app that are separately deployable and have separately manageable logging > configurations? > One could manually of course parse the individual files on the XML level (or > JSON, YAML, whatever), combine them, and serialize the output. But since > log4j knows its own object model better than any xml parser, it makes sense > to have this capability within log4j. > And yes, I've thought of the fact that property-name, logger-name, > appender-name collisions are possible and could cause trouble. I would be > prepared to live with real restrictions that prevent this. I don't think > there is any need to support concatenation of random config files that do not > prevent such collisions. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1649) CronTriggeringPolicy breaks awefully when using "reconfigure" of LoggerContext
[ https://issues.apache.org/jira/browse/LOG4J2-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15793533#comment-15793533 ] Gary Gregory commented on LOG4J2-1649: -- It is a good question: should a log4j shutdown wait for scheduled tasks? I think it should but I also think we could also provide a shutdownNow or shutdown(boolean noWaiting) API. I think that passing 0 for the shutdown with timeout API is the same as the semantics of a 'shutdown no waiting' API. AFK, can't look ATM. > CronTriggeringPolicy breaks awefully when using "reconfigure" of LoggerContext > -- > > Key: LOG4J2-1649 > URL: https://issues.apache.org/jira/browse/LOG4J2-1649 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Georg Friedrich >Assignee: Ralph Goers >Priority: Critical > Fix For: 2.8 > > Attachments: ConfigurationScheduler.patch, RollingFileManager.patch > > > Hi, > I've a major problem when using CronTriggeringPolicy in Spring Boot > environments. > I've tracked the problem down to Log4J2. > The following is happening: > * When the Spring context is created, getContext is called which results in > creation on the Log4J context and the cron trigger is registered as normal > * After that Spring starts a reinitialization of the LoggerSystem by calling > "reconfigure" of the LoggerContext of Log4J. > * This results in very weird behvaiour of Log4J: > ** Log4J finds the already created RollingFileManager in the "MAP" field in > the AbstractManager class. > ** As it was already available it calls the "updateData" which in result > registers the trigger again. > ** After that the "initialize" method is called on the RollingFileManager, > which again registers the trigger. (The cron trigger is now scheduled 3 > times! First time by the normal getContext initialization and two times more > by the reconfiguration) > The good thing is: As the old configuration gets destroyed, the old scheduler > is being shutdown too, but the last schedule of the first cron trigger is > called nevertheless. > So basically you get 3 cron trigger calls, where 2 of them are rescheduled. > How it should be fixed (from my point of view): > * Kill old CronTriggers from scheduling when the context gets reconfigured > * Do not call initialize for the triggering policy when the > RollingFileManager is updated as this is done afterwards nevertheless -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1761) Support for standard java queues for the async logger
[ https://issues.apache.org/jira/browse/LOG4J2-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15791734#comment-15791734 ] Gary Gregory commented on LOG4J2-1761: -- That's a lot of new code in a tricky area to consider without a single unit test. I can't see considering any of it without significant test coverage. Are you able to add unit test and your new code in a patch in unified diff format? > Support for standard java queues for the async logger > - > > Key: LOG4J2-1761 > URL: https://issues.apache.org/jira/browse/LOG4J2-1761 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Affects Versions: 2.7 >Reporter: Kim Northrop >Priority: Minor > Attachments: AsyncLogEvent.java, AsyncLoggerWithQueue.java, > AsyncLoggerWithQueueContext.java, AsyncLoggerWithQueueContextSelector.java, > QueueWrapper.java, QueueWrapperCLQ.java, QueueWrapperLBQ.java, > QueueWrapperLTQ.java > > > Please add support for standard java queues (LinkedTransferQueue, > ArrayBlockingQueue, LinkedBlockingQueue, ConcurrentLinkedQueue) to the async > logger. I will attach some classes for usage with System properties > (Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerWithQueueContextSelector, > LoggerQueue.Capacity=, LoggerQueue.Type= LinkedTransferQueue, ConcurrentLinkedQueue, LinkedBlockingQueue>). Since most > of these queues allocate new nodes for new elements I have not implemented > usage of thread locals for the log events. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1664) Improve OSGi unit tests
[ https://issues.apache.org/jira/browse/LOG4J2-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15788449#comment-15788449 ] Gary Gregory commented on LOG4J2-1664: -- Applied patch https://issues.apache.org/jira/secure/attachment/12844808/patch-log4j2-1664-4.diff Please verify and close. > Improve OSGi unit tests > --- > > Key: LOG4J2-1664 > URL: https://issues.apache.org/jira/browse/LOG4J2-1664 > Project: Log4j 2 > Issue Type: Improvement > Components: API, Core >Affects Versions: 2.7 >Reporter: Ludovic HOCHET > Fix For: 2.8 > > Attachments: patch-log4j2-1664-2.diff, patch-log4j2-1664-3.diff, > patch-log4j2-1664-4.diff > > > Following up on LOG4J2-1637, this ticket is to improve the OSGi unit tests. > Ideally they should catch issues like LOG4J2-1637, but other improvements are > welcome too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1757) Update Apache Commons Compress from 1.12 to 1.13.
[ https://issues.apache.org/jira/browse/LOG4J2-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1757. Resolution: Fixed Fix Version/s: 2.8 Closing: In Git master. > Update Apache Commons Compress from 1.12 to 1.13. > - > > Key: LOG4J2-1757 > URL: https://issues.apache.org/jira/browse/LOG4J2-1757 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.7 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.8 > > > Update Apache Commons Compress from 1.12 to 1.13. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1749) YAML configuration ignores Flume appender attribute 'type'
[
https://issues.apache.org/jira/browse/LOG4J2-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15788390#comment-15788390
]
Gary Gregory commented on LOG4J2-1749:
--
Can you please provide your proposal as a patch with a unit test?
> YAML configuration ignores Flume appender attribute 'type'
> --
>
> Key: LOG4J2-1749
> URL: https://issues.apache.org/jira/browse/LOG4J2-1749
> Project: Log4j 2
> Issue Type: Bug
> Components: Core, Flume Appender
>Affects Versions: 2.7
>Reporter: Jerry Meng
>
> I try to setup the Flume appender with type 'Persistent'
> {code}
> Flume:
> name: foo
> type: Persistent
> compress: false
> ...
> {code}
> However, debug log always tells my FlumeAppender[type="null"...]
> After tracking the code, I found at JsonConfiguration#processAttributes
> line:237 (the super class of YamlConfiguration).
> {code}
> ...
> if (!entry.getKey().equalsIgnoreCase("type")) {
> final JsonNode n = entry.getValue();
> if (n.isValueNode()) {
> attrs.put(entry.getKey(), n.asText());
> }
> }
> ..
> {code}
> While invoking processAttributes, the attribute 'type' will be filtered out.
> I haven't dug out the reason and in what case the attribute 'type' needs to
> be filtered out, but I think this might accidentally mass up appenders'
> configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1757) Update Apache Commons Compress from 1.12 to 1.13.
Gary Gregory created LOG4J2-1757: Summary: Update Apache Commons Compress from 1.12 to 1.13. Key: LOG4J2-1757 URL: https://issues.apache.org/jira/browse/LOG4J2-1757 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.7 Reporter: Gary Gregory Assignee: Gary Gregory Update Apache Commons Compress from 1.12 to 1.13. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1756) Adds xmlns in schema and some other tags
[ https://issues.apache.org/jira/browse/LOG4J2-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1756. Resolution: Fixed Fix Version/s: 2.8 In Git master. Closes #53. > Adds xmlns in schema and some other tags > - > > Key: LOG4J2-1756 > URL: https://issues.apache.org/jira/browse/LOG4J2-1756 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.7 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.8 > > > Adds xmlns in schema and some tags. See > https://github.com/apache/logging-log4j2/pull/53 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1756) Adds xmlns in schema and some other tags
Gary Gregory created LOG4J2-1756: Summary: Adds xmlns in schema and some other tags Key: LOG4J2-1756 URL: https://issues.apache.org/jira/browse/LOG4J2-1756 Project: Log4j 2 Issue Type: Bug Components: Core Affects Versions: 2.7 Reporter: Gary Gregory Assignee: Gary Gregory Adds xmlns in schema and some tags. See https://github.com/apache/logging-log4j2/pull/53 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15777636#comment-15777636
]
Gary Gregory commented on LOG4J2-1748:
--
I do not think we should change the thread pool type to daemon, that would be
too dangerous. How about making the KAT configurable with possibly a short
default KAT?
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
> Labels: RollingFile, bug
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncLoggerRingBuffer'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=Loggers,name=*,subtype=RingBuffer'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Stopping
> XmlConfiguration[location=C:\Users\danidemi\workspace\bug-log4j2-hanging-up-before-shutdown\target\classes\log4j2.xml]...
> 2016-12-22
[jira] [Closed] (LOG4J2-1751) Update liquibase-core from 3.5.1 to 3.5.3
[ https://issues.apache.org/jira/browse/LOG4J2-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1751. Resolution: Fixed Fix Version/s: 2.8 Closing, in Git master. Tests OK in Eclipse. > Update liquibase-core from 3.5.1 to 3.5.3 > - > > Key: LOG4J2-1751 > URL: https://issues.apache.org/jira/browse/LOG4J2-1751 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.8 > > > Update liquibase-core from 3.5.1 to 3.5.3. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1751) Update liquibase-core from 3.5.1 to 3.5.3
Gary Gregory created LOG4J2-1751: Summary: Update liquibase-core from 3.5.1 to 3.5.3 Key: LOG4J2-1751 URL: https://issues.apache.org/jira/browse/LOG4J2-1751 Project: Log4j 2 Issue Type: Improvement Affects Versions: 2.7 Reporter: Gary Gregory Assignee: Gary Gregory Update liquibase-core from 3.5.1 to 3.5.3. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1750) Update Kafka from 0.10.0.1 to 0.10.1.1
[
https://issues.apache.org/jira/browse/LOG4J2-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LOG4J2-1750.
Resolution: Fixed
Fix Version/s: 2.8
Closing. {{mvn clean install}} passes. In Git master.
> Update Kafka from 0.10.0.1 to 0.10.1.1
> --
>
> Key: LOG4J2-1750
> URL: https://issues.apache.org/jira/browse/LOG4J2-1750
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Affects Versions: 2.7
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.8
>
>
> Update Kafka from 0.10.0.1 to 0.10.1.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1750) Update Kafka from 0.10.0.1 to 0.10.1.1
Gary Gregory created LOG4J2-1750: Summary: Update Kafka from 0.10.0.1 to 0.10.1.1 Key: LOG4J2-1750 URL: https://issues.apache.org/jira/browse/LOG4J2-1750 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.7 Reporter: Gary Gregory Assignee: Gary Gregory Update Kafka from 0.10.0.1 to 0.10.1.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15771374#comment-15771374
]
Gary Gregory commented on LOG4J2-1748:
--
You could also try to add a call to Configurator.shutdown(...) at the end of
your main. I did not realize that your example started Log4j implicitly but did
not shutdown anything explicitly.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
> Labels: RollingFile, bug
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncLoggerRingBuffer'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=Loggers,name=*,subtype=RingBuffer'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Stopping
>
[jira] [Commented] (LOG4J2-1748) RollingFile appender prevents a stand alone application to terminate for as long as 60 sec
[
https://issues.apache.org/jira/browse/LOG4J2-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15771292#comment-15771292
]
Gary Gregory commented on LOG4J2-1748:
--
I think the rollover happens on a separate thread. When log4j shutdown, it
cleans up after itself and waits for threads to finish and files to be closed.
You might be seeing a delay because of this.
> RollingFile appender prevents a stand alone application to terminate for as
> long as 60 sec
> --
>
> Key: LOG4J2-1748
> URL: https://issues.apache.org/jira/browse/LOG4J2-1748
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
> Environment: Java8, Windows
>Reporter: Daniele Demichelis
> Labels: RollingFile, bug
>
> This code reproduces what I think is a bug of Log4j2.
> It's a simple loop that logs 2000 messages with two appenders:
> a console appender and a rolling file appender that rolls the file
> every 5Kb. This limit is intentionally low to reproduce what I think is a bug.
> Here's the code.
> {code:java}
> package bug;
>
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
>
> public class Example {
>
> private static final Logger logger =
> LogManager.getLogger(Example.class);
>
> public static void main(String[] args) throws InterruptedException {
> for(int i = 0; i<2000; i++){
> logger.info("This is log message #{}.", i);
> Thread.sleep(0);
> }
> }
>
> }
> {code}
> Here's the `log4j2.xml` configuration file.
> {code:xml}
>
>
>
>
>
>
> fileName="target/log4j2/roll-by-size/app.log"
>
> filePattern="target/log4j2/roll-by-size/app.%i.log.gz"
> ignoreExceptions="false"
> append="false">
>
> %d{-MM-dd HH:mm:ss} %p %m%n
>
>
>
> size="5 KB"/>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> What is strange is that when the application is launched you will see this
> logs in the console.
> {code}
> 2016-12-22 22:12:36 INFO This is log message #1993.
> 2016-12-22 22:12:36 INFO This is log message #1994.
> 2016-12-22 22:12:36 INFO This is log message #1995.
> 2016-12-22 22:12:36 INFO This is log message #1996.
> 2016-12-22 22:12:36 INFO This is log message #1997.
> 2016-12-22 22:12:36 INFO This is log message #1998.
> 2016-12-22 22:12:36 INFO This is log message #1999.
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]
> 2016-12-22 22:13:36,380 pool-1-thread-1 DEBUG Stopping
> LoggerContext[name=60199c81,
> org.apache.logging.log4j.core.LoggerContext@4597ec68]...
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=StatusLogger]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 1 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=ContextSelector]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Loggers,name=bug,
> org.apache.logging.log4j2:type=60199c81,component=Lo
> ggers,name=]
> 2016-12-22 22:13:36,381 pool-1-thread-1 TRACE Unregistering 2 MBeans:
> [org.apache.logging.log4j2:type=60199c81,component=Appenders,name=roll-by-size,
> org.apache.logging.log4j2:type=60199c81,c
> omponent=Appenders,name=stdout]
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncAppenders,name=*'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=AsyncLoggerRingBuffer'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Unregistering but no MBeans
> found matching
> 'org.apache.logging.log4j2:type=60199c81,component=Loggers,name=*,subtype=RingBuffer'
> 2016-12-22 22:13:36,382 pool-1-thread-1 TRACE Stopping
>
[jira] [Commented] (LOG4J2-1741) scala: add support for creating custom plugins
[ https://issues.apache.org/jira/browse/LOG4J2-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15761148#comment-15761148 ] Gary Gregory commented on LOG4J2-1741: -- Even though it is more code, I think we should use Builders when we (Log4j devs) write code examples to promote future proofing for binary compatibility. It might be a bit of YAGNI, but I've not met an Appender yet that does not another feature at some point. > scala: add support for creating custom plugins > -- > > Key: LOG4J2-1741 > URL: https://issues.apache.org/jira/browse/LOG4J2-1741 > Project: Log4j 2 > Issue Type: Improvement > Components: Plugins >Reporter: PJ Fanning >Assignee: Mikael Ståldal > Labels: scala > Attachments: log4j2-sample.zip > > > I tried to add a custom appender using Scala but the pattern of having a > class with an Plugin annotation and a static method on that class with a > PluginFactory or PluginBuilderFactory annotation doesn't seem to work in > Scala. > In Scala, you can create a companion object to a class where you can > implement the equivalent of static methods but these are not the same class > under the hood. The Scala compiler builds 2 or more classes, the companion > object gets a class name with a $ appended to it. I think this is affecting > the lookup for the method with the Factory annotation. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1743) CompositeConfiguration does not add filters to appenderRefs
[
https://issues.apache.org/jira/browse/LOG4J2-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-1743.
--
Resolution: Fixed
Fix Version/s: 2.8
Thank you for the patch. In Git master. Please verify and close.
> CompositeConfiguration does not add filters to appenderRefs
> ---
>
> Key: LOG4J2-1743
> URL: https://issues.apache.org/jira/browse/LOG4J2-1743
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.7
>Reporter: Toby Shepheard
> Fix For: 2.8
>
>
> When using composite configuration, if you specify a filter under logger's
> appenderRef, that filter will not be added. For example:
> {code}
>
>
>
>
>
> {code}
> This is because the code does not copy grandchildren, only the immediate
> children of the logger are copied.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1743) CompositeConfiguration does not add filters to appenderRefs
[
https://issues.apache.org/jira/browse/LOG4J2-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-1743:
-
Summary: CompositeConfiguration does not add filters to appenderRefs (was:
CompositeConfiguration not adding filters to appenderRefs)
> CompositeConfiguration does not add filters to appenderRefs
> ---
>
> Key: LOG4J2-1743
> URL: https://issues.apache.org/jira/browse/LOG4J2-1743
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.7
>Reporter: Toby Shepheard
>
> When using composite configuration, if you specify a filter under logger's
> appenderRef, that filter will not be added. For example:
> {code}
>
>
>
>
>
> {code}
> This is because the code does not copy grandchildren, only the immediate
> children of the logger are copied.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1743) CompositeConfiguration not adding filters to appenderRefs
[
https://issues.apache.org/jira/browse/LOG4J2-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15755435#comment-15755435
]
Gary Gregory commented on LOG4J2-1743:
--
Consider subscrbing to our dev mailing list to stay abreast of our release
plans.
> CompositeConfiguration not adding filters to appenderRefs
> -
>
> Key: LOG4J2-1743
> URL: https://issues.apache.org/jira/browse/LOG4J2-1743
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.7
>Reporter: Toby Shepheard
>
> When using composite configuration, if you specify a filter under logger's
> appenderRef, that filter will not be added. For example:
> {code}
>
>
>
>
>
> {code}
> This is because the code does not copy grandchildren, only the immediate
> children of the logger are copied.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1743) CompositeConfiguration not adding filters to appenderRefs
[
https://issues.apache.org/jira/browse/LOG4J2-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15754976#comment-15754976
]
Gary Gregory commented on LOG4J2-1743:
--
Thank you for your report and PR. I would prefer that the test use a new config
file instead of piggy backing on an existing one, but that is just my style to
make the tests simpler and more focused.
> CompositeConfiguration not adding filters to appenderRefs
> -
>
> Key: LOG4J2-1743
> URL: https://issues.apache.org/jira/browse/LOG4J2-1743
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
>Affects Versions: 2.7
>Reporter: Toby Shepheard
>
> When using composite configuration, if you specify a filter under logger's
> appenderRef, that filter will not be added. For example:
> {code}
>
>
>
>
>
> {code}
> This is because the code does not copy grandchildren, only the immediate
> children of the logger are copied.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1740) Add CronTriggeringPolicy programmatically leads to NPE
[ https://issues.apache.org/jira/browse/LOG4J2-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1740. Closing based on feedback from stakeholders. > Add CronTriggeringPolicy programmatically leads to NPE > -- > > Key: LOG4J2-1740 > URL: https://issues.apache.org/jira/browse/LOG4J2-1740 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.7 >Reporter: Peter Nimmervoll > Fix For: 2.8 > > > When i try to add a RollingFileAppender with a CronTriggeringPolicy > programmatically then I get a NPE because the ScheduledExecutorService in > ConfigurationScheduler is null. IMO the ScheduledExecutorService should > always be created even when there are no items which needs to be scheduled. > Caused by: java.lang.NullPointerException > at > org.apache.logging.log4j.core.config.ConfigurationScheduler.schedule(ConfigurationScheduler.java:107) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.config.ConfigurationScheduler.scheduleWithCron(ConfigurationScheduler.java:120) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy.initialize(CronTriggeringPolicy.java:72) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.rolling.RollingFileManager.initialize(RollingFileManager.java:104) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender.createAppender(RollingRandomAccessFileAppender.java:218) > ~[log4j-core-2.7.jar:2.7] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-1740) Add CronTriggeringPolicy programmatically leads to NPE
[ https://issues.apache.org/jira/browse/LOG4J2-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved LOG4J2-1740. -- Resolution: Fixed Fix Version/s: 2.8 Ralph, Would you mind giving a look over my fix in Git master? All the tests pass. Peter, Can you test again? Thank you all, Gary > Add CronTriggeringPolicy programmatically leads to NPE > -- > > Key: LOG4J2-1740 > URL: https://issues.apache.org/jira/browse/LOG4J2-1740 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.7 >Reporter: Peter Nimmervoll > Fix For: 2.8 > > > When i try to add a RollingFileAppender with a CronTriggeringPolicy > programmatically then I get a NPE because the ScheduledExecutorService in > ConfigurationScheduler is null. IMO the ScheduledExecutorService should > always be created even when there are no items which needs to be scheduled. > Caused by: java.lang.NullPointerException > at > org.apache.logging.log4j.core.config.ConfigurationScheduler.schedule(ConfigurationScheduler.java:107) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.config.ConfigurationScheduler.scheduleWithCron(ConfigurationScheduler.java:120) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy.initialize(CronTriggeringPolicy.java:72) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.rolling.RollingFileManager.initialize(RollingFileManager.java:104) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender.createAppender(RollingRandomAccessFileAppender.java:218) > ~[log4j-core-2.7.jar:2.7] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1740) Add CronTriggeringPolicy programmatically leads to NPE
[ https://issues.apache.org/jira/browse/LOG4J2-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15752989#comment-15752989 ] Gary Gregory commented on LOG4J2-1740: -- I do not think you _always_ want to have the start of a scheduler create a thread pool as this would be wasteful for set ups that do not need this feature. The AbstractConfiguration class always holds a sheduler for example. > Add CronTriggeringPolicy programmatically leads to NPE > -- > > Key: LOG4J2-1740 > URL: https://issues.apache.org/jira/browse/LOG4J2-1740 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.7 >Reporter: Peter Nimmervoll > > When i try to add a RollingFileAppender with a CronTriggeringPolicy > programmatically then I get a NPE because the ScheduledExecutorService in > ConfigurationScheduler is null. IMO the ScheduledExecutorService should > always be created even when there are no items which needs to be scheduled. > Caused by: java.lang.NullPointerException > at > org.apache.logging.log4j.core.config.ConfigurationScheduler.schedule(ConfigurationScheduler.java:107) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.config.ConfigurationScheduler.scheduleWithCron(ConfigurationScheduler.java:120) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy.initialize(CronTriggeringPolicy.java:72) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.rolling.RollingFileManager.initialize(RollingFileManager.java:104) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender.createAppender(RollingRandomAccessFileAppender.java:218) > ~[log4j-core-2.7.jar:2.7] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1740) Add CronTriggeringPolicy programmatically leads to NPE
[
https://issues.apache.org/jira/browse/LOG4J2-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15752791#comment-15752791
]
Gary Gregory commented on LOG4J2-1740:
--
You should see if you can create a failing test in
{{org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicyTest}}.
> Add CronTriggeringPolicy programmatically leads to NPE
> --
>
> Key: LOG4J2-1740
> URL: https://issues.apache.org/jira/browse/LOG4J2-1740
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.7
>Reporter: Peter Nimmervoll
>
> When i try to add a RollingFileAppender with a CronTriggeringPolicy
> programmatically then I get a NPE because the ScheduledExecutorService in
> ConfigurationScheduler is null. IMO the ScheduledExecutorService should
> always be created even when there are no items which needs to be scheduled.
> Caused by: java.lang.NullPointerException
> at
> org.apache.logging.log4j.core.config.ConfigurationScheduler.schedule(ConfigurationScheduler.java:107)
> ~[log4j-core-2.7.jar:2.7]
> at
> org.apache.logging.log4j.core.config.ConfigurationScheduler.scheduleWithCron(ConfigurationScheduler.java:120)
> ~[log4j-core-2.7.jar:2.7]
> at
> org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy.initialize(CronTriggeringPolicy.java:72)
> ~[log4j-core-2.7.jar:2.7]
> at
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.initialize(RollingFileManager.java:104)
> ~[log4j-core-2.7.jar:2.7]
> at
> org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender.createAppender(RollingRandomAccessFileAppender.java:218)
> ~[log4j-core-2.7.jar:2.7]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1740) Add CronTriggeringPolicy programmatically leads to NPE
[ https://issues.apache.org/jira/browse/LOG4J2-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15752237#comment-15752237 ] Gary Gregory commented on LOG4J2-1740: -- Can you please provide your configuration file? How about a unit test patch that demonstrate the problem? > Add CronTriggeringPolicy programmatically leads to NPE > -- > > Key: LOG4J2-1740 > URL: https://issues.apache.org/jira/browse/LOG4J2-1740 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.7 >Reporter: Peter Nimmervoll > > When i try to add a RollingFileAppender with a CronTriggeringPolicy > programmatically then I get a NPE because the ScheduledExecutorService in > ConfigurationScheduler is null. IMO the ScheduledExecutorService should > always be created even when there are no items which needs to be scheduled. > Caused by: java.lang.NullPointerException > at > org.apache.logging.log4j.core.config.ConfigurationScheduler.schedule(ConfigurationScheduler.java:107) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.config.ConfigurationScheduler.scheduleWithCron(ConfigurationScheduler.java:120) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy.initialize(CronTriggeringPolicy.java:72) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.rolling.RollingFileManager.initialize(RollingFileManager.java:104) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender.createAppender(RollingRandomAccessFileAppender.java:218) > ~[log4j-core-2.7.jar:2.7] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1740) Add CronTriggeringPolicy programmatically leads to NPE
[ https://issues.apache.org/jira/browse/LOG4J2-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15751072#comment-15751072 ] Gary Gregory commented on LOG4J2-1740: -- I fixed that in commit c5222aea440023a2891c08634ec8ed2d8ca63e00 for [LOG4J2-1474]. Can you check our Git master? > Add CronTriggeringPolicy programmatically leads to NPE > -- > > Key: LOG4J2-1740 > URL: https://issues.apache.org/jira/browse/LOG4J2-1740 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.7 >Reporter: Peter Nimmervoll > > When i try to add a RollingFileAppender with a CronTriggeringPolicy > programmatically then I get a NPE because the ScheduledExecutorService in > ConfigurationScheduler is null. IMO the ScheduledExecutorService should > always be created even when there are no items which needs to be scheduled. > Caused by: java.lang.NullPointerException > at > org.apache.logging.log4j.core.config.ConfigurationScheduler.schedule(ConfigurationScheduler.java:107) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.config.ConfigurationScheduler.scheduleWithCron(ConfigurationScheduler.java:120) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy.initialize(CronTriggeringPolicy.java:72) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.rolling.RollingFileManager.initialize(RollingFileManager.java:104) > ~[log4j-core-2.7.jar:2.7] > at > org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender.createAppender(RollingRandomAccessFileAppender.java:218) > ~[log4j-core-2.7.jar:2.7] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1740) Add CronTriggeringPolicy programmatically leads to NPE
[ https://issues.apache.org/jira/browse/LOG4J2-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15750920#comment-15750920 ] Gary Gregory commented on LOG4J2-1740: -- Can you please add a stack trace to your description? > Add CronTriggeringPolicy programmatically leads to NPE > -- > > Key: LOG4J2-1740 > URL: https://issues.apache.org/jira/browse/LOG4J2-1740 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.7 >Reporter: Peter Nimmervoll > > When i try to add a RollingFileAppender with a CronTriggeringPolicy > programmatically then I get a NPE because the ScheduledExecutorService in > ConfigurationScheduler is null. IMO the ScheduledExecutorService should > always be created even when there are no items which needs to be scheduled. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1682) Logger using LocalizedMessageFactory prints key instead of message
[
https://issues.apache.org/jira/browse/LOG4J2-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-1682:
-
Summary: Logger using LocalizedMessageFactory prints key instead of message
(was: Logger using LocalizedMessageFactory prints key instead of messsage)
> Logger using LocalizedMessageFactory prints key instead of message
> --
>
> Key: LOG4J2-1682
> URL: https://issues.apache.org/jira/browse/LOG4J2-1682
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.7
>Reporter: Markus Waidhofer
>Assignee: Gary Gregory
> Fix For: 2.8
>
> Attachments: exampleLocalizedMessageFactory.zip
>
>
> I am having a problem when logging localized messages. I use a Logger with
> the LocalizedMessageFactory. However, everytime I pass the message key to the
> logger, it prints the key itself instead of the message. If I pass additional
> arguments to the logging method, the key gets translated correctly to the
> message.
> Example:
> {code}
> public class Showcase {
> private static Logger logger = LogManager.getLogger(Showcase.class, new
> LocalizedMessageFactory("messages"));
> public static void main(String... args) {
> logger.info("key.test"); // logs "key.test"
> logger.info("key.test", ""); // prints message correctly
> }
> }
> {code}
> See attached project for a working example.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-1302) log4j-slf4j-impl should provide a runtime dependency on log4j-core
[ https://issues.apache.org/jira/browse/LOG4J2-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15749828#comment-15749828 ] Gary Gregory commented on LOG4J2-1302: -- The expectation of this user does not match our documentation or architecture. > log4j-slf4j-impl should provide a runtime dependency on log4j-core > -- > > Key: LOG4J2-1302 > URL: https://issues.apache.org/jira/browse/LOG4J2-1302 > Project: Log4j 2 > Issue Type: Improvement > Components: SLF4J Bridge >Reporter: Steve Davids >Assignee: Remko Popma > > After pulling in the log4j-slf4j-impl I was surprised to find out that I also > needed to add the the log4j-core dependency myself instead of the dependency > pulled in automatically from the log4j-slf4j-impl pom. I was expecting the > behavior provided by slf4j-log4j12 which does pull in the appropriate > implementation to get going immediately. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1733) Add SyncSend attribute to KafkaAppender (as in KafkaLog4jAppender)
[ https://issues.apache.org/jira/browse/LOG4J2-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-1733. Resolution: Fixed Fix Version/s: 2.8 Apply patch from Vincent Tieleman with a change: Do NOT change the deprecated factory method as this would break BC. New feature are only added to the Builder. Closes #51. > Add SyncSend attribute to KafkaAppender (as in KafkaLog4jAppender) > -- > > Key: LOG4J2-1733 > URL: https://issues.apache.org/jira/browse/LOG4J2-1733 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.5 > Environment: Kafka 0.10.1.0 >Reporter: Vincent Tieleman >Assignee: Mikael Ståldal > Fix For: 2.8 > > > The KafkaLog4jAppender (shipped with Kafka and usable with log4j), has a > syncsend property that improves performance significantly by not blocking a > send to Kafka. I've tried many other configuration settings and setups, but > find that none of these approaches improved the logging performance to Kafka > as significantly as setting the syncsend property to false. > Unfortunately, the syncsend property is not supported by the KafkaAppender > shipped with log4j2 and the KafkaLog4jAppender only supports log4j, so I am > stuck with forking the code and making the change myself. > Could you please introduce this property in the KafkaAppender in log4j2? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-1733) Add SyncSend attribute to KafkaAppender (as in KafkaLog4jAppender)
[ https://issues.apache.org/jira/browse/LOG4J2-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-1733: - Summary: Add SyncSend attribute to KafkaAppender (as in KafkaLog4jAppender) (was: Introduce SyncSend property for KafkaAppender (as in KafkaLog4jAppender)) > Add SyncSend attribute to KafkaAppender (as in KafkaLog4jAppender) > -- > > Key: LOG4J2-1733 > URL: https://issues.apache.org/jira/browse/LOG4J2-1733 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.5 > Environment: Kafka 0.10.1.0 >Reporter: Vincent Tieleman >Assignee: Mikael Ståldal > > The KafkaLog4jAppender (shipped with Kafka and usable with log4j), has a > syncsend property that improves performance significantly by not blocking a > send to Kafka. I've tried many other configuration settings and setups, but > find that none of these approaches improved the logging performance to Kafka > as significantly as setting the syncsend property to false. > Unfortunately, the syncsend property is not supported by the KafkaAppender > shipped with log4j2 and the KafkaLog4jAppender only supports log4j, so I am > stuck with forking the code and making the change myself. > Could you please introduce this property in the KafkaAppender in log4j2? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1739) Add Builder to KafkaAppender and deprecate org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppender.createAppender(Layout, Filter, String, b
[
https://issues.apache.org/jira/browse/LOG4J2-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LOG4J2-1739.
Resolution: Fixed
Fix Version/s: 2.8
In Git master.
> Add Builder to KafkaAppender and deprecate
> org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppender.createAppender(Layout extends Serializable>, Filter, String, boolean, String, Property[],
> Configuration)
>
>
> Key: LOG4J2-1739
> URL: https://issues.apache.org/jira/browse/LOG4J2-1739
> Project: Log4j 2
> Issue Type: New Feature
> Components: Appenders
>Affects Versions: 2.7
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.8
>
>
> Add {{Builder}} to {{KafkaAppender}} and deprecate
> {{KafkaAppender.createAppender(Layout, Filter,
> String, boolean, String, Property[], Configuration)}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1739) Add Builder to KafkaAppender and deprecate org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppender.createAppender(Layout, Filter, String,
Gary Gregory created LOG4J2-1739:
Summary: Add Builder to KafkaAppender and deprecate
org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppender.createAppender(Layout, Filter, String, boolean, String, Property[],
Configuration)
Key: LOG4J2-1739
URL: https://issues.apache.org/jira/browse/LOG4J2-1739
Project: Log4j 2
Issue Type: New Feature
Components: Appenders
Affects Versions: 2.7
Reporter: Gary Gregory
Assignee: Gary Gregory
Add {{Builder}} to {{KafkaAppender}} and deprecate
{{KafkaAppender.createAppender(Layout, Filter, String,
boolean, String, Property[], Configuration)}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1738) Add a Builder to JsonLayout and deprecate org.apache.logging.log4j.core.layout.JsonLayout.createLayout(Configuration, boolean, boolean, boolean, boolean, boolean, boolean
[
https://issues.apache.org/jira/browse/LOG4J2-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LOG4J2-1738.
Resolution: Fixed
Fix Version/s: 2.8
Closing. In Git master.
> Add a Builder to JsonLayout and deprecate
> org.apache.logging.log4j.core.layout.JsonLayout.createLayout(Configuration,
> boolean, boolean, boolean, boolean, boolean, boolean, String, String,
> Charset, boolean)
> -
>
> Key: LOG4J2-1738
> URL: https://issues.apache.org/jira/browse/LOG4J2-1738
> Project: Log4j 2
> Issue Type: New Feature
> Components: Layouts
>Affects Versions: 2.7
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.8
>
>
> Add a Builder to {{JsonLayout}} and deprecate
> {{JsonLayout.createLayout(Configuration, boolean, boolean, boolean, boolean,
> boolean, boolean, String, String, Charset, boolean)}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-1738) Add a Builder to JsonLayout and deprecate org.apache.logging.log4j.core.layout.JsonLayout.createLayout(Configuration, boolean, boolean, boolean, boolean, boolean, boolea
Gary Gregory created LOG4J2-1738:
Summary: Add a Builder to JsonLayout and deprecate
org.apache.logging.log4j.core.layout.JsonLayout.createLayout(Configuration,
boolean, boolean, boolean, boolean, boolean, boolean, String, String, Charset,
boolean)
Key: LOG4J2-1738
URL: https://issues.apache.org/jira/browse/LOG4J2-1738
Project: Log4j 2
Issue Type: New Feature
Components: Layouts
Affects Versions: 2.7
Reporter: Gary Gregory
Assignee: Gary Gregory
Add a Builder to {{JsonLayout}} and deprecate
{{JsonLayout.createLayout(Configuration, boolean, boolean, boolean, boolean,
boolean, boolean, String, String, Charset, boolean)}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-969) Refactor SyslogAppender so that Layout is a Plugin element
[
https://issues.apache.org/jira/browse/LOG4J2-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LOG4J2-969.
---
Resolution: Fixed
Fix Version/s: 2.8
For the most flexibility, you can now set the {{Layout}} element for a
{{SyslogAppender}} which will override the {{format}} setting.
> Refactor SyslogAppender so that Layout is a Plugin element
> ---
>
> Key: LOG4J2-969
> URL: https://issues.apache.org/jira/browse/LOG4J2-969
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders, Layouts
>Affects Versions: 2.2
>Reporter: Paul D Johe
>Assignee: Gary Gregory
> Labels: syslog, syslogappender
> Fix For: 2.8
>
>
> There are quite a lot of attributes to the syslogappender that could have
> been simply included as:
> {code}
> @PluginElement("layout") Layout layout,
> {code}
> This is much more flexible (for example, extension of existing syslog
> layouts) and the field 'format' becomes superfluous, as it is implied by the
> layout chosen (normally SyslogLayout or Rfc5424Layout will be chosen).
> Furthermore, it becomes much clearer which attributes are for the RFC5424
> format and which are for the BSD format.
> Or at least add the possibility for a Layout element, which if does not exist
> will use the existing code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Reopened] (LOG4J2-969) Refactor SyslogAppender so that Layout is a Plugin element
[
https://issues.apache.org/jira/browse/LOG4J2-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory reopened LOG4J2-969:
-
Assignee: Gary Gregory
> Refactor SyslogAppender so that Layout is a Plugin element
> ---
>
> Key: LOG4J2-969
> URL: https://issues.apache.org/jira/browse/LOG4J2-969
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders, Layouts
>Affects Versions: 2.2
>Reporter: Paul D Johe
>Assignee: Gary Gregory
> Labels: syslog, syslogappender
>
> There are quite a lot of attributes to the syslogappender that could have
> been simply included as:
> {code}
> @PluginElement("layout") Layout layout,
> {code}
> This is much more flexible (for example, extension of existing syslog
> layouts) and the field 'format' becomes superfluous, as it is implied by the
> layout chosen (normally SyslogLayout or Rfc5424Layout will be chosen).
> Furthermore, it becomes much clearer which attributes are for the RFC5424
> format and which are for the BSD format.
> Or at least add the possibility for a Layout element, which if does not exist
> will use the existing code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Closed] (LOG4J2-1737) Add a Builder to SyslogLayout and deprecate SyslogLayout.createLayout(Facility, boolean, String, Charset)
[
https://issues.apache.org/jira/browse/LOG4J2-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LOG4J2-1737.
Resolution: Fixed
Fix Version/s: 2.8
In Git master.
> Add a Builder to SyslogLayout and deprecate
> SyslogLayout.createLayout(Facility, boolean, String, Charset)
> -
>
> Key: LOG4J2-1737
> URL: https://issues.apache.org/jira/browse/LOG4J2-1737
> Project: Log4j 2
> Issue Type: New Feature
> Components: Layouts
>Affects Versions: 2.7
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.8
>
>
> Add a {{Builder}} to {{SyslogLayout}} and deprecate
> {{SyslogLayout.createLayout(Facility, boolean, String, Charset)}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
