[jira] [Commented] (LOG4J2-1876) Unreliable checking for runtime dependencies
[
https://issues.apache.org/jira/browse/LOG4J2-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964502#comment-15964502
]
Matt Sicker commented on LOG4J2-1876:
-
That would be appropriate. Also, I don't think you meant to assign this to me?
> Unreliable checking for runtime dependencies
>
>
> Key: LOG4J2-1876
> URL: https://issues.apache.org/jira/browse/LOG4J2-1876
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8.2
>Reporter: Mikael Ståldal
>Assignee: Matt Sicker
>
> If I include this in Maven POM:
> {code}
>
> com.fasterxml.jackson.core
> jackson-databind
> 2.8.7
> runtime
>
>
> com.fasterxml.jackson.core
> jackson-core
>
>
>
> {code}
> I get this printed on STDERR on startup:
> {code}
> Unknown error checking for existence of class:
> com.fasterxml.jackson.databind.ObjectMapper
> java.lang.NoClassDefFoundError: com/fasterxml/jackson/core/Versioned
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> 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.util.LoaderUtil.isClassAvailable(LoaderUtil.java:115)
> at
> org.apache.logging.log4j.core.util.Loader.isClassAvailable(Loader.java:310)
> at
> org.apache.logging.log4j.core.config.yaml.YamlConfigurationFactory.(YamlConfigurationFactory.java:47)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.logging.log4j.core.util.ReflectionUtil.instantiate(ReflectionUtil.java:188)
> at
> org.apache.logging.log4j.core.config.ConfigurationFactory.addFactory(ConfigurationFactory.java:190)
> at
> org.apache.logging.log4j.core.config.ConfigurationFactory.getInstance(ConfigurationFactory.java:164)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:613)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:242)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:174)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:618)
> at logtest.Main.(Main.java:14)
> Caused by: java.lang.ClassNotFoundException:
> com.fasterxml.jackson.core.Versioned
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 33 more
> Unknown error checking for existence of class:
> com.fasterxml.jackson.databind.ObjectMapper
> java.lang.NoClassDefFoundError: com/fasterxml/jackson/core/Versioned
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
>
[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=15962930#comment-15962930 ] Matt Sicker commented on LOG4J2-1873: - I'd be interested in seeing this feature myself. The standard UTF-8 CharsetEncoder is ridiculous in this regard. > 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] [Created] (LOG4J2-1871) Add an Avro layout for extensible binary encoding
Matt Sicker created LOG4J2-1871: --- Summary: Add an Avro layout for extensible binary encoding Key: LOG4J2-1871 URL: https://issues.apache.org/jira/browse/LOG4J2-1871 Project: Log4j 2 Issue Type: New Feature Components: Layouts Reporter: Matt Sicker Similar in style to the JSON layout (and other related dynamic layouts), a new layout based on [Apache Avro|https://avro.apache.org/docs/current/] would be a good choice for simple binary layouts. Avro also provides adapters for Apache Thrift and Protobuf, so this library makes sense as a good choice for the most extensible binary layout. This also opens up the ability to create a socket appender or similar using the Avro IPC classes. -- 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-1870) Add a "fast defaults" option to make modern configurations simpler
Matt Sicker created LOG4J2-1870: --- Summary: Add a "fast defaults" option to make modern configurations simpler Key: LOG4J2-1870 URL: https://issues.apache.org/jira/browse/LOG4J2-1870 Project: Log4j 2 Issue Type: New Feature Components: Core Reporter: Matt Sicker There have been a few non-default options added over various releases which improve the performance of Log4j. These include: * Async loggers * Direct console appender * Async Kafka appender This feature should add a Log4j system property to quickly enable fast defaults instead of the backward compatible ones. This should enable async loggers globally when the LMAX library is available. This should also enable current and future fast options to appenders and other plugins. Ideally, this feature should be accompanied by an explanation of how to choose options and appenders for difference scenarios. For example, it would be great to explain why a user might use different wait strategies in different scenarios (high throughput versus low latency versus safety), or why using different clocks than the default can be useful. Explicit details of all available options should remain on their normal manual pages, but quick summaries and pointers on such a page would be useful. -- 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-1229) Error creating logger
[
https://issues.apache.org/jira/browse/LOG4J2-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-1229:
Fix Version/s: (was: 2.8.2)
> Error creating logger
> -
>
> Key: LOG4J2-1229
> URL: https://issues.apache.org/jira/browse/LOG4J2-1229
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 2.4.1, 2.5
> Environment: Ubuntu 14.04
>Reporter: Dmitriy Dumanskiy
>
> I have a lot of VMs where everything is fine. But on some of them I get
> below stack trace. I have a feeling it somehow related with access rights.
> Here is stack trace :
> {code}
> 2015-12-21 08:05:06,036 AsyncLogger-1 ERROR Unable to invoke factory method
> in class class org.apache.logging.log4j.core.appender.RollingFileAppender for
> element RollingFile. java.lang.reflect.InvocationTargetException
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:136)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:813)
> at
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:753)
> at
> org.apache.logging.log4j.core.appender.routing.RoutingAppender.createAppender(RoutingAppender.java:152)
> at
> org.apache.logging.log4j.core.appender.routing.RoutingAppender.getControl(RoutingAppender.java:136)
> at
> org.apache.logging.log4j.core.appender.routing.RoutingAppender.append(RoutingAppender.java:110)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:152)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:125)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:116)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:390)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:378)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:362)
> at
> org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:79)
> at
> org.apache.logging.log4j.core.async.AsyncLogger.actualAsyncLog(AsyncLogger.java:385)
> at
> org.apache.logging.log4j.core.async.RingBufferLogEvent.execute(RingBufferLogEvent.java:103)
> at
> org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:43)
> at
> org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(RingBufferLogEventHandler.java:28)
> at
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
> 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: java.lang.IllegalStateException: ManagerFactory
> [org.apache.logging.log4j.core.appender.rolling.RollingFileManager$RollingFileManagerFactory@346629f5]
> unable to create manager for [/data//1_v4.csv] with data
> [org.apache.logging.log4j.core.appender.rolling.RollingFileManager$FactoryData@6d48f4b0]
> at
> org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:73)
> at
> org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:61)
> at
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.getFileManager(RollingFileManager.java:79)
> at
> org.apache.logging.log4j.core.appender.RollingFileAppender.createAppender(RollingFileAppender.java:193)
> ... 25 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] [Updated] (LOG4J2-1013) Log4j2 Main Arguments Lookup by name doesn't work
[
https://issues.apache.org/jira/browse/LOG4J2-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-1013:
Fix Version/s: (was: 2.8.2)
> Log4j2 Main Arguments Lookup by name doesn't work
> -
>
> Key: LOG4J2-1013
> URL: https://issues.apache.org/jira/browse/LOG4J2-1013
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core, Lookups
>Affects Versions: 2.2
> Environment: Windows 7 x64 Ultimate and Java 8U31 x64. Project
> created using Eclipse.
>Reporter: Ioan Mihaila
>Priority: Critical
> Attachments:
> LOG4J2_1013_select_underlying_StrLookup_before_stripping_off_potential_default_values.patch
>
>
> Accessing Main Arguments by using index based look up works : $\{main:0}
> Accessing Main Arguments by using name based look up doesn't work :
> $\{main:--file}
> When trying to access by name it doesn't retrieve the argument but retrieves
> "-file".
--
This message was sent by Atlassian JIRA
(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-1699) Configurable Log File Permissions with PosixFilePermission
[ https://issues.apache.org/jira/browse/LOG4J2-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1699: Fix Version/s: (was: 2.8.2) > Configurable Log File Permissions with PosixFilePermission > -- > > Key: LOG4J2-1699 > URL: https://issues.apache.org/jira/browse/LOG4J2-1699 > Project: Log4j 2 > Issue Type: Question > Components: Appenders > Environment: Linux >Reporter: Demetrios Dimatos >Priority: Critical > Labels: features > Original Estimate: 336h > Remaining Estimate: 336h > > We would like to hear the communities thoughts on being able to configure the > permissions log files are created with. We don't want to rely on UMASK > because we have managed services who's process should generate logs with a > 644 yet deployed applications by users should default to a 640 because the > logs may contain sensitive information. > We will make the modification and set this in the properties file. Now we are > looking to see what the community position would be on accepting such a > patch, we don't want to be patching our own distribution indefinitely. > I searched all the JIRAs and was not able to find any matching requirements > recently. All I could find was something dated in 2006: > https://bz.apache.org/bugzilla/show_bug.cgi?id=40407 -- 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-915) Wrong timestamp of filename when SizeBasedTriggering and TimeBasedTrigger used simultaniously with RollingFileAppender
[ https://issues.apache.org/jira/browse/LOG4J2-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-915: --- Fix Version/s: (was: 2.8.2) > Wrong timestamp of filename when SizeBasedTriggering and TimeBasedTrigger > used simultaniously with RollingFileAppender > -- > > Key: LOG4J2-915 > URL: https://issues.apache.org/jira/browse/LOG4J2-915 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.1 >Reporter: Daniel Stuckert > Attachments: JIRA_915.diff > > > When using the SizedBasedTrigger and TimeBasedTrigger simultaniously the > timestamp for the filename generated by the SizeBasedTrigger is not the > current time but the next timestamp calculated by the TimeBasedTrigger. > The bug can be reproduced with the sample configuration in the manual. > Likely cause of the problem is that the TimeBasedTrigger sets the time of the > next rollover and the SizeBasedTrigger uses the set time. -- 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-1198) Add support for custom rollover strategy
[ https://issues.apache.org/jira/browse/LOG4J2-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1198: Fix Version/s: (was: 2.8.2) > Add support for custom rollover strategy > > > Key: LOG4J2-1198 > URL: https://issues.apache.org/jira/browse/LOG4J2-1198 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Affects Versions: 2.4.1 >Reporter: Remko Popma > > [DefaultRolloverStrategy|http://logging.apache.org/log4j/2.x/manual/appenders.html#DefaultRolloverStrategy] > has a very compact configuration, but as a trade-off has become a bit > monolithic. I find it difficult to unit test and maintain. > Continuing in the spirit of the work done for LOG4J2-435, I would like to > break out components for the different kinds of processing done by > DefaultRolloverStrategy so that they can be individually configured and > combined by users. Users would configure a CustomRolloverStrategy by > specifying nested actions that define what needs to be done during a rollover. > The DefaultRolloverStrategy would still continue to work as current, but > under the hood can delegate to these components. > _At this stage the above is still just a concept. The description is to be > updated when it becomes more clear if and how this would work._ -- 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-1130) CsvLogEventLayout NanoTime timestamp is always zero.
[
https://issues.apache.org/jira/browse/LOG4J2-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-1130:
Fix Version/s: (was: 2.8.2)
> CsvLogEventLayout NanoTime timestamp is always zero.
>
>
> Key: LOG4J2-1130
> URL: https://issues.apache.org/jira/browse/LOG4J2-1130
> Project: Log4j 2
> Issue Type: Bug
> Components: Layouts
>Affects Versions: 2.4
>Reporter: Remko Popma
>
> CsvLogEventLayout generates NanoTime timestamps but these are always zero.
> To fix this, add the below code to the CsvLogEventLayout constructor:
> {code}
> // LOG4J2-1074 Switch to actual clock if nanosecond timestamps are
> required in config.
> // LoggerContext will notify known NanoClockFactory users that the
> configuration has changed.
> NanoClockFactory.setMode(NanoClockFactory.Mode.System);
> {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-1116) Web app-friendly thread locals for gc-free logging (was: upgrade to log4j2 causes too frequent minor gc)
[ https://issues.apache.org/jira/browse/LOG4J2-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1116: Fix Version/s: (was: 2.8.2) > Web app-friendly thread locals for gc-free logging (was: upgrade to log4j2 > causes too frequent minor gc) > > > Key: LOG4J2-1116 > URL: https://issues.apache.org/jira/browse/LOG4J2-1116 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.3 > Environment: jdk1.6 > slf4j 1.7.9 > log4j2.3 >Reporter: Mingjiang Shi >Assignee: Ralph Goers >Priority: Critical > Attachments: Log4jThreadLocal.java, Log4jThreadLocal.java > > > We used slf4j+log1.2 in our spring web application. Due to the log4j1.0 > performance issue, we upgrade it to log4j2. When it goes to production, it > experienced very frequent minor gc (once per second) even though the eden > area is not full. For example, the eden area just occupied 10%, the minor gc > also happens. The issue disappears when rolling back to log4j1.2. > Can anyone show some hints on diagnose this issue? Thanks! -- 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-1862) The comments in Order and OrderComparator are wrong
[ https://issues.apache.org/jira/browse/LOG4J2-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved LOG4J2-1862. - Resolution: Fixed Fix Version/s: 2.8.2 Thanks for the PR! Merged to master. Please verify and close. > The comments in Order and OrderComparator are wrong > --- > > Key: LOG4J2-1862 > URL: https://issues.apache.org/jira/browse/LOG4J2-1862 > Project: Log4j 2 > Issue Type: Documentation > Components: Documentation >Reporter: wangyuntao >Assignee: Matt Sicker >Priority: Trivial > 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] [Assigned] (LOG4J2-1862) The comments in Order and OrderComparator are wrong
[ https://issues.apache.org/jira/browse/LOG4J2-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker reassigned LOG4J2-1862: --- Assignee: Matt Sicker > The comments in Order and OrderComparator are wrong > --- > > Key: LOG4J2-1862 > URL: https://issues.apache.org/jira/browse/LOG4J2-1862 > Project: Log4j 2 > Issue Type: Documentation > Components: Documentation >Reporter: wangyuntao >Assignee: Matt Sicker >Priority: Trivial > -- 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-1861) Fix JavaDoc on org.apache.logging.log4j.ThreadContext (about inheritance)
[
https://issues.apache.org/jira/browse/LOG4J2-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-1861.
-
Resolution: Fixed
Fix Version/s: 2.8.2
Fixed in master. Please verify and close.
> Fix JavaDoc on org.apache.logging.log4j.ThreadContext (about inheritance)
> -
>
> Key: LOG4J2-1861
> URL: https://issues.apache.org/jira/browse/LOG4J2-1861
> Project: Log4j 2
> Issue Type: Documentation
> Components: API
>Affects Versions: 2.8.1
>Reporter: Franz van Betteraey
>Assignee: Matt Sicker
>Priority: Trivial
> Labels: easyfix, javadoc
> Fix For: 2.8.2
>
>
> The
> [JavaDoc|https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/ThreadContext.html]
> of org.apache.logging.log4j.ThreadContext describes the behavior regarding
> inheritance as follows:
> {quote}
> A child thread automatically inherits a copy of the mapped diagnostic context
> of its parent.
> {quote}
> But the behavior was changed in LOG4J2-479. Now the system property
> _isThreadContextMapInheritable_ has to be set to _true_ to enforce this
> behavior (see
> [documentation|https://logging.apache.org/log4j/2.x/manual/thread-context.html]).
> This should be corrected in the JavaDoc of ThreadContext.
--
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] [Assigned] (LOG4J2-1861) Fix JavaDoc on org.apache.logging.log4j.ThreadContext (about inheritance)
[
https://issues.apache.org/jira/browse/LOG4J2-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker reassigned LOG4J2-1861:
---
Assignee: Matt Sicker
> Fix JavaDoc on org.apache.logging.log4j.ThreadContext (about inheritance)
> -
>
> Key: LOG4J2-1861
> URL: https://issues.apache.org/jira/browse/LOG4J2-1861
> Project: Log4j 2
> Issue Type: Documentation
> Components: API
>Affects Versions: 2.8.1
>Reporter: Franz van Betteraey
>Assignee: Matt Sicker
>Priority: Trivial
> Labels: easyfix, javadoc
> Fix For: 2.8.2
>
>
> The
> [JavaDoc|https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/ThreadContext.html]
> of org.apache.logging.log4j.ThreadContext describes the behavior regarding
> inheritance as follows:
> {quote}
> A child thread automatically inherits a copy of the mapped diagnostic context
> of its parent.
> {quote}
> But the behavior was changed in LOG4J2-479. Now the system property
> _isThreadContextMapInheritable_ has to be set to _true_ to enforce this
> behavior (see
> [documentation|https://logging.apache.org/log4j/2.x/manual/thread-context.html]).
> This should be corrected in the JavaDoc of ThreadContext.
--
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-1863) Add support for filtering input in TcpSocketServer and UdpSocketServer
[ https://issues.apache.org/jira/browse/LOG4J2-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved LOG4J2-1863. - Resolution: Fixed Added to master. > Add support for filtering input in TcpSocketServer and UdpSocketServer > -- > > Key: LOG4J2-1863 > URL: https://issues.apache.org/jira/browse/LOG4J2-1863 > Project: Log4j 2 > Issue Type: New Feature > Components: Receivers >Affects Versions: 2.8.1 >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: 2.8.2 > > > It is best practice to add a configurable class filter to ObjectInputStream > usage when input comes from untrusted sources. Add this feature to > TcpSocketServer and UdpSocketServer along with sensible default settings. > This feature is unnecessary in JmsServer as that relies on the underlying > configuration of the JMS server (e.g., ActiveMQ has a similar configuration > option). -- 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-1863) Add support for filtering input in TcpSocketServer and UdpSocketServer
Matt Sicker created LOG4J2-1863: --- Summary: Add support for filtering input in TcpSocketServer and UdpSocketServer Key: LOG4J2-1863 URL: https://issues.apache.org/jira/browse/LOG4J2-1863 Project: Log4j 2 Issue Type: New Feature Components: Receivers Affects Versions: 2.8.1 Reporter: Matt Sicker Assignee: Matt Sicker Fix For: 2.8.2 It is best practice to add a configurable class filter to ObjectInputStream usage when input comes from untrusted sources. Add this feature to TcpSocketServer and UdpSocketServer along with sensible default settings. This feature is unnecessary in JmsServer as that relies on the underlying configuration of the JMS server (e.g., ActiveMQ has a similar configuration option). -- 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-1849) Broken FixedDateFormat tests when daylight saving time starts
[
https://issues.apache.org/jira/browse/LOG4J2-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926338#comment-15926338
]
Matt Sicker commented on LOG4J2-1849:
-
It also appears that Jenkins runs in UTC or something as the tests didn't fail
there when I pushed some code last Sunday. On the plus side, it gets dark later
now in Chicago.
> Broken FixedDateFormat tests when daylight saving time starts
> -
>
> Key: LOG4J2-1849
> URL: https://issues.apache.org/jira/browse/LOG4J2-1849
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8.1
>Reporter: Matt Sicker
>Assignee: Remko Popma
>
> Today we started daylight saving time in the US, and the following tests
> failed:
> {noformat}
> Failed tests:
> FixedDateFormatTest.testFormatLong:162 ABSOLUTE(HH:mm:ss,SSS)/1489305608119
> expected:<0[3]:00:08,119> but was:<0[2]:00:08,119>
> FixedDateFormatTest.testFormatLongCharArrayInt:196
> ABSOLUTE(HH:mm:ss,SSS)/1489305607930 expected:<0[3]:00:07,930> but
> was:<0[2]:00:07,930>
> FixedDateFormatTest.testFormatLongCharArrayInt_goingBackInTime:214
> ABSOLUTE(HH:mm:ss,SSS)/1489381194091 expected:<2[3]:59:54,091> but
> was:<2[2]:59:54,091>
> FixedDateFormatTest.testFormatLong_goingBackInTime:178
> ABSOLUTE(HH:mm:ss,SSS)/1489381194072 expected:<2[3]:59:54,072> but
> was:<2[2]:59:54,072>
> {noformat}
--
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-1849) Broken FixedDateFormat tests when daylight saving time starts
[
https://issues.apache.org/jira/browse/LOG4J2-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926282#comment-15926282
]
Matt Sicker commented on LOG4J2-1849:
-
I see that Japan isn't cursed with daylight saving time. Lucky you ;)
> Broken FixedDateFormat tests when daylight saving time starts
> -
>
> Key: LOG4J2-1849
> URL: https://issues.apache.org/jira/browse/LOG4J2-1849
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8.1
>Reporter: Matt Sicker
>Assignee: Remko Popma
>
> Today we started daylight saving time in the US, and the following tests
> failed:
> {noformat}
> Failed tests:
> FixedDateFormatTest.testFormatLong:162 ABSOLUTE(HH:mm:ss,SSS)/1489305608119
> expected:<0[3]:00:08,119> but was:<0[2]:00:08,119>
> FixedDateFormatTest.testFormatLongCharArrayInt:196
> ABSOLUTE(HH:mm:ss,SSS)/1489305607930 expected:<0[3]:00:07,930> but
> was:<0[2]:00:07,930>
> FixedDateFormatTest.testFormatLongCharArrayInt_goingBackInTime:214
> ABSOLUTE(HH:mm:ss,SSS)/1489381194091 expected:<2[3]:59:54,091> but
> was:<2[2]:59:54,091>
> FixedDateFormatTest.testFormatLong_goingBackInTime:178
> ABSOLUTE(HH:mm:ss,SSS)/1489381194072 expected:<2[3]:59:54,072> but
> was:<2[2]:59:54,072>
> {noformat}
--
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-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924455#comment-15924455 ] Matt Sicker commented on LOG4J2-1359: - Is this performance gain only feasible by directly using the StackWalker API in, for example, LogManager and ClassLoaderContextSelector, or does it still perform well when wrapped by ReflectionUtil (and thus requiring an additional stack frame)? If it's the former, then we're going to end up with several classes with Java 9 specific versions in the multi-jar. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- 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-1851) Move org.apache.logging.log4j.core.net.server package to new module
[ https://issues.apache.org/jira/browse/LOG4J2-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15907508#comment-15907508 ] Matt Sicker commented on LOG4J2-1851: - Can we aim for 2.9 with this? Also, I like the idea of putting it in the new log4j-tools repo. > Move org.apache.logging.log4j.core.net.server package to new module > --- > > Key: LOG4J2-1851 > URL: https://issues.apache.org/jira/browse/LOG4J2-1851 > Project: Log4j 2 > Issue Type: Sub-task > Components: Core >Affects Versions: 2.8.1 >Reporter: Mikael Ståldal >Assignee: Mikael Ståldal > > Move the SocketServer stuff in org.apache.logging.log4j.core.net.server > package to a new module. -- 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-1841) Problems with consequences after LOG4J2-248
[ https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15907505#comment-15907505 ] Matt Sicker commented on LOG4J2-1841: - So then is the servlet class loader not the correct loader here? That's what would be used to find a classpath resource in your WEB-INF directory I thought (sorry, haven't had to program in servlets in a while). > Problems with consequences after LOG4J2-248 > --- > > Key: LOG4J2-1841 > URL: https://issues.apache.org/jira/browse/LOG4J2-1841 > Project: Log4j 2 > Issue Type: Bug > Components: Boot >Affects Versions: 2.8 > Environment: Linux, Tomcat, WebApps >Reporter: Seweryn Habdank-Wojewodzki > > Situation till Log4j v. 2.5 (including it): > 1. One instance of embedded Jetty (programatically started) WITHOUT > definition of the log4j.configurationFile variable. > 2. WAR deployed on within this concrete instance of the embedded Jetty. > 3. WAR internally contains own log4j2.xml file. So every Log4j instance, > which is global for the WebApp, but local for the Jetty, will search and use > configuration in own class path. > Works in the way that every Web-App got own Log4j configuration and will > operate according to own definitions (appenders, layouts, loggers). > In the Log4j v. 2.6 and later in the same setup we are observing the > following: > Log4j in the applications are reporting problem that config file (log4j2.xml) > is not visible. Thus we got message, that Log4j will switch to backup mode > which will write only ERRORs in the console. > We debuged that issue and found that change made in: > https://issues.apache.org/jira/browse/LOG4J2-248 > seems to be the main reason. > We cannot asses if this change was made only with respect to some PMD warning > or it has as well some design considerations in background. > The consequence is that Web Server instance shall define > log4j.configurationFile variable, but also it means ALL WebApps within > Application Container will use one single configuration, what makes > definitely problem, as all WebApps providers must agree on ONE configuration > including appenders configuration, message Layout and so on. > Consider this report and provide solution (or workaround) or maybe just > reasonable comment for the given system setup, please :-). -- 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-1359) Add support for Java 9 StackWalker API in ReflectionUtil
[ https://issues.apache.org/jira/browse/LOG4J2-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15907500#comment-15907500 ] Matt Sicker commented on LOG4J2-1359: - Well that's no good! Have you posted this to the jdk mailing lists, too? In order to access sun.reflect in Java 9, I think we'll have to add some compilation flags as they're trying to hide all their internal APIs that have public equivalents. > Add support for Java 9 StackWalker API in ReflectionUtil > > > Key: LOG4J2-1359 > URL: https://issues.apache.org/jira/browse/LOG4J2-1359 > Project: Log4j 2 > Issue Type: Improvement > Components: API > Environment: Java 1.9+ >Reporter: Matt Sicker >Assignee: Ralph Goers > Labels: jdk9 > > [StackWalker|http://download.java.net/jdk9/docs/api/java/lang/StackWalker.html] > Based on the functional nature of this API, supporting it may require > compiling at least one class using javac 1.9 and reflectively loading it in > ReflectionUtil similar to how Spring supports newer JDK APIs. > Without support for StackWalker, ReflectionUtil will fall back to using a > slower API in Java 1.9. This is because the Reflection class is a > sun-internal class which are no longer exported to non-JDK code without > setting special command line flags. -- 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-1850) Cassendra's integration test fails on Windows
[
https://issues.apache.org/jira/browse/LOG4J2-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-1850.
-
Resolution: Fixed
Fix Version/s: 2.8.2
Thanks for the patch! Applied to master. You can verify and close. Hopefully
this means that the [Windows Jenkins
jobs|https://builds.apache.org/job/Log4jWindows/] will be fully functional now.
> Cassendra's integration test fails on Windows
> -
>
> Key: LOG4J2-1850
> URL: https://issues.apache.org/jira/browse/LOG4J2-1850
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.8.2
> Environment: Windows 10
>Reporter: Ludovic HOCHET
>Assignee: Matt Sicker
>Priority: Minor
> Fix For: 2.8.2
>
> Attachments: patch-log4j2-1850.diff
>
>
> While verifying LOG4J2-1753 I tried to clean build the whole Log4J project,
> it failed during the integration tests of the log4j-nosql module with the
> following:
> {quote}
> --- maven-failsafe-plugin:2.19.1:integration-test (integration-tests) @
> log4j-nosql ---
> file.encoding cannot be set as system property, use
> -Dfile.encoding=... instead
> ---
> T E S T S
> ---
> Running org.apache.logging.log4j.nosql.appender.cassandra.CassandraAppenderIT
> ERROR StatusLogger No log4j2 configuration file found. Using default
> configuration: logging only errors to the console. Set system property
> 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show
> Log4j2 internal initialization logging.
> 23:32:33.958 [Log4j2-TF-1-Cassandra-1] ERROR
> org.apache.cassandra.service.StartupChecks - cassandra.jmx.local.port missing
> from cassandra-env.sh, unable to start local JMX service.
> ERROR StatusLogger No log4j2 configuration file found. Using default
> configuration: logging only errors to the console. Set system property
> 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show
> Log4j2 internal initialization logging.
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> --- maven-failsafe-plugin:2.19.1:verify (verify) @ log4j-nosql ---
>
> BUILD FAILURE
>
> Total time: 29.346 s
> Finished at: 2017-03-12T23:32:49+01:00
> Final Memory: 30M/516M
>
> Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:verify (verify) on
> project log4j-nosql: There was a timeout or other error in the fork -> [Help
> 1]
> To see the full stack trace of the errors, re-run Maven with the -e switch.
> Re-run Maven using the -X switch to enable full debug logging.
> For more information about the errors and possible solutions, please read the
> following articles:
> [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {quote}
--
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] [Assigned] (LOG4J2-1850) Cassendra's integration test fails on Windows
[
https://issues.apache.org/jira/browse/LOG4J2-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker reassigned LOG4J2-1850:
---
Assignee: Matt Sicker
> Cassendra's integration test fails on Windows
> -
>
> Key: LOG4J2-1850
> URL: https://issues.apache.org/jira/browse/LOG4J2-1850
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.8.2
> Environment: Windows 10
>Reporter: Ludovic HOCHET
>Assignee: Matt Sicker
>Priority: Minor
> Attachments: patch-log4j2-1850.diff
>
>
> While verifying LOG4J2-1753 I tried to clean build the whole Log4J project,
> it failed during the integration tests of the log4j-nosql module with the
> following:
> {quote}
> --- maven-failsafe-plugin:2.19.1:integration-test (integration-tests) @
> log4j-nosql ---
> file.encoding cannot be set as system property, use
> -Dfile.encoding=... instead
> ---
> T E S T S
> ---
> Running org.apache.logging.log4j.nosql.appender.cassandra.CassandraAppenderIT
> ERROR StatusLogger No log4j2 configuration file found. Using default
> configuration: logging only errors to the console. Set system property
> 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show
> Log4j2 internal initialization logging.
> 23:32:33.958 [Log4j2-TF-1-Cassandra-1] ERROR
> org.apache.cassandra.service.StartupChecks - cassandra.jmx.local.port missing
> from cassandra-env.sh, unable to start local JMX service.
> ERROR StatusLogger No log4j2 configuration file found. Using default
> configuration: logging only errors to the console. Set system property
> 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show
> Log4j2 internal initialization logging.
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> --- maven-failsafe-plugin:2.19.1:verify (verify) @ log4j-nosql ---
>
> BUILD FAILURE
>
> Total time: 29.346 s
> Finished at: 2017-03-12T23:32:49+01:00
> Final Memory: 30M/516M
>
> Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:verify (verify) on
> project log4j-nosql: There was a timeout or other error in the fork -> [Help
> 1]
> To see the full stack trace of the errors, re-run Maven with the -e switch.
> Re-run Maven using the -X switch to enable full debug logging.
> For more information about the errors and possible solutions, please read the
> following articles:
> [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {quote}
--
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-1850) Cassendra's integration test fails on Windows
[
https://issues.apache.org/jira/browse/LOG4J2-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906733#comment-15906733
]
Matt Sicker commented on LOG4J2-1850:
-
I can't figure out how to apply this patch file properly. Could you use the
output from {{git format-patch}}? Or a pull request would work, too. Thanks for
figuring out why this was failing!
> Cassendra's integration test fails on Windows
> -
>
> Key: LOG4J2-1850
> URL: https://issues.apache.org/jira/browse/LOG4J2-1850
> Project: Log4j 2
> Issue Type: Bug
>Affects Versions: 2.8.2
> Environment: Windows 10
>Reporter: Ludovic HOCHET
>Priority: Minor
> Attachments: patch-log4j2-1850.diff
>
>
> While verifying LOG4J2-1753 I tried to clean build the whole Log4J project,
> it failed during the integration tests of the log4j-nosql module with the
> following:
> {quote}
> --- maven-failsafe-plugin:2.19.1:integration-test (integration-tests) @
> log4j-nosql ---
> file.encoding cannot be set as system property, use
> -Dfile.encoding=... instead
> ---
> T E S T S
> ---
> Running org.apache.logging.log4j.nosql.appender.cassandra.CassandraAppenderIT
> ERROR StatusLogger No log4j2 configuration file found. Using default
> configuration: logging only errors to the console. Set system property
> 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show
> Log4j2 internal initialization logging.
> 23:32:33.958 [Log4j2-TF-1-Cassandra-1] ERROR
> org.apache.cassandra.service.StartupChecks - cassandra.jmx.local.port missing
> from cassandra-env.sh, unable to start local JMX service.
> ERROR StatusLogger No log4j2 configuration file found. Using default
> configuration: logging only errors to the console. Set system property
> 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show
> Log4j2 internal initialization logging.
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> --- maven-failsafe-plugin:2.19.1:verify (verify) @ log4j-nosql ---
>
> BUILD FAILURE
>
> Total time: 29.346 s
> Finished at: 2017-03-12T23:32:49+01:00
> Final Memory: 30M/516M
>
> Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:2.19.1:verify (verify) on
> project log4j-nosql: There was a timeout or other error in the fork -> [Help
> 1]
> To see the full stack trace of the errors, re-run Maven with the -e switch.
> Re-run Maven using the -X switch to enable full debug logging.
> For more information about the errors and possible solutions, please read the
> following articles:
> [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {quote}
--
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-1442) Add generic HTTP verb appender
[ https://issues.apache.org/jira/browse/LOG4J2-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906662#comment-15906662 ] Matt Sicker commented on LOG4J2-1442: - With the newly added JSON escape pattern converter, arbitrary JSON messages can be sent via this plugin which should provide enough functionality to create whatever payload is necessary to use a webhook or basic REST API. > Add generic HTTP verb appender > -- > > Key: LOG4J2-1442 > URL: https://issues.apache.org/jira/browse/LOG4J2-1442 > Project: Log4j 2 > Issue Type: New Feature > Components: Appenders >Reporter: Matt Sicker >Assignee: Mikael Ståldal > > Inspired by [this mailing list > post|http://apache-logging.6191.n7.nabble.com/Custom-appender-needed-to-HTTP-POST-log-msgs-td52921.html]. > This would in one swoop support various APIs such as: > * Slack and other ChatOps software > * ElasticSearch > * ...I'm sure there's more > Basic features that would be needed are: > * HTTP verb > * headers > * body -- 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-1848) Add JSON encoding support to EncodingPatternConverter %encode{}.
[
https://issues.apache.org/jira/browse/LOG4J2-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker closed LOG4J2-1848.
---
Resolution: Fixed
Fix Version/s: 2.8.2
Added to master.
> Add JSON encoding support to EncodingPatternConverter %encode{}.
>
>
> Key: LOG4J2-1848
> URL: https://issues.apache.org/jira/browse/LOG4J2-1848
> Project: Log4j 2
> Issue Type: New Feature
> Components: Layouts
>Reporter: Matt Sicker
>Assignee: Matt Sicker
> Fix For: 2.8.2
>
>
> The existing implementation of EncodingPatternConverter is for escaping
> output for HTML specifically. This pattern converter should be extended to
> allow multiple types of encoding. The existing HTML behavior should be the
> default, but an optional second parameter should be added to allow specifying
> a different format to encode for.
> For JSON, encoding would require the following:
> {noformat}
>The representation of strings is similar to conventions used in the C
>family of programming languages. A string begins and ends with
>quotation marks. All Unicode characters may be placed within the
>quotation marks except for the characters that must be escaped:
>quotation mark, reverse solidus, and the control characters (U+
>through U+001F).
>Any character may be escaped. If the character is in the Basic
>Multilingual Plane (U+ through U+), then it may be
>represented as a six-character sequence: a reverse solidus, followed
>by the lowercase letter u, followed by four hexadecimal digits that
>encode the character's code point. The hexadecimal letters A though
>F can be upper or lowercase. So, for example, a string containing
>only a single reverse solidus character may be represented as
>"\u005C".
>Alternatively, there are two-character sequence escape
>representations of some popular characters. So, for example, a
>string containing only a single reverse solidus character may be
>represented more compactly as "\\".
>To escape an extended character that is not in the Basic Multilingual
>Plane, the character is represented as a twelve-character sequence,
>encoding the UTF-16 surrogate pair. So, for example, a string
>containing only the G clef character (U+1D11E) may be represented as
>"\uD834\uDD1E".
> {noformat}
--
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-1849) Broken FixedDateFormat tests when daylight saving time starts
Matt Sicker created LOG4J2-1849:
---
Summary: Broken FixedDateFormat tests when daylight saving time
starts
Key: LOG4J2-1849
URL: https://issues.apache.org/jira/browse/LOG4J2-1849
Project: Log4j 2
Issue Type: Bug
Components: Core
Affects Versions: 2.8.1
Reporter: Matt Sicker
Today we started daylight saving time in the US, and the following tests failed:
{noformat}
Failed tests:
FixedDateFormatTest.testFormatLong:162 ABSOLUTE(HH:mm:ss,SSS)/1489305608119
expected:<0[3]:00:08,119> but was:<0[2]:00:08,119>
FixedDateFormatTest.testFormatLongCharArrayInt:196
ABSOLUTE(HH:mm:ss,SSS)/1489305607930 expected:<0[3]:00:07,930> but
was:<0[2]:00:07,930>
FixedDateFormatTest.testFormatLongCharArrayInt_goingBackInTime:214
ABSOLUTE(HH:mm:ss,SSS)/1489381194091 expected:<2[3]:59:54,091> but
was:<2[2]:59:54,091>
FixedDateFormatTest.testFormatLong_goingBackInTime:178
ABSOLUTE(HH:mm:ss,SSS)/1489381194072 expected:<2[3]:59:54,072> but
was:<2[2]:59:54,072>
{noformat}
--
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-1848) Add JSON encoding support to EncodingPatternConverter %encode{}.
Matt Sicker created LOG4J2-1848:
---
Summary: Add JSON encoding support to EncodingPatternConverter
%encode{}.
Key: LOG4J2-1848
URL: https://issues.apache.org/jira/browse/LOG4J2-1848
Project: Log4j 2
Issue Type: New Feature
Components: Layouts
Reporter: Matt Sicker
Assignee: Matt Sicker
The existing implementation of EncodingPatternConverter is for escaping output
for HTML specifically. This pattern converter should be extended to allow
multiple types of encoding. The existing HTML behavior should be the default,
but an optional second parameter should be added to allow specifying a
different format to encode for.
For JSON, encoding would require the following:
{noformat}
The representation of strings is similar to conventions used in the C
family of programming languages. A string begins and ends with
quotation marks. All Unicode characters may be placed within the
quotation marks except for the characters that must be escaped:
quotation mark, reverse solidus, and the control characters (U+
through U+001F).
Any character may be escaped. If the character is in the Basic
Multilingual Plane (U+ through U+), then it may be
represented as a six-character sequence: a reverse solidus, followed
by the lowercase letter u, followed by four hexadecimal digits that
encode the character's code point. The hexadecimal letters A though
F can be upper or lowercase. So, for example, a string containing
only a single reverse solidus character may be represented as
"\u005C".
Alternatively, there are two-character sequence escape
representations of some popular characters. So, for example, a
string containing only a single reverse solidus character may be
represented more compactly as "\\".
To escape an extended character that is not in the Basic Multilingual
Plane, the character is represented as a twelve-character sequence,
encoding the UTF-16 surrogate pair. So, for example, a string
containing only the G clef character (U+1D11E) may be represented as
"\uD834\uDD1E".
{noformat}
--
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-1841) Problems with consequences after LOG4J2-248
[ https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906586#comment-15906586 ] Matt Sicker commented on LOG4J2-1841: - Can you give more details on how you're deploying everything? Such as versions. If you're using Jetty 8 at least (which is EOL), you'll have Servlet 3.0 which means that everything should work correctly. The issue in LOG4J2-248 only affects Jetty 6 and 7 [which are pretty old|https://wiki.eclipse.org/Jetty/Starting/Jetty_Version_Comparison_Table]. However, this is an interesting issue determining the correct ClassLoader since it's not being used to load classes but to find the proper LoggerContext/configuration file. This is a very peculiar circumstance, and I think I need more details on your use case to determine the root cause. > Problems with consequences after LOG4J2-248 > --- > > Key: LOG4J2-1841 > URL: https://issues.apache.org/jira/browse/LOG4J2-1841 > Project: Log4j 2 > Issue Type: Bug > Components: Boot >Affects Versions: 2.8 > Environment: Linux, Tomcat, WebApps >Reporter: Seweryn Habdank-Wojewodzki > > Situation till Log4j v. 2.5 (including it): > 1. One instance of embedded Jetty (programatically started) WITHOUT > definition of the log4j.configurationFile variable. > 2. WAR deployed on within this concrete instance of the embedded Jetty. > 3. WAR internally contains own log4j2.xml file. So every Log4j instance, > which is global for the WebApp, but local for the Jetty, will search and use > configuration in own class path. > Works in the way that every Web-App got own Log4j configuration and will > operate according to own definitions (appenders, layouts, loggers). > In the Log4j v. 2.6 and later in the same setup we are observing the > following: > Log4j in the applications are reporting problem that config file (log4j2.xml) > is not visible. Thus we got message, that Log4j will switch to backup mode > which will write only ERRORs in the console. > We debuged that issue and found that change made in: > https://issues.apache.org/jira/browse/LOG4J2-248 > seems to be the main reason. > We cannot asses if this change was made only with respect to some PMD warning > or it has as well some design considerations in background. > The consequence is that Web Server instance shall define > log4j.configurationFile variable, but also it means ALL WebApps within > Application Container will use one single configuration, what makes > definitely problem, as all WebApps providers must agree on ONE configuration > including appenders configuration, message Layout and so on. > Consider this report and provide solution (or workaround) or maybe just > reasonable comment for the given system setup, please :-). -- 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-1843) Line-wise common suffix support for %ex pattern
[
https://issues.apache.org/jira/browse/LOG4J2-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-1843.
-
Resolution: Fixed
Thanks for the pull request! Merged into master. I know I already added the
docs for this in your previous PR, so we should be good there. You can go ahead
and close this if it's all good.
> Line-wise common suffix support for %ex pattern
> ---
>
> Key: LOG4J2-1843
> URL: https://issues.apache.org/jira/browse/LOG4J2-1843
> Project: Log4j 2
> Issue Type: New Feature
> Components: Layouts
>Affects Versions: 2.8.1
>Reporter: Zilong Song
>Assignee: Matt Sicker
> Labels: features
> Fix For: 2.8.2
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The [LOG4J2-1838] issue provide us with the feature to print a common suffix
> to each line of a stack trace. But it only implemented the feature for the
> {{%rEx}} and {{%xEx}} pattern, not yet for the {{%ex}} pattern. This issue is
> intended to implement the feature for the {{%ex}} pattern.
--
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] [Assigned] (LOG4J2-1843) Line-wise common suffix support for %ex pattern
[
https://issues.apache.org/jira/browse/LOG4J2-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker reassigned LOG4J2-1843:
---
Assignee: Matt Sicker
> Line-wise common suffix support for %ex pattern
> ---
>
> Key: LOG4J2-1843
> URL: https://issues.apache.org/jira/browse/LOG4J2-1843
> Project: Log4j 2
> Issue Type: New Feature
> Components: Layouts
>Affects Versions: 2.8.1
>Reporter: Zilong Song
>Assignee: Matt Sicker
> Labels: features
> Fix For: 2.8.2
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The [LOG4J2-1838] issue provide us with the feature to print a common suffix
> to each line of a stack trace. But it only implemented the feature for the
> {{%rEx}} and {{%xEx}} pattern, not yet for the {{%ex}} pattern. This issue is
> intended to implement the feature for the {{%ex}} pattern.
--
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-1842) Expand SystemPropertiesLookup syntax
[
https://issues.apache.org/jira/browse/LOG4J2-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906579#comment-15906579
]
Matt Sicker commented on LOG4J2-1842:
-
I definitely like the idea of this feature, though it seems more appropriate to
be implemented via {{StrSubstitutor}} so that it's available for all
{{StrLookup}} classes. There's already a default value syntax similar to bash
for one of your examples:
{code}
${sys:some.property:defaultValue}
{code}
Though I can't even find where that's documented in the manual.
> Expand SystemPropertiesLookup syntax
>
>
> Key: LOG4J2-1842
> URL: https://issues.apache.org/jira/browse/LOG4J2-1842
> Project: Log4j 2
> Issue Type: Improvement
> Components: Lookups
>Reporter: Mihhail Lapushkin
>Priority: Minor
>
> I've been using a modified version of {{SystemPropertiesLookup}} in my
> project. Maybe it could be part of the library.
> The idea is to allow a series of property keys to be specified. If one of the
> properties is present, then it is used. If none are present, then the default
> value is used. For example:
> {code}
> level="${sys:myapp.log.level|myapp.log.level.dao|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.service|warn}"/>
> level="${sys:myapp.log.level|myapp.log.level.controller|warn}"/>
> {code}
> This allows me to quickly rerun the app with different log levels without
> fiddling with the configuration file or JConsole. Defaults represent
> production settings, so that nothing extra needs to be specified to run the
> app.
> This work nice in other places as well:
> {code}
>
> {code}
> Disables colors by default (for production build), but leaves an easy way to
> turn them on for development.
> When no pipes are present in the expression, then the standard property
> lookup is used, so the change is backwards-compatible.
> Can be a separate lookup if needed.
--
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-1840) Doc issue in example for regex
[
https://issues.apache.org/jira/browse/LOG4J2-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-1840.
-
Resolution: Fixed
Fix Version/s: 2.8.2
Thanks for the pull request! Merged into master. Please verify and close.
I did notice that you linked to the legacy site. We leave that up for archival
usage normally. That link wouldn't get updated with a new release.
> Doc issue in example for regex
> ---
>
> Key: LOG4J2-1840
> URL: https://issues.apache.org/jira/browse/LOG4J2-1840
> Project: Log4j 2
> Issue Type: Documentation
> Components: Documentation
>Reporter: pradeep bala
>Assignee: Matt Sicker
> Fix For: 2.8.2
>
>
> https://logging.apache.org/log4j/log4j-2.3/manual/layouts.html
> replace{pattern}{regex}{substitution}
> has a typo in the example
> "%replace(%msg}{\s}{}"
> fix
> "%replace{%msg}{\s}{}"
--
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] [Assigned] (LOG4J2-1840) Doc issue in example for regex
[
https://issues.apache.org/jira/browse/LOG4J2-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker reassigned LOG4J2-1840:
---
Assignee: Matt Sicker
> Doc issue in example for regex
> ---
>
> Key: LOG4J2-1840
> URL: https://issues.apache.org/jira/browse/LOG4J2-1840
> Project: Log4j 2
> Issue Type: Documentation
> Components: Documentation
>Reporter: pradeep bala
>Assignee: Matt Sicker
>
> https://logging.apache.org/log4j/log4j-2.3/manual/layouts.html
> replace{pattern}{regex}{substitution}
> has a typo in the example
> "%replace(%msg}{\s}{}"
> fix
> "%replace{%msg}{\s}{}"
--
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-1841) Problems with consequences after LOG4J2-248
[ https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15905285#comment-15905285 ] Matt Sicker commented on LOG4J2-1841: - The component properties file is a way to override system properties specific to log4j-api and log4j-core (and other modules under org.apache.logging.log4j). I'm actually not sure if in theory that would work here, but if you're deploying log4j-api in each war, it should work. > Problems with consequences after LOG4J2-248 > --- > > Key: LOG4J2-1841 > URL: https://issues.apache.org/jira/browse/LOG4J2-1841 > Project: Log4j 2 > Issue Type: Bug > Components: Boot >Affects Versions: 2.8 > Environment: Linux, Tomcat, WebApps >Reporter: Seweryn Habdank-Wojewodzki > > Situation till Log4j v. 2.5 (including it): > 1. One instance of embedded Jetty (programatically started) WITHOUT > definition of the log4j.configurationFile variable. > 2. WAR deployed on within this concrete instance of the embedded Jetty. > 3. WAR internally contains own log4j2.xml file. So every Log4j instance, > which is global for the WebApp, but local for the Jetty, will search and use > configuration in own class path. > Works in the way that every Web-App got own Log4j configuration and will > operate according to own definitions (appenders, layouts, loggers). > In the Log4j v. 2.6 and later in the same setup we are observing the > following: > Log4j in the applications are reporting problem that config file (log4j2.xml) > is not visible. Thus we got message, that Log4j will switch to backup mode > which will write only ERRORs in the console. > We debuged that issue and found that change made in: > https://issues.apache.org/jira/browse/LOG4J2-248 > seems to be the main reason. > We cannot asses if this change was made only with respect to some PMD warning > or it has as well some design considerations in background. > The consequence is that Web Server instance shall define > log4j.configurationFile variable, but also it means ALL WebApps within > Application Container will use one single configuration, what makes > definitely problem, as all WebApps providers must agree on ONE configuration > including appenders configuration, message Layout and so on. > Consider this report and provide solution (or workaround) or maybe just > reasonable comment for the given system setup, please :-). -- 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-1841) Problems with consequences after LOG4J2-248
[ https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903451#comment-15903451 ] Matt Sicker commented on LOG4J2-1841: - This is clearly a bug, yes. We should roll it back. > Problems with consequences after LOG4J2-248 > --- > > Key: LOG4J2-1841 > URL: https://issues.apache.org/jira/browse/LOG4J2-1841 > Project: Log4j 2 > Issue Type: Bug > Components: Boot >Affects Versions: 2.8 > Environment: Linux, Tomcat, WebApps >Reporter: Seweryn Habdank-Wojewodzki > > Situation till Log4j v. 2.5 (including it): > 1. One instance of embedded Jetty (programatically started) WITHOUT > definition of the log4j.configurationFile variable. > 2. WAR deployed on within this concrete instance of the embedded Jetty. > 3. WAR internally contains own log4j2.xml file. So every Log4j instance, > which is global for the WebApp, but local for the Jetty, will search and use > configuration in own class path. > Works in the way that every Web-App got own Log4j configuration and will > operate according to own definitions (appenders, layouts, loggers). > In the Log4j v. 2.6 and later in the same setup we are observing the > following: > Log4j in the applications are reporting problem that config file (log4j2.xml) > is not visible. Thus we got message, that Log4j will switch to backup mode > which will write only ERRORs in the console. > We debuged that issue and found that change made in: > https://issues.apache.org/jira/browse/LOG4J2-248 > seems to be the main reason. > We cannot asses if this change was made only with respect to some PMD warning > or it has as well some design considerations in background. > The consequence is that Web Server instance shall define > log4j.configurationFile variable, but also it means ALL WebApps will use one > single configuration, what makes definitely problem, as all WebApps providers > must agree on ONE configuration including appenders configuration, message > Layout and so on. > Consider this report and provide solution (or workaround) or maybe just > reasonable comment for the given system setup, please :-). -- 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-1841) Problems with consequences after LOG4J2-248
[ https://issues.apache.org/jira/browse/LOG4J2-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903170#comment-15903170 ] Matt Sicker commented on LOG4J2-1841: - A workaround is mentioned in the [faq|https://logging.apache.org/log4j/2.x/faq.html#config_location]. Specify log4j.configurationFile inside a log4j2.component.properties file inside the war. > Problems with consequences after LOG4J2-248 > --- > > Key: LOG4J2-1841 > URL: https://issues.apache.org/jira/browse/LOG4J2-1841 > Project: Log4j 2 > Issue Type: Bug > Components: Boot >Affects Versions: 2.8 > Environment: Linux, Tomcat, WebApps >Reporter: Seweryn Habdank-Wojewodzki > > Situation till Log4j v. 2.5 (including it): > 1. One instance of embedded Jetty (programatically started) WITHOUT > definition of the log4j.configurationFile variable. > 2. WAR deployed on within this concrete instance of the embedded Jetty. > 3. WAR internally contains own log4j2.xml file. So every Log4j instance, > which is global for the WebApp, but local for the Jetty, will search and use > configuration in own class path. > Works in the way that every Web-App got own Log4j configuration and will > operate according to own definitions (appenders, layouts, loggers). > In the Log4j v. 2.6 and later in the same setup we are observing the > following: > Log4j in the applications are reporting problem that config file (log4j2.xml) > is not visible. Thus we got message, that Log4j will switch to backup mode > which will write only ERRORs in the console. > We debuged that issue and found that change made in: > https://issues.apache.org/jira/browse/LOG4J2-248 > seems to be the main reason. > We cannot asses if this change was made only with respect to some PMD warning > or it has as well some design considerations in background. > The consequence is that Web Server instance shall define > log4j.configurationFile variable, but also it means ALL WebApps will use one > single configuration, what makes definitely problem, as all WebApps providers > must agree on ONE configuration including appenders configuration, message > Layout and so on. > Consider this report and provide solution (or workaround) or maybe just > reasonable comment for the given system setup, please :-). -- 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=15900686#comment-15900686
]
Matt Sicker commented on LOG4J2-1753:
-
[~lhochet], [~garydgregory]: do you feel that this issue was fixed? I know
there are still open questions about handling this better, but can the issue be
resolved?
> 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
[jira] [Resolved] (LOG4J2-1835) Incorrect license info for jeromq at runtime dependencies page
[ https://issues.apache.org/jira/browse/LOG4J2-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved LOG4J2-1835. - Resolution: Fixed Fix Version/s: 2.8.2 Fixed in master. Please verify and close. > Incorrect license info for jeromq at runtime dependencies page > -- > > Key: LOG4J2-1835 > URL: https://issues.apache.org/jira/browse/LOG4J2-1835 > Project: Log4j 2 > Issue Type: Documentation > Components: Documentation >Affects Versions: 2.8 >Reporter: Konstantin Gribov >Assignee: Matt Sicker >Priority: Minor > Labels: licensing > Fix For: 2.8.2 > > > Log4j2 runtime deps > [documentation|http://logging.apache.org/log4j/2.x/runtime-dependencies.html] > says that JeroMQ is under LGPL but right before v0.3.6 it was relicensed > under MPL-2.0, see > https://repo1.maven.org/maven2/org/zeromq/jeromq/0.3.6/jeromq-0.3.6.pom and > https://github.com/zeromq/jeromq/issues/327 -- 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] [Assigned] (LOG4J2-1835) Incorrect license info for jeromq at runtime dependencies page
[ https://issues.apache.org/jira/browse/LOG4J2-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker reassigned LOG4J2-1835: --- Assignee: Matt Sicker > Incorrect license info for jeromq at runtime dependencies page > -- > > Key: LOG4J2-1835 > URL: https://issues.apache.org/jira/browse/LOG4J2-1835 > Project: Log4j 2 > Issue Type: Documentation > Components: Documentation >Affects Versions: 2.8 >Reporter: Konstantin Gribov >Assignee: Matt Sicker >Priority: Minor > Labels: licensing > > Log4j2 runtime deps > [documentation|http://logging.apache.org/log4j/2.x/runtime-dependencies.html] > says that JeroMQ is under LGPL but right before v0.3.6 it was relicensed > under MPL-2.0, see > https://repo1.maven.org/maven2/org/zeromq/jeromq/0.3.6/jeromq-0.3.6.pom and > https://github.com/zeromq/jeromq/issues/327 -- 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-1838) Add support for appending common suffix to each line of throwable stack trace
[
https://issues.apache.org/jira/browse/LOG4J2-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-1838.
-
Resolution: Fixed
PR merged and some documentation added to the layouts page. I noticed there are
some hidden options in ThrowableFormatOptions that aren't mentioned on the
layouts page, so I added a TODO.
The fix version is marked as 2.8.2 for now, but it may end up being 2.9 since
I'd like to start making larger changes again. Thanks for the PR! Go ahead and
close this if it's all good with you.
> Add support for appending common suffix to each line of throwable stack trace
> -
>
> Key: LOG4J2-1838
> URL: https://issues.apache.org/jira/browse/LOG4J2-1838
> Project: Log4j 2
> Issue Type: New Feature
> Components: Pattern Converters
>Affects Versions: 2.8.1
>Reporter: Zilong Song
>Assignee: Matt Sicker
> Labels: features
> Fix For: 2.8.2
>
>
> Add support for appending common suffix to each line of throwable stack
> trace. The suffix can be configured by patterns just like patterns used
> elsewhere.
> For example, pattern {{%xExsuffix(- %mdckey)}} will
> append a string generated by pattern {{-}} and {{%mdckey}}.
> But patterns that handles throwable will be automatically ignored, because
> they will make the rendered result confusing. So pattern {{%xExsuffix(-
> %rEx%mdckey)}} has the same effect with
> {{%xExsuffix(- %mdckey)}}, as if the nested {{%rEx}}
> pattern has never appeared.
> Following is an example of the with such suffix:
> {code:title=stack trace, with pattern "%xExsuffix(-
> %mdckey)" and MDC(key)="test mdc suffix"|borderStyle=solid}
> java.lang.IllegalArgumentException: IllegalArgument - test mdc suffix
> at
> org.apache.logging.log4j.core.pattern.ExtendedThrowablePatternConverterTest.testSuffixFromNormalPattern(ExtendedThrowablePatternConverterTest.java:48)
> [test-classes/:?] - test mdc suffix
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:1.8.0_91] - test mdc suffix
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.8.0_91] - test mdc suffix
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_91] -
> test mdc suffix
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> [idea_rt.jar:?] - test mdc suffix
> Caused by: java.lang.NullPointerException: null pointer - test mdc suffix
> at
> org.apache.logging.log4j.core.pattern.ExtendedThrowablePatternConverterTest.testSuffixFromNormalPattern(ExtendedThrowablePatternConverterTest.java:47)
> ~[test-classes/:?] - test mdc suffix
> ... 27 more - test mdc suffix
> }}
> {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] [Assigned] (LOG4J2-1838) Add support for appending common suffix to each line of throwable stack trace
[
https://issues.apache.org/jira/browse/LOG4J2-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker reassigned LOG4J2-1838:
---
Assignee: Matt Sicker
> Add support for appending common suffix to each line of throwable stack trace
> -
>
> Key: LOG4J2-1838
> URL: https://issues.apache.org/jira/browse/LOG4J2-1838
> Project: Log4j 2
> Issue Type: New Feature
> Components: Pattern Converters
>Affects Versions: 2.8.1
>Reporter: Zilong Song
>Assignee: Matt Sicker
> Labels: features
> Fix For: 2.8.2
>
>
> Add support for appending common suffix to each line of throwable stack
> trace. The suffix can be configured by patterns just like patterns used
> elsewhere.
> For example, pattern {{%xExsuffix(- %mdckey)}} will
> append a string generated by pattern {{-}} and {{%mdckey}}.
> But patterns that handles throwable will be automatically ignored, because
> they will make the rendered result confusing. So pattern {{%xExsuffix(-
> %rEx%mdckey)}} has the same effect with
> {{%xExsuffix(- %mdckey)}}, as if the nested {{%rEx}}
> pattern has never appeared.
> Following is an example of the with such suffix:
> {code:title=stack trace, with pattern "%xExsuffix(-
> %mdckey)" and MDC(key)="test mdc suffix"|borderStyle=solid}
> java.lang.IllegalArgumentException: IllegalArgument - test mdc suffix
> at
> org.apache.logging.log4j.core.pattern.ExtendedThrowablePatternConverterTest.testSuffixFromNormalPattern(ExtendedThrowablePatternConverterTest.java:48)
> [test-classes/:?] - test mdc suffix
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:1.8.0_91] - test mdc suffix
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.8.0_91] - test mdc suffix
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_91] -
> test mdc suffix
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> [idea_rt.jar:?] - test mdc suffix
> Caused by: java.lang.NullPointerException: null pointer - test mdc suffix
> at
> org.apache.logging.log4j.core.pattern.ExtendedThrowablePatternConverterTest.testSuffixFromNormalPattern(ExtendedThrowablePatternConverterTest.java:47)
> ~[test-classes/:?] - test mdc suffix
> ... 27 more - test mdc suffix
> }}
> {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-1824) (GC) Avoid allocating temporary objects in KafkaAppender
[
https://issues.apache.org/jira/browse/LOG4J2-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15896691#comment-15896691
]
Matt Sicker commented on LOG4J2-1824:
-
There's work being done to port the byte buffer pool stuff to the Consumer API,
so whatever gets done there could be helpful here. See KAFKA-2045.
> (GC) Avoid allocating temporary objects in KafkaAppender
>
>
> Key: LOG4J2-1824
> URL: https://issues.apache.org/jira/browse/LOG4J2-1824
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Reporter: Matt Sicker
>
> Due to API limitations in kafka-clients, log messages must be encoded into
> byte arrays rather than directly into ByteBuffers via
> {{Encoder}}-enhanced layouts. I've opened up KAFKA-4802 to get
> support on the client side for not converting the provided ByteBuffers back
> into a byte array, but in the meantime, KafkaAppender and KafkaManager can be
> enhanced to use the Encoder API.
--
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-1835) Incorrect license info for jeromq at runtime dependencies page
[ https://issues.apache.org/jira/browse/LOG4J2-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894963#comment-15894963 ] Matt Sicker commented on LOG4J2-1835: - Oh I had totally forgotten that MPL is weak copyleft. That's actually a decent license to use, too. I'd much prefer they used it instead of using a modified GPL or LGPL (it's a lot easier to convince corporate types to allow usage of specific licenses, but it's a lot more annoying to submit specific license mods to the lawyers). > Incorrect license info for jeromq at runtime dependencies page > -- > > Key: LOG4J2-1835 > URL: https://issues.apache.org/jira/browse/LOG4J2-1835 > Project: Log4j 2 > Issue Type: Documentation > Components: Documentation >Affects Versions: 2.8 >Reporter: Konstantin Gribov >Priority: Minor > Labels: licensing > > Log4j2 runtime deps > [documentation|http://logging.apache.org/log4j/2.x/runtime-dependencies.html] > says that JeroMQ is under LGPL but right before v0.3.6 it was relicensed > under MPL-2.0, see > https://repo1.maven.org/maven2/org/zeromq/jeromq/0.3.6/jeromq-0.3.6.pom and > https://github.com/zeromq/jeromq/issues/327 -- 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-1824) (GC) Avoid allocating temporary objects in KafkaAppender
[
https://issues.apache.org/jira/browse/LOG4J2-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894693#comment-15894693
]
Matt Sicker commented on LOG4J2-1824:
-
An unrolled Producer method would certainly allow for them to support it. I
haven't gotten any response yet on my original ticket. I wonder how their
community process is over there and if we can contribute the updates. Being
able to rapidly send Kafka messages is a pretty useful use case for Kafka, so
reducing or eliminating garbage in the producer seems like a logical feature to
include.
> (GC) Avoid allocating temporary objects in KafkaAppender
>
>
> Key: LOG4J2-1824
> URL: https://issues.apache.org/jira/browse/LOG4J2-1824
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Reporter: Matt Sicker
>
> Due to API limitations in kafka-clients, log messages must be encoded into
> byte arrays rather than directly into ByteBuffers via
> {{Encoder}}-enhanced layouts. I've opened up KAFKA-4802 to get
> support on the client side for not converting the provided ByteBuffers back
> into a byte array, but in the meantime, KafkaAppender and KafkaManager can be
> enhanced to use the Encoder API.
--
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-1824) (GC) Avoid allocating temporary objects in KafkaAppender
[
https://issues.apache.org/jira/browse/LOG4J2-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894656#comment-15894656
]
Matt Sicker commented on LOG4J2-1824:
-
Then it seems the only way to implement this would be via changes in
kafka-clients or by using a different Kafka client library entirely.
> (GC) Avoid allocating temporary objects in KafkaAppender
>
>
> Key: LOG4J2-1824
> URL: https://issues.apache.org/jira/browse/LOG4J2-1824
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Reporter: Matt Sicker
>
> Due to API limitations in kafka-clients, log messages must be encoded into
> byte arrays rather than directly into ByteBuffers via
> {{Encoder}}-enhanced layouts. I've opened up KAFKA-4802 to get
> support on the client side for not converting the provided ByteBuffers back
> into a byte array, but in the meantime, KafkaAppender and KafkaManager can be
> enhanced to use the Encoder API.
--
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-1824) (GC) Avoid allocating temporary objects in KafkaAppender
[
https://issues.apache.org/jira/browse/LOG4J2-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894651#comment-15894651
]
Matt Sicker commented on LOG4J2-1824:
-
We can reuse ProducerRecord objects I bet. Since the KafkaProducer method
itself is async, we'd have to keep a configurable pool of ProducerRecords that
get returned via the callback function provided to KafkaProducer. Then we can
have a strategy for how to handle the pool emptying: block, expand the pool, or
just use garbage-collected objects at that point.
> (GC) Avoid allocating temporary objects in KafkaAppender
>
>
> Key: LOG4J2-1824
> URL: https://issues.apache.org/jira/browse/LOG4J2-1824
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Reporter: Matt Sicker
>
> Due to API limitations in kafka-clients, log messages must be encoded into
> byte arrays rather than directly into ByteBuffers via
> {{Encoder}}-enhanced layouts. I've opened up KAFKA-4802 to get
> support on the client side for not converting the provided ByteBuffers back
> into a byte array, but in the meantime, KafkaAppender and KafkaManager can be
> enhanced to use the Encoder API.
--
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-1835) Incorrect license info for jeromq at runtime dependencies page
[ https://issues.apache.org/jira/browse/LOG4J2-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15894630#comment-15894630 ] Matt Sicker commented on LOG4J2-1835: - Yes, that log4j-core link is generated by Maven, and the page in the description is written manually. That's an interesting update. As a free software advocate, I encourage the use of GPL and LGPL in applications and libraries, but that also causes people issues. I wonder why they decided to use MPL instead of Apache? > Incorrect license info for jeromq at runtime dependencies page > -- > > Key: LOG4J2-1835 > URL: https://issues.apache.org/jira/browse/LOG4J2-1835 > Project: Log4j 2 > Issue Type: Documentation > Components: Documentation >Affects Versions: 2.8 >Reporter: Konstantin Gribov >Priority: Minor > Labels: licensing > > Log4j2 runtime deps > [documentation|http://logging.apache.org/log4j/2.x/runtime-dependencies.html] > says that JeroMQ is under LGPL but right before v0.3.6 it was relicensed > under MPL-2.0, see > https://repo1.maven.org/maven2/org/zeromq/jeromq/0.3.6/jeromq-0.3.6.pom and > https://github.com/zeromq/jeromq/issues/327 -- 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=15892437#comment-15892437 ] Matt Sicker commented on LOG4J2-1820: - There's a good wiki page about this over on the Commons wiki actually: https://wiki.apache.org/commons/UsingGIT Found out about another hidden GitHub feature that we can use to merge pull requests by setting up an additional remote to GitHub. All PRs are provided as read-only branches to the main project (but our GitHub mirrors are read-only as it is, so this doesn't change anything). I'm guessing when you check the box to allow maintainers to make changes to your PR, that makes the pull branch read-write, but again, same limitation with our mirroring. > 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=15891636#comment-15891636
]
Matt Sicker commented on LOG4J2-1820:
-
There are two main ways to properly merge a PR from GitHub without using the UI
(which is related to this method of patch file attachments; bear with me for a
sec):
* Use the {{git pull}} command provided in the original GitHub notification
email. It fetches and merges from a different remote than what you normally
use, and when you push it to your normal remote (usually named "origin"; that's
the default at least) on apache.org, that marks the PR as merged on GitHub.
* Download the patch file by adding .patch to the URL. I just checked earlier
and adding .diff to the URL provides just the output of diff while the .patch
URL provides the output of {{git format-patch}} which is the same format that
was used in the patch file attached to this ticket. Apply this patch with the
command {{git apply foo.patch}}. You could also shorten it a bit by doing
{{curl http://whatever/foo.patch | git apply}}, but I don't know how that works
in Windows. In general, you should just be able to use {{git apply}} (or
{{git-apply}}; I don't know how git is bundled for Windows) and that will apply
the committer/author info and other metadata included in the patch so that it's
applied like a pull request.
* The third bonus way is via {{git am}}, but that's more so for people like
Linus Torvalds who use a command line mail client and still have mbox/maildir
emails which contain the patch file attachments. Considering our mailing list
software rarely propagates attachments, that's not really relevant here.
> 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=15891164#comment-15891164
]
Matt Sicker commented on LOG4J2-1820:
-
We accept PRs, but we can't just click the button in GitHub to do it. We have
to pull it the old-fashioned way (via the URL), add a commit saying that it
closes a particular GH #, and then push that to apache.org. That marks it as
merged and closed via GH.
I normally use git from the command line, but I'm guessing Gary is using EGit.
I have no idea if it supports {{git-am}} or related functions.
> 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=15891095#comment-15891095
]
Matt Sicker commented on LOG4J2-1820:
-
It's easier to apply that properly as a pull request. Since you used {{git
format-patch}}, it looks like the metadata wasn't applied properly.
> 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-1827) Separate integration tests out of core to speed up build
[ https://issues.apache.org/jira/browse/LOG4J2-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15888170#comment-15888170 ] Matt Sicker commented on LOG4J2-1827: - Glad to see you figured out why this was happening. :) > Separate integration tests out of core to speed up build > > > Key: LOG4J2-1827 > URL: https://issues.apache.org/jira/browse/LOG4J2-1827 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Affects Versions: 2.8 >Reporter: Ralph Goers > Fix For: 2.8.2 > > > The build of the core module experiences a long pause after running the unit > tests while the failsafe plugin looks for integration tests to run. By moving > the integration tests to their own module the pause will be eliminated. -- 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-1827) Separate integration tests out of core to speed up build
[ https://issues.apache.org/jira/browse/LOG4J2-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15887425#comment-15887425 ] Matt Sicker commented on LOG4J2-1827: - It might be simpler to put it in its own directory within log4j-core/src/it/java/ or something similar. > Separate integration tests out of core to speed up build > > > Key: LOG4J2-1827 > URL: https://issues.apache.org/jira/browse/LOG4J2-1827 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Affects Versions: 2.8 >Reporter: Ralph Goers > Fix For: 2.8.2 > > > The build of the core module experiences a long pause after running the unit > tests while the failsafe plugin looks for integration tests to run. By moving > the integration tests to their own module the pause will be eliminated. -- 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-174) Multiple instances of same application server cause 2 problems - want to know if they are solved in log4j 2
[
https://issues.apache.org/jira/browse/LOG4J2-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15887102#comment-15887102
]
Matt Sicker commented on LOG4J2-174:
I'd also suggest a database appender like the new Cassandra appender, but I
can't imagine that's much faster than all the file locking needed to implement
that prudent mode feature.
> Multiple instances of same application server cause 2 problems - want to know
> if they are solved in log4j 2
> ---
>
> Key: LOG4J2-174
> URL: https://issues.apache.org/jira/browse/LOG4J2-174
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
> Environment: Unix based OS and Java based application servers
>Reporter: Jas Gill
>
> When we start multiple instances of application server using log4j 1.2 and
> all instances read same configuration file, two problems are noticed.
> 1. At rollover time first app server doing rollover will do its job properly
> but when subsequent ones will do rollover again and we lose logs. May be
> log4j should check that if rolled over file is already present, it should
> skip rollover.
> 2. After rollover only one instance is logging and others stop logging. The
> problem is that the active file was rolled over and new file is created. Only
> one server has pointer to it.
>class="org.apache.log4j.rolling.RollingFileAppender">
>
>
>class="org.apache.log4j.rolling.TimeBasedRollingPolicy">
>value="${LOG_FILE}.%d{-MM-dd-HH-mm}" />
>
>
>
>
>
>
>
--
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-174) Multiple instances of same application server cause 2 problems - want to know if they are solved in log4j 2
[
https://issues.apache.org/jira/browse/LOG4J2-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15887101#comment-15887101
]
Matt Sicker commented on LOG4J2-174:
If you read the docs, prudent mode is slow. If you want to aggregate multiple
applications' log files, there are many better ways of handling it:
* Use a networked appender such as Graylog, Kafka, Flume, ZeroMQ, etc.
* Use Logstash or Splunk or similar to read the files on multiple machines and
aggregate them.
* Take advantage of things like Docker which make it easy to log to
stdout/stderr and use a log driver in Docker to route them somewhere (like
Graylog, Kafka, Flume, etc.).
> Multiple instances of same application server cause 2 problems - want to know
> if they are solved in log4j 2
> ---
>
> Key: LOG4J2-174
> URL: https://issues.apache.org/jira/browse/LOG4J2-174
> Project: Log4j 2
> Issue Type: Question
> Components: Appenders
> Environment: Unix based OS and Java based application servers
>Reporter: Jas Gill
>
> When we start multiple instances of application server using log4j 1.2 and
> all instances read same configuration file, two problems are noticed.
> 1. At rollover time first app server doing rollover will do its job properly
> but when subsequent ones will do rollover again and we lose logs. May be
> log4j should check that if rolled over file is already present, it should
> skip rollover.
> 2. After rollover only one instance is logging and others stop logging. The
> problem is that the active file was rolled over and new file is created. Only
> one server has pointer to it.
>class="org.apache.log4j.rolling.RollingFileAppender">
>
>
>class="org.apache.log4j.rolling.TimeBasedRollingPolicy">
>value="${LOG_FILE}.%d{-MM-dd-HH-mm}" />
>
>
>
>
>
>
>
--
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-1824) (GC) Avoid allocating temporary objects in KafkaAppender
[
https://issues.apache.org/jira/browse/LOG4J2-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15885154#comment-15885154
]
Matt Sicker commented on LOG4J2-1824:
-
Based on some mailing list discussions, it may be possible that the
{{ByteBufferDestination.drain(ByteBuffer)}} method could be used here.
Honestly, to properly implement this may require some interesting changes to
kafka-clients (e.g., a ByteBufferDestination-like interface for writing
directly to a message while it's being prepared to be sent over the network so
we can buffer a log message without splitting it into multiple kafka messages).
This is definitely going to require more research to handle properly.
It may be possible that GatheringByteChannel may be useful here.
> (GC) Avoid allocating temporary objects in KafkaAppender
>
>
> Key: LOG4J2-1824
> URL: https://issues.apache.org/jira/browse/LOG4J2-1824
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Reporter: Matt Sicker
>
> Due to API limitations in kafka-clients, log messages must be encoded into
> byte arrays rather than directly into ByteBuffers via
> {{Encoder}}-enhanced layouts. I've opened up KAFKA-4802 to get
> support on the client side for not converting the provided ByteBuffers back
> into a byte array, but in the meantime, KafkaAppender and KafkaManager can be
> enhanced to use the Encoder API.
--
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-1636) Console Appender does not pick up Oracle Java 8's sun.stdout.encoding and sun.stderr.encoding
[
https://issues.apache.org/jira/browse/LOG4J2-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-1636.
-
Resolution: Fixed
Fix Version/s: 2.8
2.8.1
Marking this fixed as it was included in the changelog and fixed some more in
2.8.1.
> Console Appender does not pick up Oracle Java 8's sun.stdout.encoding and
> sun.stderr.encoding
> --
>
> Key: LOG4J2-1636
> URL: https://issues.apache.org/jira/browse/LOG4J2-1636
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Layouts
> Environment: Windows
>Reporter: Eldar Gabdullin
>Assignee: Gary Gregory
> Fix For: 2.8.1, 2.8
>
>
> The Oracle Java 8 platform supports two system properties to configure the
> System console: sun.stdout.encoding and sun.stderr.encoding.
>
> Default log4j configuration prints to console using platform's default
> encoding, however that's not what standard windows console expects.
> I.e.
> {code}
> System.out.println("Поехали"); // works just fine
> System.out.write("Поехали!\n".getBytes(Charset.defaultCharset())); //
> characters are messed up
> log.info("Поехали"); // messed up in the same way
> {code}
> This happens not just on one machine, but on all Windows desktops and servers
> in our organization.
> Can we have out of the box Layout/Appender which prints directly to
> System.out/err?
--
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-1825) Log4j2 throwing an error in Windows bash console
[ https://issues.apache.org/jira/browse/LOG4J2-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884173#comment-15884173 ] Matt Sicker commented on LOG4J2-1825: - This sounds likely to be the same issue as LOG4J2-1799. Could you try with the latest snapshot? Repository: https://repository.apache.org/content/repositories/snapshots/ Version: 2.8.1-SNAPSHOT > Log4j2 throwing an error in Windows bash console > > > Key: LOG4J2-1825 > URL: https://issues.apache.org/jira/browse/LOG4J2-1825 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.8 > Environment: Windows 7 (at least) >Reporter: Adonis Settouf > Attachments: log4j2.properties, ms-dos-stacktrace > > > Good morning, > using log4j2 in my project (see below the configuration) running it, > everything went ok in Eclipse. Then building the jar and executing it in a > bash Windows, I get an error thrown regarding the "Console Appender". After > investigation, it works in other shells (like git bash), my question here is > about if this behavior is documented somewhere ?(because after googling it a > lot, I did not find anything relevant). > See the attached files for the properties file and the stacktrace as Jira > does not handle well (or I don't know how) the formatting of 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-1797) Add asynchronous/non-blocking SPIs for appenders
[ https://issues.apache.org/jira/browse/LOG4J2-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884153#comment-15884153 ] Matt Sicker commented on LOG4J2-1797: - I found a potentially useful interface already in Java for a callback: [CompletionHandler|https://docs.oracle.com/javase/8/docs/api/java/nio/channels/CompletionHandler.html]. > Add asynchronous/non-blocking SPIs for appenders > > > Key: LOG4J2-1797 > URL: https://issues.apache.org/jira/browse/LOG4J2-1797 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Reporter: Matt Sicker > > Some appenders (e.g., Kafka and Cassandra) support using an asynchronous SPI > with callbacks (to make them non-blocking). In a Scala-based API, this could > be easily handled with the Future class, and with Java 8, this could be > easily handled with a CompleteableFuture class. However, if this API > improvement is desired for Java 7, then we'd need to create a basic callback > API that would ideally be easy to update to CompleteableFuture later on. > In theory, such an SPI could also be adapted to use the Flow classes in Java > 9. This may be an interesting API to follow as we could use the Reactive > Streams standard API or a compatible API. > Some main things that would be desirable in such an SPI would include > asynchronous error handling (e.g., to trigger a failover appender). This > should be adapted to work well with the generic AsyncAppender and AsyncLogger > as well. -- 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-1824) (GC) Avoid allocating temporary objects in KafkaAppender
[
https://issues.apache.org/jira/browse/LOG4J2-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884139#comment-15884139
]
Matt Sicker commented on LOG4J2-1824:
-
One possible caveat: in Kafka, log messages are sent individually as messages.
Thus, the pattern of continually transferring to ByteBuffers and draining them
to continue writing larger messages wouldn't exactly work here. Instead, either
some garbage has to be made in resizing buffers like in some ReusableMessage
implementations, or a pool of differently sized buffers can be preallocated
(doesn't sound ideal, but could be configurable for that sort of scenario where
it would make sense).
> (GC) Avoid allocating temporary objects in KafkaAppender
>
>
> Key: LOG4J2-1824
> URL: https://issues.apache.org/jira/browse/LOG4J2-1824
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Reporter: Matt Sicker
>
> Due to API limitations in kafka-clients, log messages must be encoded into
> byte arrays rather than directly into ByteBuffers via
> {{Encoder}}-enhanced layouts. I've opened up KAFKA-4802 to get
> support on the client side for not converting the provided ByteBuffers back
> into a byte array, but in the meantime, KafkaAppender and KafkaManager can be
> enhanced to use the Encoder API.
--
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-1824) (GC) Avoid allocating temporary objects in KafkaAppender
[
https://issues.apache.org/jira/browse/LOG4J2-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884136#comment-15884136
]
Matt Sicker commented on LOG4J2-1824:
-
I also found this [alternative Kafka client
library|https://github.com/blackberry/Krackle/] from the Kafka wiki if it turns
out that decreasing temporary objects in the client itself is too difficult.
> (GC) Avoid allocating temporary objects in KafkaAppender
>
>
> Key: LOG4J2-1824
> URL: https://issues.apache.org/jira/browse/LOG4J2-1824
> Project: Log4j 2
> Issue Type: Improvement
> Components: Appenders
>Reporter: Matt Sicker
>
> Due to API limitations in kafka-clients, log messages must be encoded into
> byte arrays rather than directly into ByteBuffers via
> {{Encoder}}-enhanced layouts. I've opened up KAFKA-4802 to get
> support on the client side for not converting the provided ByteBuffers back
> into a byte array, but in the meantime, KafkaAppender and KafkaManager can be
> enhanced to use the Encoder API.
--
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-1824) (GC) Avoid allocating temporary objects in KafkaAppender
Matt Sicker created LOG4J2-1824:
---
Summary: (GC) Avoid allocating temporary objects in KafkaAppender
Key: LOG4J2-1824
URL: https://issues.apache.org/jira/browse/LOG4J2-1824
Project: Log4j 2
Issue Type: Improvement
Components: Appenders
Reporter: Matt Sicker
Due to API limitations in kafka-clients, log messages must be encoded into byte
arrays rather than directly into ByteBuffers via {{Encoder}}-enhanced
layouts. I've opened up KAFKA-4802 to get support on the client side for not
converting the provided ByteBuffers back into a byte array, but in the
meantime, KafkaAppender and KafkaManager can be enhanced to use the Encoder API.
--
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-1797) Add asynchronous/non-blocking SPIs for appenders
[ https://issues.apache.org/jira/browse/LOG4J2-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884060#comment-15884060 ] Matt Sicker commented on LOG4J2-1797: - I just had a thought that if we support callback based asynchronous completion, then we can more reliably wait for a clean shutdown in asynchronous appenders. > Add asynchronous/non-blocking SPIs for appenders > > > Key: LOG4J2-1797 > URL: https://issues.apache.org/jira/browse/LOG4J2-1797 > Project: Log4j 2 > Issue Type: Improvement > Components: Appenders >Reporter: Matt Sicker > > Some appenders (e.g., Kafka and Cassandra) support using an asynchronous SPI > with callbacks (to make them non-blocking). In a Scala-based API, this could > be easily handled with the Future class, and with Java 8, this could be > easily handled with a CompleteableFuture class. However, if this API > improvement is desired for Java 7, then we'd need to create a basic callback > API that would ideally be easy to update to CompleteableFuture later on. > In theory, such an SPI could also be adapted to use the Flow classes in Java > 9. This may be an interesting API to follow as we could use the Reactive > Streams standard API or a compatible API. > Some main things that would be desirable in such an SPI would include > asynchronous error handling (e.g., to trigger a failover appender). This > should be adapted to work well with the generic AsyncAppender and AsyncLogger > as well. -- 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=15884058#comment-15884058
]
Matt Sicker commented on LOG4J2-1807:
-
I feel that only a few major classes from log4j-core are meant to maintain
backwards compatibility. Really, as long as custom plugins can extend abstract
classes that always compile and link correctly, and as long as we keep the old
plugin factory methods from programmatic configurations, I think that covers
most of the expected classes. Really, anything that's documented in the manual
should maintain strict API compatibility where possible.
> [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-1823) Remove deprecation on MessageSupplier lambda functions in Logger API
[
https://issues.apache.org/jira/browse/LOG4J2-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker closed LOG4J2-1823.
---
Resolution: Fixed
Changed in master.
> Remove deprecation on MessageSupplier lambda functions in Logger API
>
>
> Key: LOG4J2-1823
> URL: https://issues.apache.org/jira/browse/LOG4J2-1823
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
>Affects Versions: 2.6
>Reporter: Matt Sicker
>Assignee: Matt Sicker
> Fix For: 2.8.1
>
>
> The changes done in LOG4J2-1286 to deprecate MessageSupplier were not
> properly tested in practice. Using log4j-api ever since the deprecation, the
> following code causes deprecation warnings:
> {code}
> logger.info(() -> new SimpleMessage("Hello, world!"));
> {code}
> This is because the compiler interprets this as a {{MessageSupplier}} instead
> of the more generic {{Supplier}} version which is the intended API.
> Although manual use of {{MessageSupplier}} should be discouraged, users
> should not have to manually cast the above lambda just to prevent a
> deprecation warning:
> {code}
> logger.info((Supplier) () -> new SimpleMessage("Hello, world!"));
> {code}
> {{MessageSupplier}} should become a normal part of log4j-api with a note on
> both it and {{Supplier}} that these interfaces would be removed in a
> log4j-api 3.0 release and replaced with the Java 8 version.
--
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-1823) Remove deprecation on MessageSupplier lambda functions in Logger API
Matt Sicker created LOG4J2-1823:
---
Summary: Remove deprecation on MessageSupplier lambda functions in
Logger API
Key: LOG4J2-1823
URL: https://issues.apache.org/jira/browse/LOG4J2-1823
Project: Log4j 2
Issue Type: Improvement
Components: API
Affects Versions: 2.6
Reporter: Matt Sicker
Assignee: Matt Sicker
Fix For: 2.8.1
The changes done in LOG4J2-1286 to deprecate MessageSupplier were not properly
tested in practice. Using log4j-api ever since the deprecation, the following
code causes deprecation warnings:
{code}
logger.info(() -> new SimpleMessage("Hello, world!"));
{code}
This is because the compiler interprets this as a {{MessageSupplier}} instead
of the more generic {{Supplier}} version which is the intended API.
Although manual use of {{MessageSupplier}} should be discouraged, users should
not have to manually cast the above lambda just to prevent a deprecation
warning:
{code}
logger.info((Supplier) () -> new SimpleMessage("Hello, world!"));
{code}
{{MessageSupplier}} should become a normal part of log4j-api with a note on
both it and {{Supplier}} that these interfaces would be removed in a
log4j-api 3.0 release and replaced with the Java 8 version.
--
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=15879919#comment-15879919 ] Matt Sicker commented on LOG4J2-1820: - The patch is fine, yes. We can take a closer look at broader SecurityManager testing in a separate issue. > 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=15877473#comment-15877473
]
Matt Sicker commented on LOG4J2-1820:
-
There appears to be a possibly useful method in {{Loader.getClassLoader(Class,
Class)}} that is commented with "TODO: this method could use some explanation".
Wrapping the {{Class.getClassLoader()}} into that method will fall back on an
accessible ClassLoader regardless.
> 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=15877466#comment-15877466
]
Matt Sicker commented on LOG4J2-1820:
-
The use of {{ClassLoader.getParent()}} also requires a security check in
ClassLoaderContextSelector.
As for running tests with a custom SecurityManager, I think a basic TestRule
parameter could be parameterized via @Params.
> 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=15877454#comment-15877454
]
Matt Sicker commented on LOG4J2-1820:
-
Ok, I looked into the JDK7 source code for more details since the javadocs
didn't mention it. {{Class.forName(String)}} does not do any security manager
access checks at all. And technically, a getClassLoader permission check is
only needed when the calling class's ClassLoader is not the same as or a parent
of the target ClassLoader.
{quote}
If a security manager is present, and the caller's class loader is not null and
the caller's class loader is not the same as or an ancestor of the class loader
for the class whose class loader is requested, then this method calls the
security manager's checkPermission method with a
RuntimePermission("getClassLoader") permission to ensure it's ok to access the
class loader for the class.
{quote}
In that case, you could fall back to the calling class's ClassLoader I suppose.
Or a ClassLoader/Class.forName sort of abstraction (which could possibly help
with OSGi and other exotic ClassLoader environments).
> 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=15877437#comment-15877437 ] Matt Sicker commented on LOG4J2-1820: - There's a check in LoaderUtil for the getClassLoader permission already. If you don't have that, then good luck running almost anything that isn't fully custom code. With the security check for getting a ClassLoader, the possibility of a ClassLoader being null (which indicates the root ClassLoader basically), and various other edge cases, it almost makes me think that this is a class that needs to be abstracted, though I think it'd probably be overkill. > 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-1630) Unit of Work Logging
[ https://issues.apache.org/jira/browse/LOG4J2-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15872095#comment-15872095 ] Matt Sicker commented on LOG4J2-1630: - After rereading the description, yes, this isn't really all that related to Zipkin itself, but I guess my idea was more so along the following: In microservice architectures, I'd imagine that this unit of work can span between multiple services. In Zipkin, you'd keep track of (at minimum) client and server request and response times along with some configurable metadata (generally per-service like service name, HTTP paths, response codes, errors, etc.) that also get passed between services. In the case of unit of work logging, the unit of work could potentially span between services in a request-reply fashion, or it might just be fully message-driven with no end on the original service. Anyways, what I'm thinking of sounds like a more complicated extension to this ticket. > Unit of Work Logging > > > Key: LOG4J2-1630 > URL: https://issues.apache.org/jira/browse/LOG4J2-1630 > Project: Log4j 2 > Issue Type: Story > Components: API, Core, Filters >Affects Versions: 2.7 >Reporter: Remko Popma > Fix For: 2.9 > > > h3. Intent > Provide a way to filter log events, where the decision on whether to discard > the message or actually log them cannot be made until after the application > has already logged the message. > h3. Motivation > In many systems, particularly event processing applications, log files > contain a lot of repetitive log messages. Suppose an application needs to do > some calculation to decide whether or not to react to some event, and a lot > of detail is logged during this calculation. Imagine that 99% of the time, > the application decides to take no action. Once the application arrived at > that conclusion it would be nice if we could go back and undo all the > detailed logging and print a summary instead. When the application _does_ > decide to take some action, however, we _do_ want the detailed log messages. > A Unit of Work for logging would allow us to group a set of log messages and > either discard them or log them together. (Inspired by Martin Fowler's [Unit > of Work|http://martinfowler.com/eaaCatalog/unitOfWork.html] pattern.) > This should result in log files where a lot of the "uninteresting" logging is > filtered out, significantly reducing the amount of data logged. > Some applications do this in an ad hoc manner, for example by passing a > Collection to its components, where these components can add log message > strings to this Collection. When the discard/retain decision is made, the > application then either clears the Collection or logs the contents of the > Collection. This works, but having to pass the Collection down the component > tree is clunky and the result often omits details like logger name, timestamp > and other details that come for free with normal logging. Log4j can provide a > reusable and less intrusive way to accomplish this. > h3. How it works > There would need to be some API for the application to mark the _start_ of > the unit of work, and some API to signal whether the log messages that are > part of that unit of work need to be _discarded_ or _logged_ (retained). > Not all logging that occurs after a unit of work was started is part of that > unit of work. The application may want some messages to be logged regardless > of whether the unit of work was discarded or not. There needs to be a > flexible way (or multiple ways) to include or exclude logging statements from > the unit of work. > The application may also designate multiple units of work, which may be > sequential, nested or partially overlapping. Each unit of work may define its > own rules for which log messages are considered included in or excluded from > the unit of work. -- 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-1630) Unit of Work Logging
[ https://issues.apache.org/jira/browse/LOG4J2-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15870647#comment-15870647 ] Matt Sicker commented on LOG4J2-1630: - Would you say that this sort of thing is related at all to distributed log tracing a la [Zipkin|http://zipkin.io/]? Could have some common nomenclature at least. > Unit of Work Logging > > > Key: LOG4J2-1630 > URL: https://issues.apache.org/jira/browse/LOG4J2-1630 > Project: Log4j 2 > Issue Type: Story > Components: API, Core, Filters >Affects Versions: 2.7 >Reporter: Remko Popma > Fix For: 2.9 > > > h3. Intent > Provide a way to filter log events, where the decision on whether to discard > the message or actually log them cannot be made until after the application > has already logged the message. > h3. Motivation > In many systems, particularly event processing applications, log files > contain a lot of repetitive log messages. Suppose an application needs to do > some calculation to decide whether or not to react to some event, and a lot > of detail is logged during this calculation. Imagine that 99% of the time, > the application decides to take no action. Once the application arrived at > that conclusion it would be nice if we could go back and undo all the > detailed logging and print a summary instead. When the application _does_ > decide to take some action, however, we _do_ want the detailed log messages. > A Unit of Work for logging would allow us to group a set of log messages and > either discard them or log them together. (Inspired by Martin Fowler's [Unit > of Work|http://martinfowler.com/eaaCatalog/unitOfWork.html] pattern.) > This should result in log files where a lot of the "uninteresting" logging is > filtered out, significantly reducing the amount of data logged. > Some applications do this in an ad hoc manner, for example by passing a > Collection to its components, where these components can add log message > strings to this Collection. When the discard/retain decision is made, the > application then either clears the Collection or logs the contents of the > Collection. This works, but having to pass the Collection down the component > tree is clunky and the result often omits details like logger name, timestamp > and other details that come for free with normal logging. Log4j can provide a > reusable and less intrusive way to accomplish this. > h3. How it works > There would need to be some API for the application to mark the _start_ of > the unit of work, and some API to signal whether the log messages that are > part of that unit of work need to be _discarded_ or _logged_ (retained). > Not all logging that occurs after a unit of work was started is part of that > unit of work. The application may want some messages to be logged regardless > of whether the unit of work was discarded or not. There needs to be a > flexible way (or multiple ways) to include or exclude logging statements from > the unit of work. > The application may also designate multiple units of work, which may be > sequential, nested or partially overlapping. Each unit of work may define its > own rules for which log messages are considered included in or excluded from > the unit of work. -- 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-1691) Setup build process for new Git repo logging-log4j-scala, including site
[ https://issues.apache.org/jira/browse/LOG4J2-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15866097#comment-15866097 ] Matt Sicker commented on LOG4J2-1691: - I haven't had time lately to finish this, but in theory, yeah, I think so. I'm not exactly sure on how to deploy a partial site like this or how releases of Log4j versus Log4j Scala API would coordinate site updates. > Setup build process for new Git repo logging-log4j-scala, including site > > > Key: LOG4J2-1691 > URL: https://issues.apache.org/jira/browse/LOG4J2-1691 > Project: Log4j 2 > Issue Type: Task >Reporter: Mikael Ståldal >Assignee: Matt Sicker > > We need to setup the build process for new Git repo logging-log4j-scala, > including site and Jenkins build. -- 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=15865110#comment-15865110
]
Matt Sicker commented on LOG4J2-1814:
-
Outer class name for convenience sounds like a good idea.
> 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=15864085#comment-15864085
]
Matt Sicker commented on LOG4J2-1813:
-
We'd have to add another method in PropertiesUtil like {{hasProperty()}} to
support this if it doesn't need a value.
> 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-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=15863099#comment-15863099
]
Matt Sicker commented on LOG4J2-1813:
-
That reminds me; I'd like to point out that LoggerContextRule in
log4j-core:test interprets the system property "EBUG" as a debug switch
({{-DEBUG}}). That class should be updated to support this proposed property as
well for completeness sake.
> 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-1812) Improve error message when log4j 2 configuration file not found
[
https://issues.apache.org/jira/browse/LOG4J2-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862963#comment-15862963
]
Matt Sicker commented on LOG4J2-1812:
-
You'll want to use the normalised property name after LOG4J2-1431 is merged,
though I don't really want to introduce a large change like that for 2.8.1.
> Improve error message when log4j 2 configuration file not found
> ---
>
> Key: LOG4J2-1812
> URL: https://issues.apache.org/jira/browse/LOG4J2-1812
> Project: Log4j 2
> Issue Type: Improvement
> Components: Configurators
>Affects Versions: 2.3, 2.4, 2.5, 2.6, 2.7, 2.8
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> When configuration fails because no Log4j 2 configuration file is found, the
> following message is logged to the console at ERROR level:
> {code}
> No log4j2 configuration file found. Using default configuration: logging only
> errors to the console.
> {code}
> We should be able to improve this. One idea is to add this:
> {code}
> No log4j2 configuration file found. Using default configuration: logging only
> errors to the console. Set system property
> 'org.apache.logging.log4j.simplelog.StatusLogger.level' to TRACE to show
> Log4j2 internal initialization logging.
> {code}
> Another idea is to dump the contents of the StatusLogger ring buffer to the
> console.
--
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=15862962#comment-15862962
]
Matt Sicker commented on LOG4J2-1813:
-
The simplified property system (which isn't merged yet btw) would support that
long name as one of the following:
* {{log4j2.simplelog.StatusLogger.level}}
* {{log4j2.simplelogStatusLoggerLevel}}
* and many other combinations, yet the shortest possible property name for this
would be:
* {{simplelogStatusLoggerLevel}}
* ...which is still pretty long.
> 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-1811) Log4j 2 configuration/usage ergonomics
[ https://issues.apache.org/jira/browse/LOG4J2-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862948#comment-15862948 ] Matt Sicker commented on LOG4J2-1811: - I've been thinking about something similar lately, but I wasn't sure what the problem could be described as. I do have some ideas: * Combine the Plugins and Extending Log4j manual pages. The split is hard to define, and the pages reference each other anyways. * Possibly split up the appenders page so that each appender is a subpage. This idea might be applicable elsewhere, but having huge pages by default can be confusing. Perhaps generating both a per-page and single-page version of the manual would be a good idea? Not sure how easy that is to do with the current maven plugin. * Replace code snippets, config snippets, etc., from manual with file includes of the actual source. This way, changes to tests/etc. will have documentation updates reflected. * A tl;dr version of the manual would be neat. Give some sensible fast default config files to start with, maybe help point users in the right direction for advanced features. > Log4j 2 configuration/usage ergonomics > -- > > Key: LOG4J2-1811 > URL: https://issues.apache.org/jira/browse/LOG4J2-1811 > Project: Log4j 2 > Issue Type: Epic > Components: Configurators, Core >Reporter: Remko Popma > > The vast majority of StackOverflow Log4j 2 questions is related to > configuration. The Log4j 2 site offers an extensive manual but apparently > many questions remain. > This ticket aims to make Log4j 2 easier to configure and use. This can take > many forms: > * adding documentation > * making documentation easier to find > * detecting and addressing inconsistencies > * facilitating debugging > * showing richer error messages that help users diagnose problems > * ... etc > I am making this an epic so the effort can span multiple releases and include > many big or small changes. -- 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-1810) Upgrade Logback to version 1.2
[ https://issues.apache.org/jira/browse/LOG4J2-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1810: Fix Version/s: boot-1.0-alpha1 > Upgrade Logback to version 1.2 > -- > > Key: LOG4J2-1810 > URL: https://issues.apache.org/jira/browse/LOG4J2-1810 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.8 >Reporter: Ralph Goers >Priority: Minor > Fix For: boot-1.0-alpha1, 2.8.1 > > -- 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-1691) Setup build process for new Git repo logging-log4j-scala, including site
[ https://issues.apache.org/jira/browse/LOG4J2-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15856220#comment-15856220 ] Matt Sicker commented on LOG4J2-1691: - The final step is the site integration. I'm not exactly sure which would be the best way to do so, but here are some ideas on how: * Make the Log4j Scala API site its own subdirectory like Log4j Boot will be and just include prominent links on the main Log4j site (and the Logging Services site). I kind of prefer this option because it's easier to implement for both this site as well as the other Log4j subprojects we're working on. * Try to fake site integration between Log4j 2 and Log4j Scala API by copying the generated sites from Log4j Scala API into the appropriate subdirectories in the Log4j 2 site in svn, though this will require far more manual maintenance. I feel as though if we went this route, we'd eventually want to switch to the first idea anyways. > Setup build process for new Git repo logging-log4j-scala, including site > > > Key: LOG4J2-1691 > URL: https://issues.apache.org/jira/browse/LOG4J2-1691 > Project: Log4j 2 > Issue Type: Task >Reporter: Mikael Ståldal >Assignee: Matt Sicker > > We need to setup the build process for new Git repo logging-log4j-scala, > including site and Jenkins build. -- 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=15853585#comment-15853585 ] Matt Sicker commented on LOG4J2-1809: - Yes, this is for PropertiesUtil. I can't think of anywhere else in log4j that this might be used, either. > 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] [Commented] (LOG4J2-1431) Simplify log4j system property naming scheme
[ https://issues.apache.org/jira/browse/LOG4J2-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853384#comment-15853384 ] Matt Sicker commented on LOG4J2-1431: - Thankfully, parsing the property names turned out to be a lot simpler than initially expected thanks to some regular expressions. This feature is pretty much code complete in the LOG4J2-1431 branch. I'd still like to update the manual to reference the normalized property names instead of the mish-mash we have currently. Here are some random examples of updates: * log4j2.AsyncQueueFullPolicy -> log4j2.asyncQueueFullPolicy * log4j.configurationFile -> log4j2.configurationFile * AsyncLogger.ExceptionHandler -> log4j2.asyncLoggerExceptionHandler * Log4jContextSelector -> log4j2.contextSelector > Simplify log4j system property naming scheme > > > Key: LOG4J2-1431 > URL: https://issues.apache.org/jira/browse/LOG4J2-1431 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Matt Sicker >Assignee: Matt Sicker > > As I wonder how to prefix yet another configurable system property, I noticed > we have five families of configuration name prefixes: > log4j.* > log4j2.* > Log4j* > org.apache.logging.log4j.* > > What I'd like to do is strip out all those prefixes and allow any of them, > but change the documentation to use only a single consistent prefix. This > would also make it simpler when writing the properties into a > log4j2.component.properties file as you could omit all the prefixes as they > won't clash with other libraries. -- 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=15853382#comment-15853382 ] Matt Sicker commented on LOG4J2-1809: - This is pretty much code complete in the LOG4J2-1431 branch. I'd like to add documentation before merging (plus this would be appropriate for a 2.9 release more so than a 2.8.1 release, so I could also wait to merge until after 2.8.1 or we can handle it some other way). > 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] [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=15853341#comment-15853341
]
Matt Sicker commented on LOG4J2-1809:
-
I don't think this would require that level of functionality. See for example
the interface so far:
{code:java}
public interface PropertySource {
int getPriority();
void forEach(BiConsumer action);
CharSequence getNormalForm(Iterable tokens);
}
{code}
Commons Configuration is more in line with what we do for logger/appender
configuration files.
> 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] [Created] (LOG4J2-1809) Add global configuration environment SPI
Matt Sicker created LOG4J2-1809: --- Summary: 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] [Assigned] (LOG4J2-1431) Simplify log4j system property naming scheme
[ https://issues.apache.org/jira/browse/LOG4J2-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker reassigned LOG4J2-1431: --- Assignee: Matt Sicker > Simplify log4j system property naming scheme > > > Key: LOG4J2-1431 > URL: https://issues.apache.org/jira/browse/LOG4J2-1431 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Matt Sicker >Assignee: Matt Sicker > > As I wonder how to prefix yet another configurable system property, I noticed > we have five families of configuration name prefixes: > log4j.* > log4j2.* > Log4j* > org.apache.logging.log4j.* > > What I'd like to do is strip out all those prefixes and allow any of them, > but change the documentation to use only a single consistent prefix. This > would also make it simpler when writing the properties into a > log4j2.component.properties file as you could omit all the prefixes as they > won't clash with other libraries. -- 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-1808) java.lang.NoSuchMethodError: org.apache.logging.log4j.ThreadContext.getThreadContextMap()
[
https://issues.apache.org/jira/browse/LOG4J2-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853014#comment-15853014
]
Matt Sicker commented on LOG4J2-1808:
-
This sort of thing could've been caught by the Provider API in log4j-api using
required versions, but we keep forgetting to update those for each version.
> java.lang.NoSuchMethodError:
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()
> -
>
> Key: LOG4J2-1808
> URL: https://issues.apache.org/jira/browse/LOG4J2-1808
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.8
> Environment: Google AppEngine local development server
>Reporter: Lukasz Lenart
>
> {noformat}
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger
> warn
> [INFO] WARNING: failed
> com.google.appengine.tools.development.DevAppEngineWebAppContext@454577f3{/,/Users/lukaszlenart/Projects/Private/gruuf-webapp/target/gruuf-webapp-1.0-SNAPSHOT}:
> java.lang.NoSuchMethodError:
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger
> warn
> [INFO] WARNING: failed JettyContainerService$ApiProxyHandler@53c6160c:
> java.lang.NoSuchMethodError:
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO] Feb 04, 2017 4:38:37 PM com.google.apphosting.utils.jetty.JettyLogger
> warn
> [INFO] WARNING: Error starting handlers
> [INFO] java.lang.NoSuchMethodError:
> org.apache.logging.log4j.ThreadContext.getThreadContextMap()Lorg/apache/logging/log4j/spi/ReadOnlyThreadContextMap;
> [INFO]at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:83)
> [INFO]at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:67)
> [INFO]at
> org.apache.logging.log4j.core.lookup.ContextMapLookup.(ContextMapLookup.java:34)
> [INFO]at
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:117)
> [INFO]at
> org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:125)
> [INFO]at
> org.apache.logging.log4j.core.config.NullConfiguration.(NullConfiguration.java:32)
> [INFO]at
> org.apache.logging.log4j.core.LoggerContext.(LoggerContext.java:77)
> [INFO]at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.createContext(ClassLoaderContextSelector.java:171)
> [INFO]at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:145)
> [INFO]at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:70)
> [INFO]at
> org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:57)
> [INFO]at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:147)
> [INFO]at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> [INFO]at
> org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> [INFO]at
> org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> [INFO]at
> org.apache.struts2.tiles.StrutsTilesListener.(StrutsTilesListener.java:34)
> [INFO]at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> [INFO]at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> [INFO]at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [INFO]at
> java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> [INFO]at java.lang.Class.newInstance(Class.java:383)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.newListenerInstance(WebXmlConfiguration.java:650)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.initListener(WebXmlConfiguration.java:631)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:368)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:289)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:222)
> [INFO]at
> org.mortbay.jetty.webapp.WebXmlConfiguration.configureWebApp(WebXmlConfiguration.java:180)
> [INFO]at
>
[jira] [Commented] (LOG4J2-1805) FixedDateFormat improvements
[
https://issues.apache.org/jira/browse/LOG4J2-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15849590#comment-15849590
]
Matt Sicker commented on LOG4J2-1805:
-
Ok, that makes sense. Thanks for the clarification.
> FixedDateFormat improvements
>
>
> Key: LOG4J2-1805
> URL: https://issues.apache.org/jira/browse/LOG4J2-1805
> Project: Log4j 2
> Issue Type: Improvement
> Components: Pattern Converters
>Affects Versions: 2.6
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> *Proposed changes:*
> * improve thread-safety of {{FixedDateFormat::updateMidnightMillis}}
> * expose {{FixedDateFormat::millisSinceMidnight}} as a public method
> In multi-threaded scenarios where time does not move forward monotonically,
> the implementation of {{FixedDateFormat::updateMidnightMillis}} can result in
> corrupted time stamps. In a project I am involved in we have a custom
> PatternConverter that uses FixedDateFormat to format the "event time". In
> these (artificial) tests, event time does not always move forward, so the
> {{updateMidnightMillis}} is called concurrently with varying values. This is
> not a production issue, but the implementation can be improved to be
> thread-safe without impacting performance by using double-checked locking.
> Making {{FixedDateFormat::millisSinceMidnight}} public would provide a
> performant and convenient way to strip off the date component. Useful for
> systems that are on Java 7 or for systems on Java 8 that don't want to
> construct a {{LocalTime}} object every time this value is required.
--
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-1805) FixedDateFormat improvements
[
https://issues.apache.org/jira/browse/LOG4J2-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15849506#comment-15849506
]
Matt Sicker commented on LOG4J2-1805:
-
Do you think any of these changes are relevant to commons-lang since most of
the datetime classes are from there?
> FixedDateFormat improvements
>
>
> Key: LOG4J2-1805
> URL: https://issues.apache.org/jira/browse/LOG4J2-1805
> Project: Log4j 2
> Issue Type: Improvement
> Components: Pattern Converters
>Affects Versions: 2.6
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8.1
>
>
> *Proposed changes:*
> * improve thread-safety of {{FixedDateFormat::updateMidnightMillis}}
> * expose {{FixedDateFormat::millisSinceMidnight}} as a public method
> In multi-threaded scenarios where time does not move forward monotonically,
> the implementation of {{FixedDateFormat::updateMidnightMillis}} can result in
> corrupted time stamps. In a project I am involved in we have a custom
> PatternConverter that uses FixedDateFormat to format the "event time". In
> these (artificial) tests, event time does not always move forward, so the
> {{updateMidnightMillis}} is called concurrently with varying values. This is
> not a production issue, but the implementation can be improved to be
> thread-safe without impacting performance by using double-checked locking.
> Making {{FixedDateFormat::millisSinceMidnight}} public would provide a
> performant and convenient way to strip off the date component. Useful for
> systems that are on Java 7 or for systems on Java 8 that don't want to
> construct a {{LocalTime}} object every time this value is required.
--
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-1802) Convert documentation into Markdown
Title: Message Title Matt Sicker created an issue Log4j 2 / LOG4J2-1802 Convert documentation into Markdown Issue Type: Documentation Assignee: Matt Sicker Components: Documentation Created: 29/Jan/17 18:09 Priority: Major Reporter: Matt Sicker The xdoc system currently in place is difficult to use correctly (it expects proper XHTML, no block level elements inside inline level elements, the usual pedantry from an XHTML/XML validator) and is needlessly verbose for writing documentation. The plugin we already use (maven-site-plugin) supports Markdown as an alternative (amongst others). Most text can be formatted as plain Markdown which simplifies the format a bit, plus anything complex can still be written in regular HTML (e.g., special tables). This will also allow for the documentation to be viewable on GitHub (at least for non-templated files) as seen in this example page. I suggest using Markdown instead of something like Asciidoc as it's simpler to convert from xdoc and because I'm far more experienced with the syntax. Add
[jira] (LOG4J2-1431) Simplify log4j system property naming scheme
Title: Message Title Matt Sicker commented on LOG4J2-1431 Re: Simplify log4j system property naming scheme Bringing this topic back up before I plan any code changes, I'd like to elaborate on the idea. Right now, configuration done via the normal config file system is rather well supported in the documentation. One of the key improvements in Log4j 2's configuration format was getting rid of the need to specify internal class names to configure plugins. This feature request follows a similar philosophy in simplifying the global Log4j 2 settings that are normally specified as system properties or through a log4j2.component.properties file on the classpath. System property settings are documented all over the manual where appropriate, but the general system of how to use them other than as command line flags is not very well explained. What I'd like to propose here, besides simplifying the base naming scheme and supporting them all (along with updating the documentation to normalize on the prefix log4j2. as discussed above), would be supporting a general property name format like such. All the following property names would be equivalent: log4j.configurationFile log4j2.configurationFile Log4jConfigurationFile org.apache.logging.log4j.configurationFile LOG4J_CONFIGURATIONFILE LOG4J_CONFIGURATION_FILE Log4j-configurationFile Log4j-ConfigurationFile log4j.configuration.file The idea here being that dots, dashes, and underscores should all be equivalent (underscores being supported for allowing environment variables to be used instead of system properties in a 12factor system, and dashes being added possibly to allow for alternate styles to be used, but I have no personal request for that other than completeness); properties could either be case-insensitive or we could support a system where CamelCaseWords are treated the same as camel.case.words or CAMEL_CASE_WORDS (so, somewhat case insensitive, but after parsing into words); and this would in general provide the possibility to inject configuration in a cloud environment through any arbitrary configuration system (although supporting environment variables in addition to system properties would handle the majority of cases; it's not like global settings from PropertiesUtil are reconfigurable at runtime, so supporting hot-reload via some configuration management
[jira] [Commented] (LOG4J2-1691) Setup build process for new Git repo logging-log4j-scala, including site
[ https://issues.apache.org/jira/browse/LOG4J2-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15844167#comment-15844167 ] Matt Sicker commented on LOG4J2-1691: - Updated the readme file as well. > Setup build process for new Git repo logging-log4j-scala, including site > > > Key: LOG4J2-1691 > URL: https://issues.apache.org/jira/browse/LOG4J2-1691 > Project: Log4j 2 > Issue Type: Task >Reporter: Mikael Ståldal >Assignee: Matt Sicker > > We need to setup the build process for new Git repo logging-log4j-scala, > including site and Jenkins build. -- 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-1691) Setup build process for new Git repo logging-log4j-scala, including site
[ https://issues.apache.org/jira/browse/LOG4J2-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15844132#comment-15844132 ] Matt Sicker commented on LOG4J2-1691: - Jenkins is now set up and properly building. The site looks a little messed up, though, because of some path assumptions: https://builds.apache.org/job/Log4jScala/site/ > Setup build process for new Git repo logging-log4j-scala, including site > > > Key: LOG4J2-1691 > URL: https://issues.apache.org/jira/browse/LOG4J2-1691 > Project: Log4j 2 > Issue Type: Task >Reporter: Mikael Ståldal >Assignee: Matt Sicker > > We need to setup the build process for new Git repo logging-log4j-scala, > including site and Jenkins build. -- 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-1788) Create Apache Logging parent pom
[ https://issues.apache.org/jira/browse/LOG4J2-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-1788. --- Closing as version 1 was tagged and released. > Create Apache Logging parent pom > > > Key: LOG4J2-1788 > URL: https://issues.apache.org/jira/browse/LOG4J2-1788 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Matt Sicker >Assignee: Matt Sicker > > Create a parent pom that inherits from the main ASF pom that is used by > log4j, log4j-boot, log4j-scala, log4j-bom, and any other future subprojects. > groupId: org.apache.logging (or with .log4j?) > artifactId: parent (or log4j-parent, logging-parent?) > This should also configure a baseline compiler and target version of 1.7 by > default (ASF's does 1.6 right now), plus any other useful pom metadata such > as the team list, distribution info, etc. -- 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-1630) Unit of Work Logging
[ https://issues.apache.org/jira/browse/LOG4J2-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1630: Fix Version/s: (was: 2.8.1) 2.9 > Unit of Work Logging > > > Key: LOG4J2-1630 > URL: https://issues.apache.org/jira/browse/LOG4J2-1630 > Project: Log4j 2 > Issue Type: Story > Components: API, Core, Filters >Affects Versions: 2.7 >Reporter: Remko Popma > Fix For: 2.9 > > > h3. Intent > Provide a way to filter log events, where the decision on whether to discard > the message or actually log them cannot be made until after the application > has already logged the message. > h3. Motivation > In many systems, particularly event processing applications, log files > contain a lot of repetitive log messages. Suppose an application needs to do > some calculation to decide whether or not to react to some event, and a lot > of detail is logged during this calculation. Imagine that 99% of the time, > the application decides to take no action. Once the application arrived at > that conclusion it would be nice if we could go back and undo all the > detailed logging and print a summary instead. When the application _does_ > decide to take some action, however, we _do_ want the detailed log messages. > A Unit of Work for logging would allow us to group a set of log messages and > either discard them or log them together. (Inspired by Martin Fowler's [Unit > of Work|http://martinfowler.com/eaaCatalog/unitOfWork.html] pattern.) > This should result in log files where a lot of the "uninteresting" logging is > filtered out, significantly reducing the amount of data logged. > Some applications do this in an ad hoc manner, for example by passing a > Collection to its components, where these components can add log message > strings to this Collection. When the discard/retain decision is made, the > application then either clears the Collection or logs the contents of the > Collection. This works, but having to pass the Collection down the component > tree is clunky and the result often omits details like logger name, timestamp > and other details that come for free with normal logging. Log4j can provide a > reusable and less intrusive way to accomplish this. > h3. How it works > There would need to be some API for the application to mark the _start_ of > the unit of work, and some API to signal whether the log messages that are > part of that unit of work need to be _discarded_ or _logged_ (retained). > Not all logging that occurs after a unit of work was started is part of that > unit of work. The application may want some messages to be logged regardless > of whether the unit of work was discarded or not. There needs to be a > flexible way (or multiple ways) to include or exclude logging statements from > the unit of work. > The application may also designate multiple units of work, which may be > sequential, nested or partially overlapping. Each unit of work may define its > own rules for which log messages are considered included in or excluded from > the unit of work. -- 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
