[jira] [Commented] (LOG4J2-2079) Update Conversant Disruptor from 1.12.10 to 1.12.11
[ https://issues.apache.org/jira/browse/LOG4J2-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16208168#comment-16208168 ] Ralph Goers commented on LOG4J2-2079: - This can be implemented in one of three ways: # Wait for Log4j to make Java 8 the minimum version. # Inform the end user that they can upgrade to the new version if they are running on Java 8. # Add profiles to the parent pom that specify the dependency based on the version of Java. Personally, I consider the versions listed in the poms to be advisory. All of my projects have a dependencyManagement section that declares all the versions of the dependencies to use. > Update Conversant Disruptor from 1.12.10 to 1.12.11 > --- > > Key: LOG4J2-2079 > URL: https://issues.apache.org/jira/browse/LOG4J2-2079 > Project: Log4j 2 > Issue Type: Improvement >Affects Versions: 2.9.1 >Reporter: Gary Gregory >Assignee: Gary Gregory > Labels: Java8 > > Update Conversant Disruptor from 1.12.10 to 1.12.11. > This update requires Java 8. > See https://github.com/conversant/disruptor -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2055) ServiceConfigurationError in Tomcat when Log4j is used as the logging implementation
[
https://issues.apache.org/jira/browse/LOG4J2-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209368#comment-16209368
]
Ralph Goers commented on LOG4J2-2055:
-
I recommend you try the latest in master.
> ServiceConfigurationError in Tomcat when Log4j is used as the logging
> implementation
>
>
> Key: LOG4J2-2055
> URL: https://issues.apache.org/jira/browse/LOG4J2-2055
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.9.1
>Reporter: Ralph Goers
>Assignee: Ralph Goers
> Fix For: 2.10.0
>
>
> When Log4j is used as the Tomcat logging implementation using the
> log4j-appserver Handler applications using Log4j will fail to start trying to
> load a Log4jProvider they cannot access. The following will appear in the
> startup log.
> {code}
> 2017-09-23 17:29:43,223 [localhost-startStop-1] ERROR
> o.a.c.c.ContainerBase.addChildInternal:755 - ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/AuditCatalog]]
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
> ~[catalina.jar:8.5.20]
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
> [catalina.jar:8.5.20]
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
> [catalina.jar:8.5.20]
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
> [catalina.jar:8.5.20]
> at
> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:988)
> [catalina.jar:8.5.20]
> at
> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1860)
> [catalina.jar:8.5.20]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
> [?:?]
> at java.lang.Thread.run(Thread.java:844) [?:?]
> Caused by: java.util.ServiceConfigurationError:
> org.apache.logging.log4j.spi.Provider:
> org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
> at java.util.ServiceLoader.fail(ServiceLoader.java:588) ~[?:?]
> at java.util.ServiceLoader.access$200(ServiceLoader.java:390) ~[?:?]
> at
> java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1231)
> ~[?:?]
> at
> java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1259)
> ~[?:?]
> at java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1294) ~[?:?]
> at java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1379) ~[?:?]
> at
> org.apache.logging.log4j.util.ProviderUtil.loadProviders(ProviderUtil.java:101)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.util.ProviderUtil.(ProviderUtil.java:67)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.util.ProviderUtil.lazyInit(ProviderUtil.java:142)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.util.ProviderUtil.hasProviders(ProviderUtil.java:126)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.spi.ThreadContextMapFactory.createThreadContextMap(ThreadContextMapFactory.java:73)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.ThreadContext.init(ThreadContext.java:224)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.ThreadContext.(ThreadContext.java:203)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:83)
> ~[log4j-core-2.9.1.jar:2.9.1]
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:67)
> ~[log4j-core-2.9.1.jar:2.9.1]
> at
> org.apache.logging.log4j.core.lookup.ContextMapLookup.(ContextMapLookup.java:34)
> ~[log4j-core-2.9.1.jar:2.9.1]
> at
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:117)
> ~[log4j-core-2.9.1.jar:2.9.1]
> at
> org.apache.logging.log4j.web.Log4jWebInitializerImpl.(Log4jWebInitializerImpl.java:63)
> ~[?:?]
> at
> org.apache.logging.log4j.web.Log4jWebInitializerImpl.initialize(Log4jWebInitializerImpl.java:86)
> ~[?:?]
> at
> or
[jira] [Commented] (LOG4J2-2089) [TagLib] Update servlet-api provided dependency from 2.5 to 3.0.1
[ https://issues.apache.org/jira/browse/LOG4J2-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16215528#comment-16215528 ] Ralph Goers commented on LOG4J2-2089: - Does this change imply that Log4j no longer supports servlet-api 2.5? > [TagLib] Update servlet-api provided dependency from 2.5 to 3.0.1 > - > > Key: LOG4J2-2089 > URL: https://issues.apache.org/jira/browse/LOG4J2-2089 > Project: Log4j 2 > Issue Type: Task > Components: Taglib >Affects Versions: 2.9.1 >Reporter: Gary Gregory > Fix For: 2.10.0 > > > Update servlet-api provided dependency from 2.5 to 3.0.1. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2089) [TagLib] Update servlet-api provided dependency from 2.5 to 3.0.1
[ https://issues.apache.org/jira/browse/LOG4J2-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16215557#comment-16215557 ] Ralph Goers commented on LOG4J2-2089: - I guess this is a more general question. In my experience, one usually creates the tests for the minimum supported version with the expectation that future versions will be binary compatible. So if we are compiling and testing with 3.0 how will we know if we have broken compatibility with 2.5? > [TagLib] Update servlet-api provided dependency from 2.5 to 3.0.1 > - > > Key: LOG4J2-2089 > URL: https://issues.apache.org/jira/browse/LOG4J2-2089 > Project: Log4j 2 > Issue Type: Task > Components: Taglib >Affects Versions: 2.9.1 >Reporter: Gary Gregory > Fix For: 2.10.0 > > > Update servlet-api provided dependency from 2.5 to 3.0.1. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2087) Property log4j.skipJansi should have a default of true
[ https://issues.apache.org/jira/browse/LOG4J2-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16215735#comment-16215735 ] Ralph Goers commented on LOG4J2-2087: - So now we would have 2 properties that have opposite meanings? So if one has a default of true and one is false what is the overall default? > Property log4j.skipJansi should have a default of true > -- > > Key: LOG4J2-2087 > URL: https://issues.apache.org/jira/browse/LOG4J2-2087 > Project: Log4j 2 > Issue Type: Bug > Components: Appenders >Affects Versions: 2.9.1 > Environment: Windows >Reporter: Remko Popma >Assignee: Remko Popma > Fix For: 2.10.0 > > > JIRA ticket for GitHub pull request > https://github.com/apache/logging-log4j2/pull/29 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16217905#comment-16217905
]
Ralph Goers commented on LOG4J2-1863:
-
Please note that the Log4j team strongly recommends against using the
SerializedLayout with the SocketAppenders. The SocketAppender can be configured
with the JsonLayout to accomplish the same thing in a way that does not expose
the server to the serialization issues.
The Log4j socket servers were meant to be examples for users and as such have
been moved from log4j core into its own Git repository where it will be
separately maintained and released. There are no plans to drop support for the
SocketServers.
> 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).
> h3. Security Details
> {code}
> CVE-2017-5645: Apache Log4j socket receiver deserialization vulnerability
> Severity: High
> CVSS Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
> Vendor: The Apache Software Foundation
> Versions Affected: all versions from 2.0-alpha1 to 2.8.1
> Description: When using the TCP socket server or UDP socket server to receive
> serialized log events from another application, a specially crafted binary
> payload can be sent that, when deserialized, can execute arbitrary code.
> Mitigation: Java 7+ users should migrate to version 2.8.2 or avoid using the
> socket server classes. Java 6 users should avoid using the TCP or UDP socket
> server classes, or they can manually backport the security fix from 2.8.2:
>
> Credit: This issue was discovered by Marcio Almeida de Macedo of Red Team at
> Telstra
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2056) Modularize Log4j as automatic modules
[ https://issues.apache.org/jira/browse/LOG4J2-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222628#comment-16222628 ] Ralph Goers commented on LOG4J2-2056: - Stephen followed up on the jigsaw mailing list and was able to validate that what has been implemented for this issue is correct. See http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-October/thread.html#13283 - specifically http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-October/013283.html and http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-October/013285.html. > Modularize Log4j as automatic modules > - > > Key: LOG4J2-2056 > URL: https://issues.apache.org/jira/browse/LOG4J2-2056 > Project: Log4j 2 > Issue Type: New Feature >Affects Versions: 2.9.1 >Reporter: Ralph Goers >Assignee: Ralph Goers > Fix For: 2.10.0 > > > To fully support Java 9 all Log4j jars must (at least) be packaged as > automatic modules. We should, as much as possible, follow the recommendations > at http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html. Given > that the module names would be: > ||Artifact ID ||Module name|| > |log4j-api|org.apache.logging.log4j| > |log4j-core|org.apache.logging.log4j.core| > |log4j-1.2-api|org.apache.log4j| > |log4j-appserver|org.apache.logging.log4j.appserver| > |log4j-flume-ng|org.apache.logging.log4j.flume| > |log4j-iostreams|org.apache.logging.log4j.iostreams| > |log4j-jcl|org.apache.logging.log4j.jcl| > |log4j-jmx-gui|org.apache.logging.log4j.jmx.gui| > |log4j-jul|org.apache.logging.log4j.jul| > |log4j-nosql|org.apache.logging.log4j.nosql| > |log4j-osgi|org.apache.logging.log4j.osgi| > |log4j-sl4j-impl|org.apache.logging.log4j.slf4j.impl*| > |log4j-to-slf4j|org.apache.logging.log4j.slf4j| > |log4j-taglib|org.apache.logging.log4j.taglib| > |log4j-web|org.apache.logging.log4j.web| > # log4j-liquibase uses a package name outside the org.apache.logging.log4j > namespace so is not modularized. > # log4j-slf4j-impl cannot currently be modularized until the binding is > modified. It cannot have classes in the org.slf4j namespace. > # log4j-slf4j-impl and log4j-to-slf4j both use the same package name - > org.apache.logging.log4j.slf4j. This will remain the same as it will prevent > them both from being loaded at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (LOG4J2-2069) --multi-release option not set for the multi-release jar.
[
https://issues.apache.org/jira/browse/LOG4J2-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers closed LOG4J2-2069.
---
> --multi-release option not set for the multi-release jar.
> -
>
> Key: LOG4J2-2069
> URL: https://issues.apache.org/jira/browse/LOG4J2-2069
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Reporter: Naman Nigam
>
> Executing Jdeps on the `log4j-api-2.9.1.jar` results into an error:-
> {quote} Error: log4j-api-2.9.1.jar is a multi-release jar file but
> --multi-release option is not set
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (LOG4J2-2069) --multi-release option not set for the multi-release jar.
[
https://issues.apache.org/jira/browse/LOG4J2-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-2069.
-
Resolution: Not A Problem
This is user error. Try running jdeps -? for help on the command.
Entering
{code}
jdeps --multi-release 9
~/.m2/repository/org/apache/logging/log4j/log4j-api/2.9.1/log4j-api-2.9.1.jar
{code}
yields the desired output.
> --multi-release option not set for the multi-release jar.
> -
>
> Key: LOG4J2-2069
> URL: https://issues.apache.org/jira/browse/LOG4J2-2069
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Reporter: Naman Nigam
>
> Executing Jdeps on the `log4j-api-2.9.1.jar` results into an error:-
> {quote} Error: log4j-api-2.9.1.jar is a multi-release jar file but
> --multi-release option is not set
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-1203) Allow filtering of line breaks in layout pattern
[
https://issues.apache.org/jira/browse/LOG4J2-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235051#comment-16235051
]
Ralph Goers commented on LOG4J2-1203:
-
Yes. Issues with patches are always more likely to be accepted.
> Allow filtering of line breaks in layout pattern
>
>
> Key: LOG4J2-1203
> URL: https://issues.apache.org/jira/browse/LOG4J2-1203
> Project: Log4j 2
> Issue Type: New Feature
> Components: Pattern Converters
>Affects Versions: 2.4.1
>Reporter: Mitth'raw'nuruodo
>Priority: Minor
> Fix For: 2.0-rc2
>
>
> Unless specific steps are taken to filter log inputs, there may be a risk of
> CRLF injection, allowing an attacker to forge log entries:
> https://cwe.mitre.org/data/definitions/93.html
> This is not a critical vulnerability, but manually
> escaping/encoding/sanitising every instance of logging in a large application
> is impractical. Most applications have no need to output un-filtered line
> breaks, so they would benefit from a global option.
> Could the list of pattern converters be extended to include a modifier to say
> that whitespace should be normalised (as per Commons Lang
> {{StringUtils.normaliseSpace}})? Eg {{%_m}}
> Alternatively, it would be simple to implement a wrapper that would apply
> normalisation to the output of another layout, but it would be more difficult
> to configure such a wrapper in XML, and it would affect the entire log
> output, effectively obliterating all padding modifiers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-1203) Allow filtering of line breaks in layout pattern
[
https://issues.apache.org/jira/browse/LOG4J2-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235051#comment-16235051
]
Ralph Goers edited comment on LOG4J2-1203 at 11/2/17 1:21 AM:
--
Yes. Issues with patches are always more likely to be accepted. I should point
out that instead of attaching a patch you can also create a pull request at
github.
was (Author: ralph.go...@dslextreme.com):
Yes. Issues with patches are always more likely to be accepted.
> Allow filtering of line breaks in layout pattern
>
>
> Key: LOG4J2-1203
> URL: https://issues.apache.org/jira/browse/LOG4J2-1203
> Project: Log4j 2
> Issue Type: New Feature
> Components: Pattern Converters
>Affects Versions: 2.4.1
>Reporter: Mitth'raw'nuruodo
>Priority: Minor
> Fix For: 2.0-rc2
>
>
> Unless specific steps are taken to filter log inputs, there may be a risk of
> CRLF injection, allowing an attacker to forge log entries:
> https://cwe.mitre.org/data/definitions/93.html
> This is not a critical vulnerability, but manually
> escaping/encoding/sanitising every instance of logging in a large application
> is impractical. Most applications have no need to output un-filtered line
> breaks, so they would benefit from a global option.
> Could the list of pattern converters be extended to include a modifier to say
> that whitespace should be normalised (as per Commons Lang
> {{StringUtils.normaliseSpace}})? Eg {{%_m}}
> Alternatively, it would be simple to implement a wrapper that would apply
> normalisation to the output of another layout, but it would be more difficult
> to configure such a wrapper in XML, and it would affect the entire log
> output, effectively obliterating all padding modifiers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2094) Specifying log4jConfiguration in web.xml fails on Windows when the file's path contains vm options
[
https://issues.apache.org/jira/browse/LOG4J2-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235163#comment-16235163
]
Ralph Goers commented on LOG4J2-2094:
-
Can you please try
{code}
file:///${sys:SYSTEM_HOME}/etc/properties/log4j2.xml
{code}
and see if that works any better?
> Specifying log4jConfiguration in web.xml fails on Windows when the file's
> path contains vm options
> --
>
> Key: LOG4J2-2094
> URL: https://issues.apache.org/jira/browse/LOG4J2-2094
> Project: Log4j 2
> Issue Type: Bug
> Environment: Windows 10, jetty 9.4.7.v20170914 , Java 8, log4j 2.9.1
>Reporter: jinyanan
>Priority: Minor
>
> when I code my web.xml like this
> {code:java}
>
> log4jConfiguration
>
> file:///${SYSTEM_HOME}/etc/properties/log4j2.xml
>
> {code}
> I get exception like
> {code:java}
> ERROR StatusLogger Unable to access
> file:///$%7BSYSTEM_HOME%7D/etc/properties/log4j2.xml
> java.io.FileNotFoundException: \${SYSTEM_HOME}\etc\properties\log4j2.xml
> (系统找不到指定的路径。)
> {code}
> I set my SYSTEM_HOME in my IntelliJ IDEA VM Options
> !http://wx4.sinaimg.cn/large/7dde05d2gy1fl3ikz7iqmj20uc0a4dgf.jpg!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-1866) Add default value to MdcPatternConverter
[
https://issues.apache.org/jira/browse/LOG4J2-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235661#comment-16235661
]
Ralph Goers commented on LOG4J2-1866:
-
I’m sorry, but we don’t speak Chinese and the google translation isn’t clear
what you are wanting.
> Add default value to MdcPatternConverter
> -
>
> Key: LOG4J2-1866
> URL: https://issues.apache.org/jira/browse/LOG4J2-1866
> Project: Log4j 2
> Issue Type: Bug
> Components: Pattern Converters
>Affects Versions: 2.8.2
>Reporter: Izek Greenfield
>Priority: Major
> Labels: converter, mdc, pattern
> Attachments: Add_default_value_to_MDC_converter.patch,
> Add_documentation_.patch
>
>
> When using %X in a pattern I can't define default value if the value does not
> exist in MDC.
> I will be great to be able to define one like:
> {code:title=pattern|borderStyle=solid}
> %X{key}{hello}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (LOG4J2-2098) Add AppenderSkeleton to Log4j 1.2 API
Ralph Goers created LOG4J2-2098: --- Summary: Add AppenderSkeleton to Log4j 1.2 API Key: LOG4J2-2098 URL: https://issues.apache.org/jira/browse/LOG4J2-2098 Project: Log4j 2 Issue Type: Improvement Components: log4j 1.2 emulation Affects Versions: 2.9.1 Reporter: Ralph Goers Fix For: 2.10.0 Some applications dynamically create Appenders for Log4j 1.x and will fail to run with Log4j 2 due to a ClassNotFoundException. Providing a version of the class should cause no harm as the Appender will never be called in Log4j 2. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (LOG4J2-2098) Add AppenderSkeleton to Log4j 1.2 API
[ https://issues.apache.org/jira/browse/LOG4J2-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-2098. - Resolution: Fixed > Add AppenderSkeleton to Log4j 1.2 API > - > > Key: LOG4J2-2098 > URL: https://issues.apache.org/jira/browse/LOG4J2-2098 > Project: Log4j 2 > Issue Type: Improvement > Components: log4j 1.2 emulation >Affects Versions: 2.9.1 >Reporter: Ralph Goers > Fix For: 2.10.0 > > > Some applications dynamically create Appenders for Log4j 1.x and will fail to > run with Log4j 2 due to a ClassNotFoundException. Providing a version of the > class should cause no harm as the Appender will never be called in Log4j 2. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (LOG4J2-2098) Add AppenderSkeleton to Log4j 1.2 API
[ https://issues.apache.org/jira/browse/LOG4J2-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers closed LOG4J2-2098. --- > Add AppenderSkeleton to Log4j 1.2 API > - > > Key: LOG4J2-2098 > URL: https://issues.apache.org/jira/browse/LOG4J2-2098 > Project: Log4j 2 > Issue Type: Improvement > Components: log4j 1.2 emulation >Affects Versions: 2.9.1 >Reporter: Ralph Goers > Fix For: 2.10.0 > > > Some applications dynamically create Appenders for Log4j 1.x and will fail to > run with Log4j 2 due to a ClassNotFoundException. Providing a version of the > class should cause no harm as the Appender will never be called in Log4j 2. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2099) API changes report for Log4j API snapshot
[ https://issues.apache.org/jira/browse/LOG4J2-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239104#comment-16239104 ] Ralph Goers commented on LOG4J2-2099: - Thanks. Is there something we are supposed to do with this Jira issue? Are you requesting we add a link to the web site or something? FWIW, the graph only tells part of the story. The Log4j API has several classes that have to be public but are noted with Javadoc comments. Generally, those are the only classes where you may see binary incompatibilities and, as the graph shows, that doesn't happen often. > API changes report for Log4j API snapshot > - > > Key: LOG4J2-2099 > URL: https://issues.apache.org/jira/browse/LOG4J2-2099 > Project: Log4j 2 > Issue Type: Documentation >Reporter: Andrey Ponomarenko > Attachments: log4j-api-1.png, log4j-api-2.png > > > Hi, > I'd like to share report on API changes and backward compatibility for the > Log4j API library: https://abi-laboratory.pro/java/tracker/timeline/log4j-api/ > BC — binary compatibility > SC — source compatibility > The report is generated according to the article > https://wiki.eclipse.org/Evolving_Java-based_APIs_2 by the > https://github.com/lvc/japi-tracker tool. > The analysis for the latest snapshot version of the library from > https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-api/ > is included to the report. > Hope it will be helpful for users and maintainers of the library. > Thank you. > !log4j-api-2.png|API symbols timeline! > !log4j-api-1.png|API changes review! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2104) LoaderUtil getClassLoaders() method and while loops
[
https://issues.apache.org/jira/browse/LOG4J2-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241463#comment-16241463
]
Ralph Goers commented on LOG4J2-2104:
-
First, why is this a Jira issue? Simple questions like this should be on the
dev list.
Yes. This method returns all the ClassLoaders to search for a Log4j
implementation. Although the ThreadContextClassLoader shouldn't be there twice
it won't really hurt anything.
> LoaderUtil getClassLoaders() method and while loops
> ---
>
> Key: LOG4J2-2104
> URL: https://issues.apache.org/jira/browse/LOG4J2-2104
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Andrejus Chaliapinas
>Priority: Minor
>
> For v2.9.1 inside org.apache.logging.log4j.util.LoaderUtil and
> getClassLoaders() method we have lines 120-123 as such:
> ClassLoader parent = tcl;
> while (parent != null && !classLoaders.contains(parent)) {
> classLoaders.add(parent);
> }
> where it looks like some getParent() call is either missing or otherwise
> "while" loop is not needed.
> In line 111 tcl classloader already added into list of clasloaders:
> classLoaders.add(tcl);
> Was it an attempt to add all classloaders hierarchy or just some immediate
> parents?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (LOG4J2-2104) LoaderUtil getClassLoaders() method and while loops
[
https://issues.apache.org/jira/browse/LOG4J2-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned LOG4J2-2104:
---
Assignee: Ralph Goers
> LoaderUtil getClassLoaders() method and while loops
> ---
>
> Key: LOG4J2-2104
> URL: https://issues.apache.org/jira/browse/LOG4J2-2104
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Andrejus Chaliapinas
>Assignee: Ralph Goers
>Priority: Minor
>
> For v2.9.1 inside org.apache.logging.log4j.util.LoaderUtil and
> getClassLoaders() method we have lines 120-123 as such:
> ClassLoader parent = tcl;
> while (parent != null && !classLoaders.contains(parent)) {
> classLoaders.add(parent);
> }
> where it looks like some getParent() call is either missing or otherwise
> "while" loop is not needed.
> In line 111 tcl classloader already added into list of clasloaders:
> classLoaders.add(tcl);
> Was it an attempt to add all classloaders hierarchy or just some immediate
> parents?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2104) LoaderUtil getClassLoaders() method and while loops
[
https://issues.apache.org/jira/browse/LOG4J2-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242342#comment-16242342
]
Ralph Goers commented on LOG4J2-2104:
-
The problem you are mentioning is fixed in trunk as a result of LOG4J2-2055.
Using Provider.class.getClassLoader will only return the ClassLoader for the
log4j-api jar, which isn't what is desired. However, I am going to assign this
to myself to remind me to look at the ServiceLoader code so I can understand
why it is throwing the ServiceConfigurationError.
> LoaderUtil getClassLoaders() method and while loops
> ---
>
> Key: LOG4J2-2104
> URL: https://issues.apache.org/jira/browse/LOG4J2-2104
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Andrejus Chaliapinas
>Assignee: Ralph Goers
>Priority: Minor
>
> For v2.9.1 inside org.apache.logging.log4j.util.LoaderUtil and
> getClassLoaders() method we have lines 120-123 as such:
> ClassLoader parent = tcl;
> while (parent != null && !classLoaders.contains(parent)) {
> classLoaders.add(parent);
> }
> where it looks like some getParent() call is either missing or otherwise
> "while" loop is not needed.
> In line 111 tcl classloader already added into list of clasloaders:
> classLoaders.add(tcl);
> Was it an attempt to add all classloaders hierarchy or just some immediate
> parents?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2072) Support TLS configuration through FlumeAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16246523#comment-16246523 ] Ralph Goers commented on LOG4J2-2072: - >From past experience, changes to the factory methods break backwards >compatibility with apps that were using them directly. Changes to builders >don't have this effect. So it is desired that factory methods are changed to >builders before any changes are made. > Support TLS configuration through FlumeAppender > --- > > Key: LOG4J2-2072 > URL: https://issues.apache.org/jira/browse/LOG4J2-2072 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.9.1 >Reporter: Frank Swanson > > When using the FlumeAppnder with a FlumeAvroManager it would be nice to be > able to pass some properties through to the connect method for the RpcClient > to support SSL configuration. > The required properties to support the configuration are ~ > properties[0] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS, > "false"); > properties[1] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true"); > properties[2] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, > path_to_truststore); > properties[3] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD, > super_secret); > properties[4] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE, > "JKS"); > I am happy to provide a PR for this feature if supported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2072) Support TLS configuration through FlumeAppender
[ https://issues.apache.org/jira/browse/LOG4J2-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16246575#comment-16246575 ] Ralph Goers commented on LOG4J2-2072: - I hadn't really noticed that this only touched the manager. If there is no change to the parameters on the FlumeAppender then I agree, the conversion to use a builder is not required. > Support TLS configuration through FlumeAppender > --- > > Key: LOG4J2-2072 > URL: https://issues.apache.org/jira/browse/LOG4J2-2072 > Project: Log4j 2 > Issue Type: Bug > Components: Flume Appender >Affects Versions: 2.9.1 >Reporter: Frank Swanson > > When using the FlumeAppnder with a FlumeAvroManager it would be nice to be > able to pass some properties through to the connect method for the RpcClient > to support SSL configuration. > The required properties to support the configuration are ~ > properties[0] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUST_ALL_CERTS, > "false"); > properties[1] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_SSL, "true"); > properties[2] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE, > path_to_truststore); > properties[3] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_PASSWORD, > super_secret); > properties[4] = > Property.createProperty(RpcClientConfigurationConstants.CONFIG_TRUSTSTORE_TYPE, > "JKS"); > I am happy to provide a PR for this feature if supported. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247031#comment-16247031 ] Ralph Goers commented on LOG4J2-2106: - The problem isn't that rollover is synchronized but that checkRollover is synchronized. Two rollovers cannot be allowed to happen concurrently but we should be able to determine if rollovers are required concurrently. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: skopt > > My log file is very large, so I set the config about compression. The > policies is as follows: > > > > > When restart the service on the hour, this will trigger the two > policies. And I find that the log can not be written for a while. > I think, there would be two compress actions. In the file > RollingFileManager(package org.apache.logging.log4j.core.appender.rolling), > the actions will submit to asyncExecutor which will create a new thread for > every work. That mean the log file will be compressed by the two actions. Is > this the cause? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247031#comment-16247031 ] Ralph Goers edited comment on LOG4J2-2106 at 11/10/17 5:36 AM: --- The problem isn't that rollover is synchronized but that checkRollover is synchronized. Two rollovers cannot be allowed to happen concurrently but we should be able to determine if rollovers are required concurrently. Some of the isTriggeringEvent implementations might require synchronization but not all of them do. Specifically, CronTriggeringPolicy, CompositeTriggeringPolicy and OnStartupTriggeringPolicy do not. Furthermore, SizeBasedTriggeringPolicy and TimeBasedTriggeringPolicy each can be independently synchronized. was (Author: ralph.go...@dslextreme.com): The problem isn't that rollover is synchronized but that checkRollover is synchronized. Two rollovers cannot be allowed to happen concurrently but we should be able to determine if rollovers are required concurrently. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: skopt > > My log file is very large, so I set the config about compression. The > policies is as follows: > > > > > When restart the service on the hour, this will trigger the two > policies. And I find that the log can not be written for a while. > I think, there would be two compress actions. In the file > RollingFileManager(package org.apache.logging.log4j.core.appender.rolling), > the actions will submit to asyncExecutor which will create a new thread for > every work. That mean the log file will be compressed by the two actions. Is > this the cause? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247031#comment-16247031 ] Ralph Goers edited comment on LOG4J2-2106 at 11/10/17 5:38 AM: --- The problem isn't that rollover is synchronized but that checkRollover is synchronized. Two rollovers cannot be allowed to happen concurrently but we should be able to determine if rollovers are required concurrently. Some of the isTriggeringEvent implementations might require synchronization but not all of them do. Specifically, CronTriggeringPolicy, CompositeTriggeringPolicy and OnStartupTriggeringPolicy do not. Furthermore, SizeBasedTriggeringPolicy and TimeBasedTriggeringPolicy each can be independently synchronized - and don't need to synchronize on the FileManager as rollover does. was (Author: ralph.go...@dslextreme.com): The problem isn't that rollover is synchronized but that checkRollover is synchronized. Two rollovers cannot be allowed to happen concurrently but we should be able to determine if rollovers are required concurrently. Some of the isTriggeringEvent implementations might require synchronization but not all of them do. Specifically, CronTriggeringPolicy, CompositeTriggeringPolicy and OnStartupTriggeringPolicy do not. Furthermore, SizeBasedTriggeringPolicy and TimeBasedTriggeringPolicy each can be independently synchronized. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: skopt > > My log file is very large, so I set the config about compression. The > policies is as follows: > > > > > When restart the service on the hour, this will trigger the two > policies. And I find that the log can not be written for a while. > I think, there would be two compress actions. In the file > RollingFileManager(package org.apache.logging.log4j.core.appender.rolling), > the actions will submit to asyncExecutor which will create a new thread for > every work. That mean the log file will be compressed by the two actions. Is > this the cause? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-2106. - Resolution: Fixed Please checkout from master and verify the fix works for you. If it does, please close the issue. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: skopt > > My log file is very large, so I set the config about compression. The > policies is as follows: > > > > > When restart the service on the hour, this will trigger the two > policies. And I find that the log can not be written for a while. > I think, there would be two compress actions. In the file > RollingFileManager(package org.apache.logging.log4j.core.appender.rolling), > the actions will submit to asyncExecutor which will create a new thread for > every work. That mean the log file will be compressed by the two actions. Is > this the cause? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248918#comment-16248918 ] Ralph Goers commented on LOG4J2-2106: - That is a good question. Both rollover and checkRollover synchronize on the FileManager. So all calls to checkRollover are synchronized and will be blocked by rollover. rollover calls rollover(strategy). It waits for any async tasks to be completed before it will execute (to prevent trying to compress the same file). This will cause a second call to rollover to block until all async threads are complete, which will cause threads to block waiting to log. The logic in rollover(strategy) of waiting for the async thread to complete is correct and is required. But I don't believe logging should be blocked while the rollover completes. So this may only partially solve the reporter's issue. *Potential Issue 1* I made isTriggeringEvent in both TimeBasedTriggeringPolicy and SizeBasedTriggeringPolicy synchronized. However, both update the file time so both need to use the same lock. I will need to create a lock for them to synchronize on. *Potential Issue 2* That is really the same as Potential Issue 1 and the same fix should apply. *Optimization* I don't think that will work as the call to getNextTime needs to be locked against changes by calls to updateTime from SizeBasedTriggeringPolicy. That could be done by synchronizing those methods. But I now see another issue. It seems that we allow the patternProcessor to be replaced on a reconfiguration. Currently it copies the time values from the old pattern processor to the new one. But that only works properly if the pattern processor time values cannot be changed after the new copy is made or only use the new PatternProcessor after the values are copied. Right now updateData isn't synchronized at all. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: skopt > > My log file is very large, so I set the config about compression. The > policies is as follows: > > > > > When restart the service on the hour, this will trigger the two > policies. And I find that the log can not be written for a while. > I think, there would be two compress actions. In the file > RollingFileManager(package org.apache.logging.log4j.core.appender.rolling), > the actions will submit to asyncExecutor which will create a new thread for > every work. That mean the log file will be compressed by the two actions. Is > this the cause? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248918#comment-16248918 ] Ralph Goers edited comment on LOG4J2-2106 at 11/12/17 5:14 PM: --- That is a good question. Both rollover and checkRollover synchronize on the FileManager. So all calls to checkRollover are synchronized and will be blocked by rollover. rollover calls rollover(strategy). It waits for any async tasks to be completed before it will execute (to prevent trying to compress the same file). This will cause a second call to rollover to block until all async threads are complete, which will cause threads to block waiting to log. The logic in rollover(strategy) of waiting for the async thread to complete is correct and is required. But I don't believe logging should be blocked while the rollover completes. So this may only partially solve the reporter's issue. *Potential Issue 1* I made isTriggeringEvent in both TimeBasedTriggeringPolicy and SizeBasedTriggeringPolicy synchronized. However, both update the file time so both need to use the same lock. I will need to create a lock for them to synchronize on. *Potential Issue 2* That is really the same as Potential Issue 1 and the same fix should apply. *Optimization* I don't think that will work as the call to getNextTime needs to be locked against changes by calls to updateTime from SizeBasedTriggeringPolicy. That could be done by synchronizing those methods. But I now see another issue. It seems that we allow the patternProcessor to be replaced on a reconfiguration. Currently it copies the time values from the old pattern processor to the new one. But that only works properly if the pattern processor time values cannot be changed after the new copy is made or only use the new PatternProcessor after the values are copied. Right now updateData isn't synchronized at all. *Idea for future enhancement* I am not sure why this needs to be a future enhancement. setTriggeringPolicy should start the new Policy before it is set in the FileManager. There still could be threads trying to use the TriggeringPolicy after stop is called, but for the current TriggeringPolicies that won't cause a problem. was (Author: ralph.go...@dslextreme.com): That is a good question. Both rollover and checkRollover synchronize on the FileManager. So all calls to checkRollover are synchronized and will be blocked by rollover. rollover calls rollover(strategy). It waits for any async tasks to be completed before it will execute (to prevent trying to compress the same file). This will cause a second call to rollover to block until all async threads are complete, which will cause threads to block waiting to log. The logic in rollover(strategy) of waiting for the async thread to complete is correct and is required. But I don't believe logging should be blocked while the rollover completes. So this may only partially solve the reporter's issue. *Potential Issue 1* I made isTriggeringEvent in both TimeBasedTriggeringPolicy and SizeBasedTriggeringPolicy synchronized. However, both update the file time so both need to use the same lock. I will need to create a lock for them to synchronize on. *Potential Issue 2* That is really the same as Potential Issue 1 and the same fix should apply. *Optimization* I don't think that will work as the call to getNextTime needs to be locked against changes by calls to updateTime from SizeBasedTriggeringPolicy. That could be done by synchronizing those methods. But I now see another issue. It seems that we allow the patternProcessor to be replaced on a reconfiguration. Currently it copies the time values from the old pattern processor to the new one. But that only works properly if the pattern processor time values cannot be changed after the new copy is made or only use the new PatternProcessor after the values are copied. Right now updateData isn't synchronized at all. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: skopt > > My log file is very large, so I set the config about compression. The > policies is as follows: > > > > > When restart the service on the hour, this will trigger the two > policies. And I find that the log can not be written for a while. > I think, there would be two compress actions. In the file > RollingFileManager(package org.apache.logging.log4j.core.appender.rolling), > the actions will submit to asyncExecutor which will create a new thread for > every work. That mean the log file will be compressed by the two actions. Is > t
[jira] [Comment Edited] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248918#comment-16248918 ] Ralph Goers edited comment on LOG4J2-2106 at 11/12/17 5:16 PM: --- That is a good question. Both rollover and checkRollover synchronize on the FileManager. So all calls to checkRollover are synchronized and will be blocked by rollover. rollover calls rollover(strategy). It waits for any async tasks to be completed before it will execute (to prevent trying to compress the same file). This will cause a second call to rollover to block until all async threads are complete, which will cause threads to block waiting to log. The logic in rollover(strategy) of waiting for the async thread to complete is correct and is required. But I don't believe logging should be blocked while the rollover completes. So this may only partially solve the reporter's issue. *Potential Issue 1* I made isTriggeringEvent in both TimeBasedTriggeringPolicy and SizeBasedTriggeringPolicy synchronized. However, both update the file time so both need to use the same lock. I will need to create a lock for them to synchronize on. *Potential Issue 2* That is really the same as Potential Issue 1 and the same fix should apply. *Optimization* I don't think that will work as the call to getNextTime needs to be locked against changes by calls to updateTime from SizeBasedTriggeringPolicy. That could be done by synchronizing those methods. But I now see another issue. It seems that we allow the patternProcessor to be replaced on a reconfiguration. Currently it copies the time values from the old pattern processor to the new one. But that only works properly if the pattern processor time values cannot be changed after the new copy is made or only use the new PatternProcessor after the values are copied. Right now updateData isn't synchronized at all. Yes, the TriggeringPolicyUpdater shouldn't be necessary. *Idea for future enhancement* I am not sure why this needs to be a future enhancement. setTriggeringPolicy should start the new Policy before it is set in the FileManager. There still could be threads trying to use the TriggeringPolicy after stop is called, but for the current TriggeringPolicies that won't cause a problem. was (Author: ralph.go...@dslextreme.com): That is a good question. Both rollover and checkRollover synchronize on the FileManager. So all calls to checkRollover are synchronized and will be blocked by rollover. rollover calls rollover(strategy). It waits for any async tasks to be completed before it will execute (to prevent trying to compress the same file). This will cause a second call to rollover to block until all async threads are complete, which will cause threads to block waiting to log. The logic in rollover(strategy) of waiting for the async thread to complete is correct and is required. But I don't believe logging should be blocked while the rollover completes. So this may only partially solve the reporter's issue. *Potential Issue 1* I made isTriggeringEvent in both TimeBasedTriggeringPolicy and SizeBasedTriggeringPolicy synchronized. However, both update the file time so both need to use the same lock. I will need to create a lock for them to synchronize on. *Potential Issue 2* That is really the same as Potential Issue 1 and the same fix should apply. *Optimization* I don't think that will work as the call to getNextTime needs to be locked against changes by calls to updateTime from SizeBasedTriggeringPolicy. That could be done by synchronizing those methods. But I now see another issue. It seems that we allow the patternProcessor to be replaced on a reconfiguration. Currently it copies the time values from the old pattern processor to the new one. But that only works properly if the pattern processor time values cannot be changed after the new copy is made or only use the new PatternProcessor after the values are copied. Right now updateData isn't synchronized at all. *Idea for future enhancement* I am not sure why this needs to be a future enhancement. setTriggeringPolicy should start the new Policy before it is set in the FileManager. There still could be threads trying to use the TriggeringPolicy after stop is called, but for the current TriggeringPolicies that won't cause a problem. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: skopt > > My log file is very large, so I set the config about compression. The > policies is as follows: > > > > > When restart the service on the hour, this will trig
[jira] [Comment Edited] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248918#comment-16248918 ] Ralph Goers edited comment on LOG4J2-2106 at 11/12/17 5:17 PM: --- That is a good question. Both rollover and checkRollover synchronize on the FileManager. So all calls to checkRollover are synchronized and will be blocked by rollover. rollover calls rollover(strategy). It waits for any async tasks to be completed before it will execute (to prevent trying to compress the same file). This will cause a second call to rollover to block until all async threads are complete, which will cause threads to block waiting to log. The logic in rollover(strategy) of waiting for the async thread to complete is correct and is required. But I don't believe logging should be blocked while the rollover completes. So this may only partially solve the reporter's issue. Then again, I only added the lock because start was being called after the update was performed. *Potential Issue 1* I made isTriggeringEvent in both TimeBasedTriggeringPolicy and SizeBasedTriggeringPolicy synchronized. However, both update the file time so both need to use the same lock. I will need to create a lock for them to synchronize on. *Potential Issue 2* That is really the same as Potential Issue 1 and the same fix should apply. *Optimization* I don't think that will work as the call to getNextTime needs to be locked against changes by calls to updateTime from SizeBasedTriggeringPolicy. That could be done by synchronizing those methods. But I now see another issue. It seems that we allow the patternProcessor to be replaced on a reconfiguration. Currently it copies the time values from the old pattern processor to the new one. But that only works properly if the pattern processor time values cannot be changed after the new copy is made or only use the new PatternProcessor after the values are copied. Right now updateData isn't synchronized at all. Yes, the TriggeringPolicyUpdater shouldn't be necessary. *Idea for future enhancement* I am not sure why this needs to be a future enhancement. setTriggeringPolicy should start the new Policy before it is set in the FileManager. There still could be threads trying to use the TriggeringPolicy after stop is called, but for the current TriggeringPolicies that won't cause a problem. was (Author: ralph.go...@dslextreme.com): That is a good question. Both rollover and checkRollover synchronize on the FileManager. So all calls to checkRollover are synchronized and will be blocked by rollover. rollover calls rollover(strategy). It waits for any async tasks to be completed before it will execute (to prevent trying to compress the same file). This will cause a second call to rollover to block until all async threads are complete, which will cause threads to block waiting to log. The logic in rollover(strategy) of waiting for the async thread to complete is correct and is required. But I don't believe logging should be blocked while the rollover completes. So this may only partially solve the reporter's issue. *Potential Issue 1* I made isTriggeringEvent in both TimeBasedTriggeringPolicy and SizeBasedTriggeringPolicy synchronized. However, both update the file time so both need to use the same lock. I will need to create a lock for them to synchronize on. *Potential Issue 2* That is really the same as Potential Issue 1 and the same fix should apply. *Optimization* I don't think that will work as the call to getNextTime needs to be locked against changes by calls to updateTime from SizeBasedTriggeringPolicy. That could be done by synchronizing those methods. But I now see another issue. It seems that we allow the patternProcessor to be replaced on a reconfiguration. Currently it copies the time values from the old pattern processor to the new one. But that only works properly if the pattern processor time values cannot be changed after the new copy is made or only use the new PatternProcessor after the values are copied. Right now updateData isn't synchronized at all. Yes, the TriggeringPolicyUpdater shouldn't be necessary. *Idea for future enhancement* I am not sure why this needs to be a future enhancement. setTriggeringPolicy should start the new Policy before it is set in the FileManager. There still could be threads trying to use the TriggeringPolicy after stop is called, but for the current TriggeringPolicies that won't cause a problem. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: skopt > > My log file is very large, so I set the conf
[jira] [Comment Edited] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248918#comment-16248918 ] Ralph Goers edited comment on LOG4J2-2106 at 11/12/17 5:17 PM: --- That is a good question. Both rollover and checkRollover synchronize on the FileManager. So all calls to checkRollover are synchronized and will be blocked by rollover. rollover calls rollover(strategy). It waits for any async tasks to be completed before it will execute (to prevent trying to compress the same file). This will cause a second call to rollover to block until all async threads are complete, which will cause threads to block waiting to log. The logic in rollover(strategy) of waiting for the async thread to complete is correct and is required. But I don't believe logging should be blocked while the rollover completes. So this may only partially solve the reporter's issue. *Potential Issue 1* I made isTriggeringEvent in both TimeBasedTriggeringPolicy and SizeBasedTriggeringPolicy synchronized. However, both update the file time so both need to use the same lock. I will need to create a lock for them to synchronize on. *Potential Issue 2* That is really the same as Potential Issue 1 and the same fix should apply. *Optimization* I don't think that will work as the call to getNextTime needs to be locked against changes by calls to updateTime from SizeBasedTriggeringPolicy. That could be done by synchronizing those methods. But I now see another issue. It seems that we allow the patternProcessor to be replaced on a reconfiguration. Currently it copies the time values from the old pattern processor to the new one. But that only works properly if the pattern processor time values cannot be changed after the new copy is made or only use the new PatternProcessor after the values are copied. Right now updateData isn't synchronized at all. Yes, the TriggeringPolicyUpdater shouldn't be necessary. *Idea for future enhancement* I am not sure why this needs to be a future enhancement. setTriggeringPolicy should start the new Policy before it is set in the FileManager. There still could be threads trying to use the TriggeringPolicy after stop is called, but for the current TriggeringPolicies that won't cause a problem. Then again, I only added the lock because start was being called after the update was performed. was (Author: ralph.go...@dslextreme.com): That is a good question. Both rollover and checkRollover synchronize on the FileManager. So all calls to checkRollover are synchronized and will be blocked by rollover. rollover calls rollover(strategy). It waits for any async tasks to be completed before it will execute (to prevent trying to compress the same file). This will cause a second call to rollover to block until all async threads are complete, which will cause threads to block waiting to log. The logic in rollover(strategy) of waiting for the async thread to complete is correct and is required. But I don't believe logging should be blocked while the rollover completes. So this may only partially solve the reporter's issue. Then again, I only added the lock because start was being called after the update was performed. *Potential Issue 1* I made isTriggeringEvent in both TimeBasedTriggeringPolicy and SizeBasedTriggeringPolicy synchronized. However, both update the file time so both need to use the same lock. I will need to create a lock for them to synchronize on. *Potential Issue 2* That is really the same as Potential Issue 1 and the same fix should apply. *Optimization* I don't think that will work as the call to getNextTime needs to be locked against changes by calls to updateTime from SizeBasedTriggeringPolicy. That could be done by synchronizing those methods. But I now see another issue. It seems that we allow the patternProcessor to be replaced on a reconfiguration. Currently it copies the time values from the old pattern processor to the new one. But that only works properly if the pattern processor time values cannot be changed after the new copy is made or only use the new PatternProcessor after the values are copied. Right now updateData isn't synchronized at all. Yes, the TriggeringPolicyUpdater shouldn't be necessary. *Idea for future enhancement* I am not sure why this needs to be a future enhancement. setTriggeringPolicy should start the new Policy before it is set in the FileManager. There still could be threads trying to use the TriggeringPolicy after stop is called, but for the current TriggeringPolicies that won't cause a problem. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects
[jira] [Comment Edited] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248918#comment-16248918 ] Ralph Goers edited comment on LOG4J2-2106 at 11/12/17 5:20 PM: --- That is a good question. Both rollover and checkRollover synchronize on the FileManager. So all calls to checkRollover are synchronized and will be blocked by rollover. rollover calls rollover(strategy). It waits for any async tasks to be completed before it will execute (to prevent trying to compress the same file). This will cause a second call to rollover to block until all async threads are complete, which will cause threads to block waiting to log. The logic in rollover(strategy) of waiting for the async thread to complete is correct and is required. But I don't believe logging should be blocked while the rollover completes. So this may only partially solve the reporter's issue. *Potential Issue 1* I made isTriggeringEvent in both TimeBasedTriggeringPolicy and SizeBasedTriggeringPolicy synchronized. However, both update the file time so both need to use the same lock. I will need to create a lock for them to synchronize on. *Potential Issue 2* That is really the same as Potential Issue 1 and the same fix should apply. *Optimization* I don't think that will work as the call to getNextTime needs to be locked against changes by calls to updateTime from SizeBasedTriggeringPolicy. That could be done by synchronizing those methods. But I now see another issue. It seems that we allow the patternProcessor to be replaced on a reconfiguration. Currently it copies the time values from the old pattern processor to the new one. But that only works properly if the pattern processor time values cannot be changed after the new copy is made or only use the new PatternProcessor after the values are copied. Right now updateData isn't synchronized at all. *Idea for future enhancement* I am not sure why this needs to be a future enhancement. setTriggeringPolicy should start the new Policy before it is set in the FileManager. There still could be threads trying to use the TriggeringPolicy after stop is called, but for the current TriggeringPolicies that won't cause a problem. Then again, I only added the lock because start was being called after the update was performed. Yes, the TriggeringPolicyUpdater shouldn't be necessary. was (Author: ralph.go...@dslextreme.com): That is a good question. Both rollover and checkRollover synchronize on the FileManager. So all calls to checkRollover are synchronized and will be blocked by rollover. rollover calls rollover(strategy). It waits for any async tasks to be completed before it will execute (to prevent trying to compress the same file). This will cause a second call to rollover to block until all async threads are complete, which will cause threads to block waiting to log. The logic in rollover(strategy) of waiting for the async thread to complete is correct and is required. But I don't believe logging should be blocked while the rollover completes. So this may only partially solve the reporter's issue. *Potential Issue 1* I made isTriggeringEvent in both TimeBasedTriggeringPolicy and SizeBasedTriggeringPolicy synchronized. However, both update the file time so both need to use the same lock. I will need to create a lock for them to synchronize on. *Potential Issue 2* That is really the same as Potential Issue 1 and the same fix should apply. *Optimization* I don't think that will work as the call to getNextTime needs to be locked against changes by calls to updateTime from SizeBasedTriggeringPolicy. That could be done by synchronizing those methods. But I now see another issue. It seems that we allow the patternProcessor to be replaced on a reconfiguration. Currently it copies the time values from the old pattern processor to the new one. But that only works properly if the pattern processor time values cannot be changed after the new copy is made or only use the new PatternProcessor after the values are copied. Right now updateData isn't synchronized at all. Yes, the TriggeringPolicyUpdater shouldn't be necessary. *Idea for future enhancement* I am not sure why this needs to be a future enhancement. setTriggeringPolicy should start the new Policy before it is set in the FileManager. There still could be threads trying to use the TriggeringPolicy after stop is called, but for the current TriggeringPolicies that won't cause a problem. Then again, I only added the lock because start was being called after the update was performed. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects
[jira] [Commented] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248973#comment-16248973 ] Ralph Goers commented on LOG4J2-2106: - I have just realized that this fix also opens up another problem. With the changes multiple threads can now check isTriggeringEvent simultaneously. That means multiple threads can now think they are supposed to trigger a rollover. We can't have that. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: skopt > > My log file is very large, so I set the config about compression. The > policies is as follows: > > > > > When restart the service on the hour, this will trigger the two > policies. And I find that the log can not be written for a while. > I think, there would be two compress actions. In the file > RollingFileManager(package org.apache.logging.log4j.core.appender.rolling), > the actions will submit to asyncExecutor which will create a new thread for > every work. That mean the log file will be compressed by the two actions. Is > this the cause? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reopened LOG4J2-2106: - Reverted the changes while I rethink this. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: skopt > > My log file is very large, so I set the config about compression. The > policies is as follows: > > > > > When restart the service on the hour, this will trigger the two > policies. And I find that the log can not be written for a while. > I think, there would be two compress actions. In the file > RollingFileManager(package org.apache.logging.log4j.core.appender.rolling), > the actions will submit to asyncExecutor which will create a new thread for > every work. That mean the log file will be compressed by the two actions. Is > this the cause? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249630#comment-16249630 ] Ralph Goers commented on LOG4J2-2106: - [~rem...@yahoo.com] It seems to me that locking on the checkRollover method won't be required so long as each TriggeringPolicy only returns true once per rollover interval. The thing is, I don't know how to accomplish that for the SizeBasedTriggeringPolicy since it will remain true until the rollover puts a new file in place. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: skopt > > My log file is very large, so I set the config about compression. The > policies is as follows: > > > > > When restart the service on the hour, this will trigger the two > policies. And I find that the log can not be written for a while. > I think, there would be two compress actions. In the file > RollingFileManager(package org.apache.logging.log4j.core.appender.rolling), > the actions will submit to asyncExecutor which will create a new thread for > every work. That mean the log file will be compressed by the two actions. Is > this the cause? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16249630#comment-16249630 ] Ralph Goers edited comment on LOG4J2-2106 at 11/13/17 2:09 PM: --- [~rem...@yahoo.com] It seems to me that locking on the checkRollover method won't be required so long as each TriggeringPolicy only returns true once per rollover interval. The thing is, I don't know how to accomplish that for the SizeBasedTriggeringPolicy since it will remain true until the rollover puts a new file in place. We would need some logic to prevent it from being true twice and then maybe reset itself when the file size is again less than the max? was (Author: ralph.go...@dslextreme.com): [~rem...@yahoo.com] It seems to me that locking on the checkRollover method won't be required so long as each TriggeringPolicy only returns true once per rollover interval. The thing is, I don't know how to accomplish that for the SizeBasedTriggeringPolicy since it will remain true until the rollover puts a new file in place. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: skopt > > My log file is very large, so I set the config about compression. The > policies is as follows: > > > > > When restart the service on the hour, this will trigger the two > policies. And I find that the log can not be written for a while. > I think, there would be two compress actions. In the file > RollingFileManager(package org.apache.logging.log4j.core.appender.rolling), > the actions will submit to asyncExecutor which will create a new thread for > every work. That mean the log file will be compressed by the two actions. Is > this the cause? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (LOG4J2-2119) log4j-core do not include log4j-api
[ https://issues.apache.org/jira/browse/LOG4J2-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-2119. - Resolution: Cannot Reproduce > log4j-core do not include log4j-api > --- > > Key: LOG4J2-2119 > URL: https://issues.apache.org/jira/browse/LOG4J2-2119 > Project: Log4j 2 > Issue Type: Bug > Components: API >Affects Versions: 2.9.1 > Environment: Simple Tomcat Spring Application >Reporter: dennis lucero > Attachments: test.zip > > > When upgraded from log4j-core 2.8.2 or 2.9.0 to 2.9.1 logging stops working. > I have noticed this because of using spring-jcl (new component since spring 5 > to sanitize logging) which cannot discover log4j2 because of missing class > org.apache.logging.log4j.spi.ExtendedLogger which is part of API jar. > To reproduce this create simple maven-war aplication and add following to > pom.xml: > > org.apache.logging.log4j > log4j-core > 2.9.1 > > then run mvn package to assemble that war and inspect WEB-INF/lib. You will > see that log4j-api is missing. > This might be connected with following issue: LOG4J2-2084 > PS > I'm not sure why it missing since log4j-core pom.xml seems to have log4j-api > dependency. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (LOG4J2-2119) log4j-core do not include log4j-api
[ https://issues.apache.org/jira/browse/LOG4J2-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers updated LOG4J2-2119: Attachment: test.zip The attached zip file was created using mvn archetype:generate to create a standard maven web application. log4j-core version 2.9.1 was then added as a dependency. Running mvn package on this results in both log4j-core and log4j-api being present in WEB-INF/lib > log4j-core do not include log4j-api > --- > > Key: LOG4J2-2119 > URL: https://issues.apache.org/jira/browse/LOG4J2-2119 > Project: Log4j 2 > Issue Type: Bug > Components: API >Affects Versions: 2.9.1 > Environment: Simple Tomcat Spring Application >Reporter: dennis lucero > Attachments: test.zip > > > When upgraded from log4j-core 2.8.2 or 2.9.0 to 2.9.1 logging stops working. > I have noticed this because of using spring-jcl (new component since spring 5 > to sanitize logging) which cannot discover log4j2 because of missing class > org.apache.logging.log4j.spi.ExtendedLogger which is part of API jar. > To reproduce this create simple maven-war aplication and add following to > pom.xml: > > org.apache.logging.log4j > log4j-core > 2.9.1 > > then run mvn package to assemble that war and inspect WEB-INF/lib. You will > see that log4j-api is missing. > This might be connected with following issue: LOG4J2-2084 > PS > I'm not sure why it missing since log4j-core pom.xml seems to have log4j-api > dependency. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (LOG4J2-2061) RollingFileManager not removed when RollingFileAppender is stopped, using DirectWriteRolloverStrategy
[ https://issues.apache.org/jira/browse/LOG4J2-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reassigned LOG4J2-2061: --- Assignee: Ralph Goers > RollingFileManager not removed when RollingFileAppender is stopped, using > DirectWriteRolloverStrategy > - > > Key: LOG4J2-2061 > URL: https://issues.apache.org/jira/browse/LOG4J2-2061 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.0 > Environment: * >Reporter: Matthew Hill >Assignee: Ralph Goers >Priority: Blocker > Attachments: Log4jIssue.zip > > > When programmatically creating an instance of RollingFileAppender using > RollingFileAppender.newBuilder.(config options).build(), an instance of > RollingFileManager is created in AbstractManager.getManager(...), and this > instance is stored in the hashmap AbstractManager.MAP as well as on the > instance of RollingFileAppender in the super class > AbstractOutputStreamAppender. This manager is created and stored in the > AbstractManager.MAP with the name FILE_PATTERN (since we cannot create an > instance of RollingFileAppender with a file name using the > DirectWriteRolloverStrategy). However, the same manager is created with a > NAME of NULL since it is trying to use file name as the name of the manager, > but this parameter is not allowed using DirectWriteRolloverStrategy. > The problem here is that the RollingFileManager is created with a name of > FILE NAME (i.e., NULL when using DirectWriteRolloverStrategy) and added to > the hashmap with a key of FILE PATTERN, but when the rolling file appender is > stopped, it attempts to remove its manager from this MAP using > RollingFileManager.name, which equates to FILE NAME which is NULL. > Consider the following example: > * create a rolling file appender using the DirectWriteRolloverStrategy with a > file pattern of 'output.%i.log' > * a RollingFileManager is created with the name NULL, but put in > AbstractManager.MAP with the name 'output.%i.log' > * the rolling file appender is used to write a few line of log file > * the rolling file appender is stopped using RollingFileAppender.stop(..) > * the RollingFileManager is NOT removed from AbstractManager.MAP since it is > trying to remove FILE NAME but it is keyed on FILE PATTERN > * a NEW instance of rolling file appender is created using the > DirectWriteRolloverStrategy with the SAME file pattern of 'output.%i.log'. > * a new instance of RollingFileManager is NOT created, as it already exists > in the MAP, so the old instance is simply returned > * the instance of RollingFileManager for the new instance of > RollingFileAppender has a closed output stream, meaning that no logging is > possible. > In the above example you can see that if the old rolling file appender's > output stream is closed, and a new instance created with the same file > pattern, then the old manager will be used. I see no easy way of recreating > this output stream. > I found no documentation regarding why one cannot set the FILE NAME for a > RollingFileAppender using DirectWriteRolloverStrategy. Being able to > configure this may also solve the problem (unless it causes issues > elsewhere), but another possible fix to this issue is to create the > RollingFileManager with the name FILE PATTERN when using the > DirectWriteRolloverStrategy. This way we add to the MAP the instance of > RollingFileManager with the key FILE PATTERN, and we remove from the MAP > RollingFileManager.name which equals FILE PATTERN -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (LOG4J2-1768) MDC.clear() is broken in Log4j-1_2-api = 2.4
[ https://issues.apache.org/jira/browse/LOG4J2-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers closed LOG4J2-1768. --- Resolution: Incomplete Closing due to lack of response from reporter. > MDC.clear() is broken in Log4j-1_2-api = 2.4 > > > Key: LOG4J2-1768 > URL: https://issues.apache.org/jira/browse/LOG4J2-1768 > Project: Log4j 2 > Issue Type: Bug >Affects Versions: 2.4 >Reporter: A >Priority: Blocker > > MDC.clear() seems to be broken in Log4j-1_2-api = 2.4 as it is not clearing > the entries in MDC. > Though, I have not tried in higher versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (LOG4J2-2064) Publish new log4j-server on maven central repository
[ https://issues.apache.org/jira/browse/LOG4J2-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reassigned LOG4J2-2064: --- Assignee: Ralph Goers > Publish new log4j-server on maven central repository > > > Key: LOG4J2-2064 > URL: https://issues.apache.org/jira/browse/LOG4J2-2064 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: Hüseyin Kartal >Assignee: Ralph Goers >Priority: Blocker > Fix For: 2.10.0 > > > Server components moved from the log4j-core module to new module log4j-tools, > but is not available in the central repository. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2121) DefaultRolloverStrategy max = 5 does not limit nuber of files
[
https://issues.apache.org/jira/browse/LOG4J2-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255357#comment-16255357
]
Ralph Goers commented on LOG4J2-2121:
-
With you configuration you should be limited to 5 per day. Are you getting more
than 5 per day?
> DefaultRolloverStrategy max = 5 does not limit nuber of files
> -
>
> Key: LOG4J2-2121
> URL: https://issues.apache.org/jira/browse/LOG4J2-2121
> Project: Log4j 2
> Issue Type: Question
> Environment: Linux RedHat
>Reporter: Seweryn Habdank-Wojewodzki
>
> Dears,
> I have very simple configuration of the RollingFile appender
> {code:xml}
> fileName="${env:LOG_DIR}/${application}/endpoint.log"
>
> filePattern="$${env:LOG_DIR}/$${application}/$${date:-MM}/endpoint-%d{-MM-dd}-%i.log">
>
> %d{-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
>
>
>
>
>
>
> {code}
> This configuration works partly good. Every day there is created file in
> folder _-MM_.
> That is expected.
> What is not expected - it is that the process is not limited at all. I mean
> there are more than 5 files in all folders.
> Questions:
> Is it something wrong with configuration?
> is max=5 considered to be the numeber of files or folders (in my case months)?
> or max=5 is ignored at all.
> I had read some hints in SO: [How does Log4j2 DefaultRolloverStrategy's max
> attribute really
> work?|https://stackoverflow.com/questions/24551768/how-does-log4j2-defaultrolloverstrategys-max-attribute-really-work]
> Thanks in advance for help.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2122) Log4j2 - Overriding log file programaitically
[
https://issues.apache.org/jira/browse/LOG4J2-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255731#comment-16255731
]
Ralph Goers commented on LOG4J2-2122:
-
What is class Test and method m1? Is it supposed to be an appender?
> Log4j2 - Overriding log file programaitically
> -
>
> Key: LOG4J2-2122
> URL: https://issues.apache.org/jira/browse/LOG4J2-2122
> Project: Log4j 2
> Issue Type: Question
>Reporter: Durgarao
>
> In log4j1 we have an option to overriding the log file programatically by
> calling below 2 methods together
> # setAppend(false);
> # activateOptions();
> What is equivalent option in log4j2?. Below is my sample code
> {code:java}
> class Test{
>public void m1(){
> setAppend(false)
> activateOptions()
>}
> }
> {code}
> Could someone please provide log4j2 code for above m1 method
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2104) LoaderUtil getClassLoaders() method and while loops
[
https://issues.apache.org/jira/browse/LOG4J2-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16256128#comment-16256128
]
Ralph Goers commented on LOG4J2-2104:
-
To do what? Did you test the code in master?
> LoaderUtil getClassLoaders() method and while loops
> ---
>
> Key: LOG4J2-2104
> URL: https://issues.apache.org/jira/browse/LOG4J2-2104
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Andrejus Chaliapinas
>Assignee: Ralph Goers
>Priority: Minor
>
> For v2.9.1 inside org.apache.logging.log4j.util.LoaderUtil and
> getClassLoaders() method we have lines 120-123 as such:
> ClassLoader parent = tcl;
> while (parent != null && !classLoaders.contains(parent)) {
> classLoaders.add(parent);
> }
> where it looks like some getParent() call is either missing or otherwise
> "while" loop is not needed.
> In line 111 tcl classloader already added into list of clasloaders:
> classLoaders.add(tcl);
> Was it an attempt to add all classloaders hierarchy or just some immediate
> parents?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2110) Log4jServletContextListener skips initialization and thusly never calls stop()
[
https://issues.apache.org/jira/browse/LOG4J2-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16258180#comment-16258180
]
Ralph Goers commented on LOG4J2-2110:
-
Why is contextInitialized never called?
> Log4jServletContextListener skips initialization and thusly never calls stop()
> --
>
> Key: LOG4J2-2110
> URL: https://issues.apache.org/jira/browse/LOG4J2-2110
> Project: Log4j 2
> Issue Type: Bug
> Components: Web/Servlet
>Affects Versions: 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1
>Reporter: Thomas Beauvais
>Priority: Critical
>
> {{Log4jServletContextListener}} is not working in Tomcat 8 or 8.5 as it's
> never initialized.
> The {{contextInitialized}} is never called and thus it never sets the
> {{servletContext}}.
> This is checked when a {{servletContext}} is destroyed and ignored every time.
> The outcome, is that our customer appenders are never stopped leading to
> resource leaks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2106) May blocked when two compress action
[ https://issues.apache.org/jira/browse/LOG4J2-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16258274#comment-16258274 ] Ralph Goers commented on LOG4J2-2106: - OK. I will look into that. > May blocked when two compress action > > > Key: LOG4J2-2106 > URL: https://issues.apache.org/jira/browse/LOG4J2-2106 > Project: Log4j 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.9.1 >Reporter: skopt > > My log file is very large, so I set the config about compression. The > policies is as follows: > > > > > When restart the service on the hour, this will trigger the two > policies. And I find that the log can not be written for a while. > I think, there would be two compress actions. In the file > RollingFileManager(package org.apache.logging.log4j.core.appender.rolling), > the actions will submit to asyncExecutor which will create a new thread for > every work. That mean the log file will be compressed by the two actions. Is > this the cause? > Thanks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2110) Log4jServletContextListener skips initialization and thusly never calls stop()
[
https://issues.apache.org/jira/browse/LOG4J2-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16258612#comment-16258612
]
Ralph Goers commented on LOG4J2-2110:
-
Did you ask about it on the Tomcat user's or dev lists? Is the
Log4jServletContainerInitializer onStartup method being called? Is your
application compliant with the 3.0 spec?
Providing a web app that duplicates the problem would be nice so we could
verify the problem. If there is really a bug in Tomcat then I'd prefer to see
that fixed then for us to use this workaround.
> Log4jServletContextListener skips initialization and thusly never calls stop()
> --
>
> Key: LOG4J2-2110
> URL: https://issues.apache.org/jira/browse/LOG4J2-2110
> Project: Log4j 2
> Issue Type: Bug
> Components: Web/Servlet
>Affects Versions: 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1
>Reporter: Thomas Beauvais
>Priority: Critical
>
> {{Log4jServletContextListener}} is not working in Tomcat 8 or 8.5 as it's
> never initialized.
> The {{contextInitialized}} is never called and thus it never sets the
> {{servletContext}}.
> This is checked when a {{servletContext}} is destroyed and ignored every time.
> The outcome, is that our customer appenders are never stopped leading to
> resource leaks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2110) Log4jServletContextListener skips initialization and thusly never calls stop()
[
https://issues.apache.org/jira/browse/LOG4J2-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16258658#comment-16258658
]
Ralph Goers commented on LOG4J2-2110:
-
If Log4jServletContainerInitializer's onStartup method is being called with a
null servletContext then that is definitely a bug in Tomcat and should be
reported to them to be fixed. It also should be causing a NullPointerException
in the onStartup method, which you didn't mention.
Again, please provide a sample web app that demonstrates the problem.
> Log4jServletContextListener skips initialization and thusly never calls stop()
> --
>
> Key: LOG4J2-2110
> URL: https://issues.apache.org/jira/browse/LOG4J2-2110
> Project: Log4j 2
> Issue Type: Bug
> Components: Web/Servlet
>Affects Versions: 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1
>Reporter: Thomas Beauvais
>Priority: Critical
>
> {{Log4jServletContextListener}} is not working in Tomcat 8 or 8.5 as it's
> never initialized.
> The {{contextInitialized}} is never called and thus it never sets the
> {{servletContext}}.
> This is checked when a {{servletContext}} is destroyed and ignored every time.
> The outcome, is that our customer appenders are never stopped leading to
> resource leaks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2110) Log4jServletContextListener skips initialization and thusly never calls stop()
[
https://issues.apache.org/jira/browse/LOG4J2-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16258658#comment-16258658
]
Ralph Goers edited comment on LOG4J2-2110 at 11/19/17 10:52 PM:
If Log4jServletContainerInitializer's onStartup method is being called with a
null servletContext then that is definitely a bug in Tomcat and should be
reported to them to be fixed. It also should be causing a NullPointerException
in the onStartup method, which you didn't mention. Furthermore, even your fix
wouldn't work because it is passing the servletContext passed to onStartup to
the ServletContextListener. I suspect you are trying to say that the
ServletContext is not in the ServletContextEvent, but that would also be a bug
in Tomcat and would need to be reported to them.
Again, please provide a sample web app that demonstrates the problem.
was (Author: ralph.go...@dslextreme.com):
If Log4jServletContainerInitializer's onStartup method is being called with a
null servletContext then that is definitely a bug in Tomcat and should be
reported to them to be fixed. It also should be causing a NullPointerException
in the onStartup method, which you didn't mention.
Again, please provide a sample web app that demonstrates the problem.
> Log4jServletContextListener skips initialization and thusly never calls stop()
> --
>
> Key: LOG4J2-2110
> URL: https://issues.apache.org/jira/browse/LOG4J2-2110
> Project: Log4j 2
> Issue Type: Bug
> Components: Web/Servlet
>Affects Versions: 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1
>Reporter: Thomas Beauvais
>Priority: Critical
>
> {{Log4jServletContextListener}} is not working in Tomcat 8 or 8.5 as it's
> never initialized.
> The {{contextInitialized}} is never called and thus it never sets the
> {{servletContext}}.
> This is checked when a {{servletContext}} is destroyed and ignored every time.
> The outcome, is that our customer appenders are never stopped leading to
> resource leaks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2129) Log4j2 throws NoClassDefFoundError in Java 9
[
https://issues.apache.org/jira/browse/LOG4J2-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266241#comment-16266241
]
Ralph Goers commented on LOG4J2-2129:
-
Have you found any documentation on why the two "uses" declarations are
necessary? All I could find is that uses is required to name the class used by
the ServiceLoader. Not that there is anything wrong with your fix but I am
wondering why it is needed.
> Log4j2 throws NoClassDefFoundError in Java 9
>
>
> Key: LOG4J2-2129
> URL: https://issues.apache.org/jira/browse/LOG4J2-2129
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.10.0, 2.10.1
> Environment: Java 9
>Reporter: Blazej
>
> When I execute a sample project
> (https://github.com/bbucko/log4j2-jpms-sample) in Java 9 a following
> exception is thrown:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError: Could not
> initialize class org.apache.logging.log4j.util.PropertiesUtil
> at
> org.apache.logging.log4j/org.apache.logging.log4j.status.StatusLogger.(StatusLogger.java:71)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.LogManager.(LogManager.java:60)
> {code}
> Exception is a little bit misleading because it seems that true root cause
> can be found here:
> {code}
> java.util.ServiceConfigurationError:
> org.apache.logging.log4j.util.PropertySource: module org.apache.logging.log4j
> does not declare `uses`
> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:588)
> at java.base/java.util.ServiceLoader.checkCaller(ServiceLoader.java:574)
> at java.base/java.util.ServiceLoader.(ServiceLoader.java:503)
> at java.base/java.util.ServiceLoader.load(ServiceLoader.java:1684)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.PropertiesUtil$Environment.(PropertiesUtil.java:319)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.PropertiesUtil$Environment.(PropertiesUtil.java:310)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.PropertiesUtil.(PropertiesUtil.java:69)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.PropertiesUtil.(PropertiesUtil.java:49)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.Constants.(Constants.java:30)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:375)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.spi.AbstractLogger.createClassForProperty(AbstractLogger.java:198)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.spi.AbstractLogger.(AbstractLogger.java:88)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.LogManager.(LogManager.java:60)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2129) Log4j2 throws NoClassDefFoundError in Java 9
[
https://issues.apache.org/jira/browse/LOG4J2-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266241#comment-16266241
]
Ralph Goers edited comment on LOG4J2-2129 at 11/26/17 11:26 PM:
I see that we are calling ServiceLoader to load a PropertySource from
PropertiesUtil. I don't see why a uses for PropertiesUtil is necessary.
However, I do see another ServiceLoader call to load a ThreadInfoFactory class
in ThreadDumpMessage, so that needs to be added as well.
was (Author: ralph.go...@dslextreme.com):
Have you found any documentation on why the two "uses" declarations are
necessary? All I could find is that uses is required to name the class used by
the ServiceLoader. Not that there is anything wrong with your fix but I am
wondering why it is needed.
> Log4j2 throws NoClassDefFoundError in Java 9
>
>
> Key: LOG4J2-2129
> URL: https://issues.apache.org/jira/browse/LOG4J2-2129
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.10.0, 2.10.1
> Environment: Java 9
>Reporter: Blazej
>
> When I execute a sample project
> (https://github.com/bbucko/log4j2-jpms-sample) in Java 9 a following
> exception is thrown:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError: Could not
> initialize class org.apache.logging.log4j.util.PropertiesUtil
> at
> org.apache.logging.log4j/org.apache.logging.log4j.status.StatusLogger.(StatusLogger.java:71)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.LogManager.(LogManager.java:60)
> {code}
> Exception is a little bit misleading because it seems that true root cause
> can be found here:
> {code}
> java.util.ServiceConfigurationError:
> org.apache.logging.log4j.util.PropertySource: module org.apache.logging.log4j
> does not declare `uses`
> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:588)
> at java.base/java.util.ServiceLoader.checkCaller(ServiceLoader.java:574)
> at java.base/java.util.ServiceLoader.(ServiceLoader.java:503)
> at java.base/java.util.ServiceLoader.load(ServiceLoader.java:1684)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.PropertiesUtil$Environment.(PropertiesUtil.java:319)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.PropertiesUtil$Environment.(PropertiesUtil.java:310)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.PropertiesUtil.(PropertiesUtil.java:69)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.PropertiesUtil.(PropertiesUtil.java:49)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.Constants.(Constants.java:30)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:375)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.spi.AbstractLogger.createClassForProperty(AbstractLogger.java:198)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.spi.AbstractLogger.(AbstractLogger.java:88)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.LogManager.(LogManager.java:60)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2129) Log4j2 throws NoClassDefFoundError in Java 9
[
https://issues.apache.org/jira/browse/LOG4J2-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266254#comment-16266254
]
Ralph Goers commented on LOG4J2-2129:
-
That's OK. Did you verify that a uses for PropertiesUtil is necessary or will
it work with just the uses for PropertySource?
> Log4j2 throws NoClassDefFoundError in Java 9
>
>
> Key: LOG4J2-2129
> URL: https://issues.apache.org/jira/browse/LOG4J2-2129
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.10.0, 2.10.1
> Environment: Java 9
>Reporter: Blazej
>
> When I execute a sample project
> (https://github.com/bbucko/log4j2-jpms-sample) in Java 9 a following
> exception is thrown:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError: Could not
> initialize class org.apache.logging.log4j.util.PropertiesUtil
> at
> org.apache.logging.log4j/org.apache.logging.log4j.status.StatusLogger.(StatusLogger.java:71)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.LogManager.(LogManager.java:60)
> {code}
> Exception is a little bit misleading because it seems that true root cause
> can be found here:
> {code}
> java.util.ServiceConfigurationError:
> org.apache.logging.log4j.util.PropertySource: module org.apache.logging.log4j
> does not declare `uses`
> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:588)
> at java.base/java.util.ServiceLoader.checkCaller(ServiceLoader.java:574)
> at java.base/java.util.ServiceLoader.(ServiceLoader.java:503)
> at java.base/java.util.ServiceLoader.load(ServiceLoader.java:1684)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.PropertiesUtil$Environment.(PropertiesUtil.java:319)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.PropertiesUtil$Environment.(PropertiesUtil.java:310)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.PropertiesUtil.(PropertiesUtil.java:69)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.PropertiesUtil.(PropertiesUtil.java:49)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.util.Constants.(Constants.java:30)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:375)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.spi.AbstractLogger.createClassForProperty(AbstractLogger.java:198)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.spi.AbstractLogger.(AbstractLogger.java:88)
> at
> org.apache.logging.log4j/org.apache.logging.log4j.LogManager.(LogManager.java:60)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16268780#comment-16268780 ] Ralph Goers commented on LOG4J2-2133: - [~olegk] It has never been valid before java 9 to be looking for classes under the META-INF directory. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16269230#comment-16269230 ] Ralph Goers commented on LOG4J2-2133: - My original plan was to have a log4j-android that replaced log4j-api and had an implementation that tied it to androids logging system. But apparently some users want some version of log4j-core. To do that we really need to create a version of core that only includes stuff that could run in android and move the other stuff somewhere else. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16269405#comment-16269405 ] Ralph Goers commented on LOG4J2-2133: - [~mikaelstaldal] We will only be able to do that when Android supports Java 9. The StackLocator code must reside in the API and we have to have a Java 9 version of it. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275995#comment-16275995 ] Ralph Goers commented on LOG4J2-2133: - [~olegk] I think this problem is to get worse for Android users before it gets better. Adding a module-info.java file to support a jar as a Java 9 module is just beginning to happen and I believe it will only increase. In fact, it is surprising that HttpClient isn't looking to do that, since lots of components use it. It is unfortunate that Oracle decided to use a Java file instead of a JSON file, but we can't change it now. Log4j 1.8.x actually added a module-info.java file before Log4j did. So while you may be able to use SLF4J 1.7.x for a while, users will not be able to upgrade without encountering the same problem you are experiencing with Log4j. I suspect the only solution we will be able to have for this is to either have a separate jar for Android, which will admittedly be a pain, but since they seem to be stuck in the past I don't see any way around it. Suggestions are welcome. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275995#comment-16275995 ] Ralph Goers edited comment on LOG4J2-2133 at 12/3/17 4:47 PM: -- [~olegk] I think this problem is going to get worse for Android users before it gets better. Adding a module-info.java file to support a jar as a Java 9 module is just beginning to happen and I believe it will only increase. In fact, it is surprising that HttpClient isn't looking to do that, since lots of components use it. It is unfortunate that Oracle decided to use a Java file instead of a JSON file, but we can't change it now. Log4j 1.8.x actually added a module-info.java file before Log4j did. So while you may be able to use SLF4J 1.7.x for a while, users will not be able to upgrade without encountering the same problem you are experiencing with Log4j. I suspect the only solution we will be able to have for this is to either have a separate jar for Android, which will admittedly be a pain, but since they seem to be stuck in the past I don't see any way around it. Suggestions are welcome. was (Author: ralph.go...@dslextreme.com): [~olegk] I think this problem is to get worse for Android users before it gets better. Adding a module-info.java file to support a jar as a Java 9 module is just beginning to happen and I believe it will only increase. In fact, it is surprising that HttpClient isn't looking to do that, since lots of components use it. It is unfortunate that Oracle decided to use a Java file instead of a JSON file, but we can't change it now. Log4j 1.8.x actually added a module-info.java file before Log4j did. So while you may be able to use SLF4J 1.7.x for a while, users will not be able to upgrade without encountering the same problem you are experiencing with Log4j. I suspect the only solution we will be able to have for this is to either have a separate jar for Android, which will admittedly be a pain, but since they seem to be stuck in the past I don't see any way around it. Suggestions are welcome. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275996#comment-16275996 ] Ralph Goers commented on LOG4J2-2133: - I just had a thought. If we could create a module-info.json file that is compiled into a module-info.class at runtime this problem could be solved. Unfortunately, I don't know how to automagically generate the class file at runtime. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275996#comment-16275996 ] Ralph Goers edited comment on LOG4J2-2133 at 12/3/17 4:51 PM: -- I just had a thought. If we could create a module-info.json file that is compiled into a module-info.class at runtime this problem could be solved. Unfortunately, I don't know how to automagically generate the class file at runtime. This is similar to Remko's idea of including the module-info class file under a different extension and then adding it at run time. I fear it suffers from the same problems as I believe Java is actually looking at the files in the jar when looking for the module-info. was (Author: ralph.go...@dslextreme.com): I just had a thought. If we could create a module-info.json file that is compiled into a module-info.class at runtime this problem could be solved. Unfortunately, I don't know how to automagically generate the class file at runtime. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276017#comment-16276017 ] Ralph Goers commented on LOG4J2-2133: - I don't see how KISS applies to module-info. KISS means use the simplest approach to implement a feature. What you are suggesting would mean log4j-api would no longer be a Java 9 module. StackLocator uses StackWalker (Java 9) which requires lamdas (Java 8). Although it is possible to write code equivalent to lambdas prior to Java 9, it wouldn't be pretty. And it would require reflection, which would probably make our stack walking slower than it is in Java 8 instead of faster. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276017#comment-16276017 ] Ralph Goers edited comment on LOG4J2-2133 at 12/3/17 6:08 PM: -- I don't see how KISS applies to module-info. KISS means use the simplest approach to implement a feature. What you are suggesting would mean log4j-api would no longer be a Java 9 module. We need a solution that supports both Java 9 and Android. StackLocator uses StackWalker (Java 9) which requires lamdas (Java 8). Although it is possible to write code equivalent to lambdas prior to Java 9, it wouldn't be pretty. And it would require reflection, which would probably make our stack walking slower than it is in Java 8 instead of faster. was (Author: ralph.go...@dslextreme.com): I don't see how KISS applies to module-info. KISS means use the simplest approach to implement a feature. What you are suggesting would mean log4j-api would no longer be a Java 9 module. StackLocator uses StackWalker (Java 9) which requires lamdas (Java 8). Although it is possible to write code equivalent to lambdas prior to Java 9, it wouldn't be pretty. And it would require reflection, which would probably make our stack walking slower than it is in Java 8 instead of faster. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276026#comment-16276026 ] Ralph Goers commented on LOG4J2-2133: - [~jvz] We definitely should link to upstream tickets as well as open tickets against the offending tools - as I did for the Maven bundle plugin, but that alone won't satisfy users whose stuff isn't working now. Yes, trying to come up with hacks around the decision to have module-info be a class file is almost certainly a fools errand as it would probably break more stuff than it "fixes". > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276026#comment-16276026 ] Ralph Goers edited comment on LOG4J2-2133 at 12/3/17 6:33 PM: -- [~jvz] We definitely should link to upstream tickets as well as open tickets against the offending tools - as I did for the Maven bundle plugin, but that alone won't satisfy users whose stuff isn't working now. Yes, trying to come up with hacks around the decision to have module-info be a class file is almost certainly a fools errand as it would probably break more stuff than it "fixes". As far as module-info.java goes, the only thing I can think of to do is to remove module-info.java and just use the manifest entry to have it be a named automatic module as our other jars are. Eventually this may be a problem since it is using ServiceLoader and it might need to find the implementation of the service in a module. was (Author: ralph.go...@dslextreme.com): [~jvz] We definitely should link to upstream tickets as well as open tickets against the offending tools - as I did for the Maven bundle plugin, but that alone won't satisfy users whose stuff isn't working now. Yes, trying to come up with hacks around the decision to have module-info be a class file is almost certainly a fools errand as it would probably break more stuff than it "fixes". > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276066#comment-16276066 ] Ralph Goers commented on LOG4J2-2133: - In addition to https://issues.apache.org/jira/browse/FELIX-5527 I have created https://issuetracker.google.com/u/1/issues/70118537. I have also started a thread at http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050282.html. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276066#comment-16276066 ] Ralph Goers edited comment on LOG4J2-2133 at 12/3/17 8:14 PM: -- In addition to https://issues.apache.org/jira/browse/FELIX-5527 I have created https://issuetracker.google.com/u/1/issues/70118537. I have also started a thread at http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050282.html. [~garydgregory] By that logic we should just abandon the Log4j API and adopt SLF4J's. was (Author: ralph.go...@dslextreme.com): In addition to https://issues.apache.org/jira/browse/FELIX-5527 I have created https://issuetracker.google.com/u/1/issues/70118537. I have also started a thread at http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050282.html. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275995#comment-16275995 ] Ralph Goers edited comment on LOG4J2-2133 at 12/3/17 10:23 PM: --- [~olegk] I think this problem is going to get worse for Android users before it gets better. Adding a module-info.java file to support a jar as a Java 9 module is just beginning to happen and I believe it will only increase. In fact, it is surprising that HttpClient isn't looking to do that, since lots of components use it. It is unfortunate that Oracle decided to use a Java file instead of a JSON file, but we can't change it now. SLF4J 1.8.x actually added a module-info.java file before Log4j did. So while you may be able to use SLF4J 1.7.x for a while, users will not be able to upgrade without encountering the same problem you are experiencing with Log4j. I suspect the only solution we will be able to have for this is to either have a separate jar for Android, which will admittedly be a pain, but since they seem to be stuck in the past I don't see any way around it. Suggestions are welcome. was (Author: ralph.go...@dslextreme.com): [~olegk] I think this problem is going to get worse for Android users before it gets better. Adding a module-info.java file to support a jar as a Java 9 module is just beginning to happen and I believe it will only increase. In fact, it is surprising that HttpClient isn't looking to do that, since lots of components use it. It is unfortunate that Oracle decided to use a Java file instead of a JSON file, but we can't change it now. Log4j 1.8.x (Ralph, did you mean SLF4J 1.8?) actually added a module-info.java file before Log4j did. So while you may be able to use SLF4J 1.7.x for a while, users will not be able to upgrade without encountering the same problem you are experiencing with Log4j. I suspect the only solution we will be able to have for this is to either have a separate jar for Android, which will admittedly be a pain, but since they seem to be stuck in the past I don't see any way around it. Suggestions are welcome. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276133#comment-16276133 ] Ralph Goers commented on LOG4J2-2133: - Yes, it can be an automatic module. But as I said previously, I suspect this will cause problems for anyone trying to implement the log4j API where the implementation is in a module, since the Log4j API locates the implementation via ServiceLoader. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276133#comment-16276133 ] Ralph Goers edited comment on LOG4J2-2133 at 12/3/17 10:27 PM: --- Yes, it can be an automatic module. But as I said previously, I suspect this will cause problems for anyone trying to implement the log4j API where the implementation is in a module, since the Log4j API locates the implementation via ServiceLoader. FWIW - I noticed that changes were made yesterday for the next version of Logback to include a module-info.java. It will require SLF4J 1.8.x. was (Author: ralph.go...@dslextreme.com): Yes, it can be an automatic module. But as I said previously, I suspect this will cause problems for anyone trying to implement the log4j API where the implementation is in a module, since the Log4j API locates the implementation via ServiceLoader. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276133#comment-16276133 ] Ralph Goers edited comment on LOG4J2-2133 at 12/3/17 10:28 PM: --- Yes, it can be an automatic module. But as I said previously, I suspect this will cause problems for anyone trying to implement the log4j API where the implementation is in a module, since the Log4j API locates the implementation via ServiceLoader. FWIW - I noticed that changes were made yesterday for the next version of Logback to include a module-info.java. It will require SLF4J 1.8.x, so IMO the only real solution is for Android to fix its build tool. was (Author: ralph.go...@dslextreme.com): Yes, it can be an automatic module. But as I said previously, I suspect this will cause problems for anyone trying to implement the log4j API where the implementation is in a module, since the Log4j API locates the implementation via ServiceLoader. FWIW - I noticed that changes were made yesterday for the next version of Logback to include a module-info.java. It will require SLF4J 1.8.x. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276133#comment-16276133 ] Ralph Goers edited comment on LOG4J2-2133 at 12/3/17 10:30 PM: --- Yes, it can be an automatic module. But as I said previously, I suspect this will cause problems for anyone trying to implement the log4j API where the implementation is in a module, since the Log4j API locates the implementation via ServiceLoader. FWIW - I noticed that changes were made yesterday for the next version of Logback to include a module-info.java. It will require SLF4J 1.8.x, so IMO the only real solution is for Android to fix its build tool. But I should also point out that SLF4J has a special implementation for android - https://www.slf4j.org/android/. was (Author: ralph.go...@dslextreme.com): Yes, it can be an automatic module. But as I said previously, I suspect this will cause problems for anyone trying to implement the log4j API where the implementation is in a module, since the Log4j API locates the implementation via ServiceLoader. FWIW - I noticed that changes were made yesterday for the next version of Logback to include a module-info.java. It will require SLF4J 1.8.x, so IMO the only real solution is for Android to fix its build tool. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276148#comment-16276148 ] Ralph Goers commented on LOG4J2-2133: - [~olegk] I/We don't get offended by user's critiques/criticisms of the work. However, while it may not be relevant to this issue, I would like to understand why SLF4J feels lighter and friendlier to you. From my perspective, had Log4j made the API a different logging project instead of a module in Log4j it would be extremely similar to SLF4J, except for the items we typically mention. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-667) Add customization for JSON Layout keys and values
[ https://issues.apache.org/jira/browse/LOG4J2-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276181#comment-16276181 ] Ralph Goers commented on LOG4J2-667: Rather than add a bunch of options to JsonLayout would it not make more sense to allow plugins to be configured to do the filtering, possibly renaming or formatting, similar to how PatternConverters are added to the PatternLayout? > Add customization for JSON Layout keys and values > - > > Key: LOG4J2-667 > URL: https://issues.apache.org/jira/browse/LOG4J2-667 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Danny Sullivan > Labels: JSON > > I really like the JSON Layout feature as it's easily parsed by splunk. I > would like to see more customization on the type of information that's > included in each json message, similar to the Pattern Layout such as MDC and > NDC, the locations etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-667) Add customization for JSON Layout keys and values
[ https://issues.apache.org/jira/browse/LOG4J2-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276249#comment-16276249 ] Ralph Goers commented on LOG4J2-667: [~rem...@yahoo.com] Yup, that sounds like exactly what I had in mind. But the plugin interface should allow any kind of transformer. > Add customization for JSON Layout keys and values > - > > Key: LOG4J2-667 > URL: https://issues.apache.org/jira/browse/LOG4J2-667 > Project: Log4j 2 > Issue Type: Improvement >Reporter: Danny Sullivan > Labels: JSON > > I really like the JSON Layout feature as it's easily parsed by splunk. I > would like to see more customization on the type of information that's > included in each json message, similar to the Pattern Layout such as MDC and > NDC, the locations etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2139) JSONLayout ability to rename keys in log output - particularly locationInfo "source"
[
https://issues.apache.org/jira/browse/LOG4J2-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276260#comment-16276260
]
Ralph Goers commented on LOG4J2-2139:
-
This could easily be a duplicate of LOG4J2-667 if we implement what I
recommended there.
> JSONLayout ability to rename keys in log output - particularly locationInfo
> "source"
>
>
> Key: LOG4J2-2139
> URL: https://issues.apache.org/jira/browse/LOG4J2-2139
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
>Reporter: Daniel Kirkdorffer
>Priority: Minor
> Labels: json
>
> We ran into a problem when setting {{locationInfo}} to {{true}} when
> ingesting logs into Kibana. The problem had to do with a conflict with
> another existing key named {{"source"}} of type String, and the fact that
> {{locationInfo}} produces an Object called "source".
> So it would be nice to have a way to supply a different Object name. Perhaps
> this could be broadened so that other key names could also be renamed?
> Maybe there is a way to do this already?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2141) Log4j2 is taking an extra of 11 Milli seconds to write into the file?
[
https://issues.apache.org/jira/browse/LOG4J2-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16277014#comment-16277014
]
Ralph Goers commented on LOG4J2-2141:
-
I am guessing that you are running into the granularity of Windows schedular
granularity.
https://stackoverflow.com/questions/9518106/winapi-sleep-function-call-sleeps-for-longer-than-expected
and https://forum.sysinternals.com/bug-in-waitable-timers_topic16229.html.
> Log4j2 is taking an extra of 11 Milli seconds to write into the file?
> -
>
> Key: LOG4J2-2141
> URL: https://issues.apache.org/jira/browse/LOG4J2-2141
> Project: Log4j 2
> Issue Type: Question
> Components: Core
>Affects Versions: 2.9.1
> Environment: Windows 10
> Java SE 1.8
> NetBeans 8.2
> Log4j 2.9.1
>Reporter: hemachandra
>Priority: Critical
> Labels: easyfix, newbie
>
> I am new to Log4j2. I have written a simple program that actually logs data
> into RollingRandomAccessFile using log4j2. Below is the program:
> {code}
> public class Log4j2Example {
> /**
> * @param args the command line arguments
> */
> public static Logger mlogger = null;
> public static void main(String[] args) throws InterruptedException {
> mlogger = LogManager.getLogger("Messages-log");
> int i = 0;
> while (true) {
> String str = "Hello" + i;
> System.out.println(str);
> mlogger.info(str);
> i++;
> Thread.sleep(20);
> }
> }
> }
> {code}
> **My log4j2.xml file**
> {code}
>
>
>
> fileName="Log4J/Messages-${date:-MM-dd}.log"
>immediateflush="true"
> filePattern="Log4J/Messages-%d{MM-dd--HH}-%i.log.gz">
>
> %d{-MM-dd HH:mm:ss.SSS} %p %m%n
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I am writing a simple statement into the log file sleeping for 20
> milli-seconds for every record. Now the time stamp in the file should be for
> example:
> If the first statement is logged at 17:20:32:354 then the next statement
> should be logged at 17:20:32:374 but it is logging at 17:20:32:384. An extra
> of 11 milli-seconds constantly is added for every record. Below is my log
> file output
> {noformat}
> 2017-12-04 17:40:42.205 INFO Hello11
> 2017-12-04 17:40:42.236 INFO Hello12
> 2017-12-04 17:40:42.268 INFO Hello13
> 2017-12-04 17:40:42.299 INFO Hello14
> 2017-12-04 17:40:42.330 INFO Hello15
> 2017-12-04 17:40:42.361 INFO Hello16
> 2017-12-04 17:40:42.393 INFO Hello17
> 2017-12-04 17:40:42.424 INFO Hello18
> {noformat}
> You can see that first statement is logged at .205 milli second and the
> second statement is logged at .236 milli second. Infact I am sleeping the
> thread for 20 milliseconds so the correct timestamp should be .226 milli
> second. What am I doing wrong here? I need the exact time stamp to be written
> as it is very important in production. I have also tried this with log4j 1
> but the same result. I have synchronized my System time with Internet time
> also. And one thing I found it worked perfectly with 5 and 15 milli-seconds
> of sleep but from 20 milli seconds this is causing a big issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16278881#comment-16278881 ] Ralph Goers commented on LOG4J2-2133: - I don't see how it helps to tell all the non-Android users that they now need Log4j-api and log4j-xxx just to get the API to work. While not a firm commitment, http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050306.html seems to imply that Google has at least recognized the problem. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16278881#comment-16278881 ] Ralph Goers edited comment on LOG4J2-2133 at 12/5/17 5:22 PM: -- I don't see how it helps to tell all the non-Android users that they now need Log4j-api and log4j-xxx just to get the API to work. I'm also not clear what "everything that should have gone into core" is. While not a firm commitment, http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050306.html seems to imply that Google has at least recognized the problem. was (Author: ralph.go...@dslextreme.com): I don't see how it helps to tell all the non-Android users that they now need Log4j-api and log4j-xxx just to get the API to work. While not a firm commitment, http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050306.html seems to imply that Google has at least recognized the problem. > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16279160#comment-16279160 ] Ralph Goers edited comment on LOG4J2-2133 at 12/5/17 8:45 PM: -- [~mikaelstaldal] Yes, I saw that. If you really went through the API code you would find much less that you could really move. Many of the Message classes have to stay in the API because they are used by AbstractLogger. In addition, most of the Message classes should be usable by any implementation of the Log4j 2 API, which is a large reason why a lot of stuff is in the API. Almost everything in spi has to be in the API to allow the API to bind to an implementation. The StatusLogger is used by the API to log errors as well as by core - without that finding binding errors would be very hard. Only a few classes in util could realistically be moved. [~olegk] The only code in the API that is remotely related to JMX is ProcessIdUtil, which really should be in core (and can be moved if we want core to be a multi-release jar also). As I have said, StackLocator cannot move out of the API unless there is some other way to obtain the ClassLoader of the caller of LogManager.getLogger(). That code has always been in the API, it was just refactored for the 2.9 release to allow it to be overridden by a Java 9 implementation. Prior to that release it was in a class called ReflectionUtil. was (Author: ralph.go...@dslextreme.com): [~mikaelstaldal] Yes, I saw that. If you really went through the API code you would find much less that you could really move. Many of the Message classes have to stay in the API because they are used by AbstractLogger. In addition, most of the Message classes should be usable by any implementation of the Log4j 2 API, which is a large reason why a lot of stuff is in the API. Almost everything in spi has to be in the API to allow the API to bind to an implementation. The StatusLogger is used by the API to log errors as well as by core - without that finding binding errors would be very hard. Only a few classes in util could realistically be moved. [~olegk] The only code in the API that is remotely related to JMX is ProcessIdUtil, which really should be in core (and can be moved if we want core to be a multi-release jar also). As I have said, StackLocator cannot move out of the API unless there is some other way to obtain the ClassLoader of the caller of LogManager.getLogger(). > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16279160#comment-16279160 ] Ralph Goers commented on LOG4J2-2133: - [~mikaelstaldal] Yes, I saw that. If you really went through the API code you would find much less that you could really move. Many of the Message classes have to stay in the API because they are used by AbstractLogger. In addition, most of the Message classes should be usable by any implementation of the Log4j 2 API, which is a large reason why a lot of stuff is in the API. Almost everything in spi has to be in the API to allow the API to bind to an implementation. The StatusLogger is used by the API to log errors as well as by core - without that finding binding errors would be very hard. Only a few classes in util could realistically be moved. [~olegk] The only code in the API that is remotely related to JMX is ProcessIdUtil, which really should be in core (and can be moved if we want core to be a multi-release jar also). As I have said, StackLocator cannot move out of the API unless there is some other way to obtain the ClassLoader of the caller of LogManager.getLogger(). > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2133) Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 classes (class file version 53)
[ https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280965#comment-16280965 ] Ralph Goers commented on LOG4J2-2133: - I just received an email that contained this "Very latest Android Studio comes with two compilers, dx and d8. https://developer.android.com/studio/preview/features/index.html. I hear that both compilers know to skip module-info files." Can someone validate this? > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53) > - > > Key: LOG4J2-2133 > URL: https://issues.apache.org/jira/browse/LOG4J2-2133 > Project: Log4j 2 > Issue Type: Wish > Components: API >Affects Versions: 2.9.1, 2.10.0 >Reporter: Oleg Kalnichevski > Attachments: Screenshot from 2017-11-28 09-41-37.png > > > Log4J 2 appears incompatible with Android platform due to inclusion of Java 9 > classes (class file version 53). Please see screenshot attached. > I fully admit that there might be a way to make Android ignore those files > but it is still disheartening that Log4J 2 APIs have dependencies on things > that go beyond providing a thin logging abstraction layer. > Oleg -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2038) [Android] Compilation error when using log4j 2.9.0
[ https://issues.apache.org/jira/browse/LOG4J2-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281349#comment-16281349 ] Ralph Goers commented on LOG4J2-2038: - https://issuetracker.google.com/issues/70118537 was created to track the issues with the Android tools. I received an email today that a new release of the Android tools are available that will ignore the module-info file. I am unclear if it also ignores the class files in META-INF/versions. http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050382.html > [Android] Compilation error when using log4j 2.9.0 > -- > > Key: LOG4J2-2038 > URL: https://issues.apache.org/jira/browse/LOG4J2-2038 > Project: Log4j 2 > Issue Type: Bug > Components: API, Core >Affects Versions: 2.9.0 >Reporter: Mounica Kodela >Priority: Blocker > > while trying to run the app with 2.9.0 we are facing the below exception. > Error:Error converting bytecode to dex: > Cause: Dex cannot parse version 53 byte code. > This is caused by library dependencies that have been compiled using Java 8 > or above. > If you are using the 'java' gradle plugin in a library submodule add > targetCompatibility = '1.7' > sourceCompatibility = '1.7' > to that submodule's build.gradle file. > ...while parsing > META-INF/versions/9/org/apache/logging/log4j/util/ProcessIdUtil.class > lintRelease is giving below warnings: > Error processing > /Users/h126951/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.9.0/e0dcd508dfc4864a2f5a1963d6ffad170d970375/log4j-api-2.9.0.jar:META-INF/versions/9/org/apache/logging/log4j/util/ProcessIdUtil.class: > broken class file? > Error processing > /Users/h126951/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.9.0/e0dcd508dfc4864a2f5a1963d6ffad170d970375/log4j-api-2.9.0.jar:META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class: > broken class file? > Error processing > /Users/h126951/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.9.0/e0dcd508dfc4864a2f5a1963d6ffad170d970375/log4j-api-2.9.0.jar:META-INF/versions/9/org/apache/logging/log4j/util/ProcessIdUtil.class: > broken class file? > Error processing > /Users/h126951/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.9.0/e0dcd508dfc4864a2f5a1963d6ffad170d970375/log4j-api-2.9.0.jar:META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class: > broken class file? > Error processing > /Users/h126951/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.9.0/e0dcd508dfc4864a2f5a1963d6ffad170d970375/log4j-api-2.9.0.jar:META-INF/versions/9/org/apache/logging/log4j/util/ProcessIdUtil.class: > broken class file? > Error processing > /Users/h126951/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.9.0/e0dcd508dfc4864a2f5a1963d6ffad170d970375/log4j-api-2.9.0.jar:META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class: > broken class file? > Error processing > /Users/h126951/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.9.0/e0dcd508dfc4864a2f5a1963d6ffad170d970375/log4j-api-2.9.0.jar:META-INF/versions/9/org/apache/logging/log4j/util/ProcessIdUtil.class: > broken class file? > Error processing > /Users/h126951/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.9.0/e0dcd508dfc4864a2f5a1963d6ffad170d970375/log4j-api-2.9.0.jar:META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class: > broken class file? > Error processing > /Users/h126951/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.9.0/e0dcd508dfc4864a2f5a1963d6ffad170d970375/log4j-api-2.9.0.jar:META-INF/versions/9/org/apache/logging/log4j/util/ProcessIdUtil.class: > broken class file? > Error processing > /Users/h126951/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.9.0/e0dcd508dfc4864a2f5a1963d6ffad170d970375/log4j-api-2.9.0.jar:META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class: > broken class file? > Error processing > /Users/h126951/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.9.0/e0dcd508dfc4864a2f5a1963d6ffad170d970375/log4j-api-2.9.0.jar:META-INF/versions/9/org/apache/logging/log4j/util/ProcessIdUtil.class: > broken class file? > Error processing > /Users/h126951/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.9.0/e0dcd508dfc4864a2f5a1963d6ffad170d970375/log4j-api-2.9.0.jar:META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class: > broken class file? > Error processing > /Users/h126951/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.9.0/e0dcd508dfc4864a2f5a1963d6ffad170d970375/log4j-api-2.9.0.jar:META-INF/versions/9/org/a
[jira] [Created] (LOG4J2-2146) The maven bundle plugin fails due to Java 9
Ralph Goers created LOG4J2-2146: --- Summary: The maven bundle plugin fails due to Java 9 Key: LOG4J2-2146 URL: https://issues.apache.org/jira/browse/LOG4J2-2146 Project: Log4j 2 Issue Type: Improvement Components: API Affects Versions: 2.10.0 Reporter: Ralph Goers The Log4j2 API build fails if the clean lifecycle is not specified. This is because of problems in the Maven Bundle Plugin. The latest version of the plugin does not ignore module-info.class and the bnd tool does not ignore classes in META-INF/versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (LOG4J2-2146) The maven bundle plugin fails due to Java 9
[ https://issues.apache.org/jira/browse/LOG4J2-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers closed LOG4J2-2146. --- > The maven bundle plugin fails due to Java 9 > --- > > Key: LOG4J2-2146 > URL: https://issues.apache.org/jira/browse/LOG4J2-2146 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.10.0 >Reporter: Ralph Goers > Fix For: 2.10.1 > > > The Log4j2 API build fails if the clean lifecycle is not specified. This is > because of problems in the Maven Bundle Plugin. The latest version of the > plugin does not ignore module-info.class and the bnd tool does not ignore > classes in META-INF/versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (LOG4J2-2146) The maven bundle plugin fails due to Java 9
[ https://issues.apache.org/jira/browse/LOG4J2-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-2146. - Resolution: Fixed Fix Version/s: 2.10.1 > The maven bundle plugin fails due to Java 9 > --- > > Key: LOG4J2-2146 > URL: https://issues.apache.org/jira/browse/LOG4J2-2146 > Project: Log4j 2 > Issue Type: Improvement > Components: API >Affects Versions: 2.10.0 >Reporter: Ralph Goers > Fix For: 2.10.1 > > > The Log4j2 API build fails if the clean lifecycle is not specified. This is > because of problems in the Maven Bundle Plugin. The latest version of the > plugin does not ignore module-info.class and the bnd tool does not ignore > classes in META-INF/versions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2147) What is Apache's recommendation to use file type for configuration
[ https://issues.apache.org/jira/browse/LOG4J2-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281879#comment-16281879 ] Ralph Goers commented on LOG4J2-2147: - The Apache Logging project doesn't have a preference for the format of the configuration file. You can safely use any of the supported types. I personally prefer xml as I find it the most readable. Others prefer JSON or YAML. Some users really like properties files so we support that too. > What is Apache's recommendation to use file type for configuration > -- > > Key: LOG4J2-2147 > URL: https://issues.apache.org/jira/browse/LOG4J2-2147 > Project: Log4j 2 > Issue Type: Question >Reporter: Varun Sharma >Priority: Minor > > Hi, > I am setting up Log4j 2 for a new project. There are various way we can > configure log4j2, using XML file, properties file etc. What is the > recommendation from Apache for file type to configure. Like which format will > have forward compatibility or any other thing. What is preference from Apache? > Regards, > Varun -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2147) What is Apache's recommendation to use file type for configuration
[ https://issues.apache.org/jira/browse/LOG4J2-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283755#comment-16283755 ] Ralph Goers commented on LOG4J2-2147: - Marking as resolved since there have been no other comments. > What is Apache's recommendation to use file type for configuration > -- > > Key: LOG4J2-2147 > URL: https://issues.apache.org/jira/browse/LOG4J2-2147 > Project: Log4j 2 > Issue Type: Question >Reporter: Varun Sharma >Priority: Minor > > Hi, > I am setting up Log4j 2 for a new project. There are various way we can > configure log4j2, using XML file, properties file etc. What is the > recommendation from Apache for file type to configure. Like which format will > have forward compatibility or any other thing. What is preference from Apache? > Regards, > Varun -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (LOG4J2-2147) What is Apache's recommendation to use file type for configuration
[ https://issues.apache.org/jira/browse/LOG4J2-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-2147. - Resolution: Information Provided > What is Apache's recommendation to use file type for configuration > -- > > Key: LOG4J2-2147 > URL: https://issues.apache.org/jira/browse/LOG4J2-2147 > Project: Log4j 2 > Issue Type: Question >Reporter: Varun Sharma >Priority: Minor > > Hi, > I am setting up Log4j 2 for a new project. There are various way we can > configure log4j2, using XML file, properties file etc. What is the > recommendation from Apache for file type to configure. Like which format will > have forward compatibility or any other thing. What is preference from Apache? > Regards, > Varun -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2123) logger filter in composite logger not combined properly
[
https://issues.apache.org/jira/browse/LOG4J2-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284195#comment-16284195
]
Ralph Goers commented on LOG4J2-2123:
-
If someone doesn't beat me to it I will try to look at it this weekend.
> logger filter in composite logger not combined properly
> ---
>
> Key: LOG4J2-2123
> URL: https://issues.apache.org/jira/browse/LOG4J2-2123
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Jacob Tolar
>
> When using a composite logger with DefaultMergeStrategy, logger filters
> aren't combined properly.
> Specifically, if the 'parent' configuration for the logger has no filter and
> the child configuration does, all attributes and children of the child filter
> are dropped from the composite configuration.
> For example, if my parent logger has:
> {code}
>
>
>
>
> {code}
> and the child logger has:
> {code}
>
>
> />
>
>
> {code}
> DefaultMergeStrategy creates a RegexFilter node in the composite
> configuration with no attributes. You end up getting a message like this when
> the RegexFilter is constructed:
> {code}
> 2017-11-21 12:02:26,733 main ERROR A regular expression must be provided for
> RegexFilter
> {code}
> Here:
> https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/config/composite/DefaultMergeStrategy.java#L172-L174
> A new copy of the filter node is created, but the children and attributes
> aren't added to the new nodes.
> If the parent logger config does have a filter, it looks like it works
> correctly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (LOG4J2-2123) logger filter in composite logger not combined properly
[
https://issues.apache.org/jira/browse/LOG4J2-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-2123.
-
Resolution: Fixed
Fix Version/s: 2.10.1
Patch applied - Please verify and close.
> logger filter in composite logger not combined properly
> ---
>
> Key: LOG4J2-2123
> URL: https://issues.apache.org/jira/browse/LOG4J2-2123
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Jacob Tolar
> Fix For: 2.10.1
>
>
> When using a composite logger with DefaultMergeStrategy, logger filters
> aren't combined properly.
> Specifically, if the 'parent' configuration for the logger has no filter and
> the child configuration does, all attributes and children of the child filter
> are dropped from the composite configuration.
> For example, if my parent logger has:
> {code}
>
>
>
>
> {code}
> and the child logger has:
> {code}
>
>
> />
>
>
> {code}
> DefaultMergeStrategy creates a RegexFilter node in the composite
> configuration with no attributes. You end up getting a message like this when
> the RegexFilter is constructed:
> {code}
> 2017-11-21 12:02:26,733 main ERROR A regular expression must be provided for
> RegexFilter
> {code}
> Here:
> https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/config/composite/DefaultMergeStrategy.java#L172-L174
> A new copy of the filter node is created, but the children and attributes
> aren't added to the new nodes.
> If the parent logger config does have a filter, it looks like it works
> correctly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2123) logger filter in composite logger not combined properly
[
https://issues.apache.org/jira/browse/LOG4J2-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16286563#comment-16286563
]
Ralph Goers commented on LOG4J2-2123:
-
You are welcome. Please keep contributing!
> logger filter in composite logger not combined properly
> ---
>
> Key: LOG4J2-2123
> URL: https://issues.apache.org/jira/browse/LOG4J2-2123
> Project: Log4j 2
> Issue Type: Bug
>Reporter: Jacob Tolar
> Fix For: 2.10.1
>
>
> When using a composite logger with DefaultMergeStrategy, logger filters
> aren't combined properly.
> Specifically, if the 'parent' configuration for the logger has no filter and
> the child configuration does, all attributes and children of the child filter
> are dropped from the composite configuration.
> For example, if my parent logger has:
> {code}
>
>
>
>
> {code}
> and the child logger has:
> {code}
>
>
> />
>
>
> {code}
> DefaultMergeStrategy creates a RegexFilter node in the composite
> configuration with no attributes. You end up getting a message like this when
> the RegexFilter is constructed:
> {code}
> 2017-11-21 12:02:26,733 main ERROR A regular expression must be provided for
> RegexFilter
> {code}
> Here:
> https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/config/composite/DefaultMergeStrategy.java#L172-L174
> A new copy of the filter node is created, but the children and attributes
> aren't added to the new nodes.
> If the parent logger config does have a filter, it looks like it works
> correctly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2055) ServiceConfigurationError in Tomcat when Log4j is used as the logging implementation
[
https://issues.apache.org/jira/browse/LOG4J2-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287744#comment-16287744
]
Ralph Goers commented on LOG4J2-2055:
-
This stack trace is a little different in that it involves resolving the
PropertySource instead of the Provider. While the fix may be the same the
problem should be reproduced to see why it can't access the PropertySource it
found.
> ServiceConfigurationError in Tomcat when Log4j is used as the logging
> implementation
>
>
> Key: LOG4J2-2055
> URL: https://issues.apache.org/jira/browse/LOG4J2-2055
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.9.1
>Reporter: Ralph Goers
>Assignee: Ralph Goers
> Fix For: 2.10.0
>
>
> When Log4j is used as the Tomcat logging implementation using the
> log4j-appserver Handler applications using Log4j will fail to start trying to
> load a Log4jProvider they cannot access. The following will appear in the
> startup log.
> {code}
> 2017-09-23 17:29:43,223 [localhost-startStop-1] ERROR
> o.a.c.c.ContainerBase.addChildInternal:755 - ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/AuditCatalog]]
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
> ~[catalina.jar:8.5.20]
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
> [catalina.jar:8.5.20]
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
> [catalina.jar:8.5.20]
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
> [catalina.jar:8.5.20]
> at
> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:988)
> [catalina.jar:8.5.20]
> at
> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1860)
> [catalina.jar:8.5.20]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
> [?:?]
> at java.lang.Thread.run(Thread.java:844) [?:?]
> Caused by: java.util.ServiceConfigurationError:
> org.apache.logging.log4j.spi.Provider:
> org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
> at java.util.ServiceLoader.fail(ServiceLoader.java:588) ~[?:?]
> at java.util.ServiceLoader.access$200(ServiceLoader.java:390) ~[?:?]
> at
> java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1231)
> ~[?:?]
> at
> java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1259)
> ~[?:?]
> at java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1294) ~[?:?]
> at java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1379) ~[?:?]
> at
> org.apache.logging.log4j.util.ProviderUtil.loadProviders(ProviderUtil.java:101)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.util.ProviderUtil.(ProviderUtil.java:67)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.util.ProviderUtil.lazyInit(ProviderUtil.java:142)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.util.ProviderUtil.hasProviders(ProviderUtil.java:126)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.spi.ThreadContextMapFactory.createThreadContextMap(ThreadContextMapFactory.java:73)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.ThreadContext.init(ThreadContext.java:224)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.ThreadContext.(ThreadContext.java:203)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:83)
> ~[log4j-core-2.9.1.jar:2.9.1]
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:67)
> ~[log4j-core-2.9.1.jar:2.9.1]
> at
> org.apache.logging.log4j.core.lookup.ContextMapLookup.(ContextMapLookup.java:34)
> ~[log4j-core-2.9.1.jar:2.9.1]
> at
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:117)
> ~[log4j-core-2.9.1.jar:2.9.1]
> at
> org.apache.logging.log4j.web.Log4jWebInitializ
[jira] [Commented] (LOG4J2-2055) ServiceConfigurationError in Tomcat when Log4j is used as the logging implementation
[
https://issues.apache.org/jira/browse/LOG4J2-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287850#comment-16287850
]
Ralph Goers commented on LOG4J2-2055:
-
Since this issue is closed I would suggest you open a different issue for this.
> ServiceConfigurationError in Tomcat when Log4j is used as the logging
> implementation
>
>
> Key: LOG4J2-2055
> URL: https://issues.apache.org/jira/browse/LOG4J2-2055
> Project: Log4j 2
> Issue Type: Bug
> Components: API
>Affects Versions: 2.9.1
>Reporter: Ralph Goers
>Assignee: Ralph Goers
> Fix For: 2.10.0
>
>
> When Log4j is used as the Tomcat logging implementation using the
> log4j-appserver Handler applications using Log4j will fail to start trying to
> load a Log4jProvider they cannot access. The following will appear in the
> startup log.
> {code}
> 2017-09-23 17:29:43,223 [localhost-startStop-1] ERROR
> o.a.c.c.ContainerBase.addChildInternal:755 - ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/AuditCatalog]]
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
> ~[catalina.jar:8.5.20]
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:752)
> [catalina.jar:8.5.20]
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:728)
> [catalina.jar:8.5.20]
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
> [catalina.jar:8.5.20]
> at
> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:988)
> [catalina.jar:8.5.20]
> at
> org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1860)
> [catalina.jar:8.5.20]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
> [?:?]
> at java.lang.Thread.run(Thread.java:844) [?:?]
> Caused by: java.util.ServiceConfigurationError:
> org.apache.logging.log4j.spi.Provider:
> org.apache.logging.log4j.core.impl.Log4jProvider not a subtype
> at java.util.ServiceLoader.fail(ServiceLoader.java:588) ~[?:?]
> at java.util.ServiceLoader.access$200(ServiceLoader.java:390) ~[?:?]
> at
> java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1231)
> ~[?:?]
> at
> java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1259)
> ~[?:?]
> at java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1294) ~[?:?]
> at java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1379) ~[?:?]
> at
> org.apache.logging.log4j.util.ProviderUtil.loadProviders(ProviderUtil.java:101)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.util.ProviderUtil.(ProviderUtil.java:67)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.util.ProviderUtil.lazyInit(ProviderUtil.java:142)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.util.ProviderUtil.hasProviders(ProviderUtil.java:126)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.spi.ThreadContextMapFactory.createThreadContextMap(ThreadContextMapFactory.java:73)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.ThreadContext.init(ThreadContext.java:224)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.ThreadContext.(ThreadContext.java:203)
> ~[log4j-api-2.9.2-SNAPSHOT.jar:2.9.2-SNAPSHOT]
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createDefaultInjector(ContextDataInjectorFactory.java:83)
> ~[log4j-core-2.9.1.jar:2.9.1]
> at
> org.apache.logging.log4j.core.impl.ContextDataInjectorFactory.createInjector(ContextDataInjectorFactory.java:67)
> ~[log4j-core-2.9.1.jar:2.9.1]
> at
> org.apache.logging.log4j.core.lookup.ContextMapLookup.(ContextMapLookup.java:34)
> ~[log4j-core-2.9.1.jar:2.9.1]
> at
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:117)
> ~[log4j-core-2.9.1.jar:2.9.1]
> at
> org.apache.logging.log4j.web.Log4jWebInitializerImpl.(Log4jWebInitializerImpl.java:63)
> ~[?:?]
> at
> org.apache.logging.log4j.web.Log4jWebInitializerImpl.initialize(Log4jWebInitializerImpl.
[jira] [Commented] (LOG4J2-2154) Support resetting log levels
[
https://issues.apache.org/jira/browse/LOG4J2-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16293882#comment-16293882
]
Ralph Goers commented on LOG4J2-2154:
-
I've looked at the code referenced in the link above and it isn't clear to me
what the point is of what you are trying to do. It would be best if you could
email the users list with what your requirements are in terms of how you want
logging to behave and we can provide feedback on how to achieve that. Doing a
straight translation of the code form Log4j 1 to Log4j 2 is usually not the
best way to achieve the desired results.
> Support resetting log levels
>
>
> Key: LOG4J2-2154
> URL: https://issues.apache.org/jira/browse/LOG4J2-2154
> Project: Log4j 2
> Issue Type: Bug
>Reporter: paladox
>
> Hi, would it be possible to support resetting log levels please?
> In log4j1.x we did the following
> private static void reset() throws MalformedURLException {
> for (Enumeration logger = LogManager.getCurrentLoggers();
> logger.hasMoreElements(); ) {
> logger.nextElement().setLevel(null);
> }
> String path = System.getProperty(JAVA_OPTIONS_LOG_CONFIG);
> if (Strings.isNullOrEmpty(path)) {
> PropertyConfigurator.configure(Loader.getResource(LOG_CONFIGURATION));
> } else {
> PropertyConfigurator.configure(new URL(path));
> }
> }
> but in log4j2 setting null on log level results in null pointer when calling
> updateLogger().
> Also there dosen't seem to be a good replacement for
> PropertyConfigurator.configure as everything else just resets back to results
> thus if you used java to create appenders or anything else it would be erased
> and would not be re added until you restarted the java application.
> See https://gerrit-review.googlesource.com/#/c/gerrit/+/142811/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2157) Don't create exit message in traceExit(R) when logging is disabled
[
https://issues.apache.org/jira/browse/LOG4J2-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16300407#comment-16300407
]
Ralph Goers commented on LOG4J2-2157:
-
I suspect calling isEnabled before doing anything would be the way to handle
this.
> Don't create exit message in traceExit(R) when logging is disabled
> --
>
> Key: LOG4J2-2157
> URL: https://issues.apache.org/jira/browse/LOG4J2-2157
> Project: Log4j 2
> Issue Type: Improvement
>Affects Versions: 2.10.0
>Reporter: Malte Skoruppa
> Labels: performance
>
> We recently added a
>
> {{return traceExit(retvalue);}}
> to a given method in our project, where before we simply had
> {{return retvalue;}}
> We then noticed that the running time of our software skyrocketed because of
> this change (the given method that this traceExit call was added to is called
> _very_ often). On a particular test case, the execution time grew from 3
> minutes to 15 minutes.
> The surprising thing: *This happened even when logging at TRACE level was
> disabled.*
> After profiling, we found out that traceExit(R) _always_ internally generates
> a message, even when logging at TRACE level is disabled. This can become
> extremely costly when traceExit(R) is called very often, and it doesn't make
> any sense because these messages are not logged anyway.
> +Technical explanation:+
> Essentially, in org.apache.logging.log4j.spi.AbstractLogger, the method
> traceExit(final R result) calls the method exit(final String fqcn, final
> String format, final R result), which in turn makes the call
> logIfEnabled(fqcn, Level.TRACE, EXIT_MARKER, exitMsg(format, result), null).
> This means that exitMsg(format, result) is always called, even when logging
> on TRACE level is disabled. Thus, a StringBuilder is invoked every time,
> which constructs a String and then throws it away because logging is disabled
> anyway.
> This implies that traceExit(R) can only be used for methods that are not
> called very often. For methods that are called often, calling traceExit(R)
> cannot be sensibly used because it utterly kills performance.
> Could you fix this? It seems unnecessary to call exitMsg(final String format,
> final Object result) when logging is disabled anyway.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (LOG4J2-2163) Objects held in SortedArrayStringMap cannot be filtered during serialization
Ralph Goers created LOG4J2-2163: --- Summary: Objects held in SortedArrayStringMap cannot be filtered during serialization Key: LOG4J2-2163 URL: https://issues.apache.org/jira/browse/LOG4J2-2163 Project: Log4j 2 Issue Type: Bug Components: API Affects Versions: 2.10.0 Reporter: Ralph Goers Assignee: Ralph Goers Fix For: 2.10.1 Objects within SortedArrayStringMap are serialized to byte arrays and deserialized to objects using a separate ObjectInputStream. This prevents users from being able to filter the classes being deserialized. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2164) setting property: log4j.skipJansi=false does not enable Jansi console under win 7 x86
[
https://issues.apache.org/jira/browse/LOG4J2-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16305534#comment-16305534
]
Ralph Goers commented on LOG4J2-2164:
-
Please try log4j2.skipJansi=false.
> setting property: log4j.skipJansi=false does not enable Jansi console under
> win 7 x86
> -
>
> Key: LOG4J2-2164
> URL: https://issues.apache.org/jira/browse/LOG4J2-2164
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
>Affects Versions: 2.10.0
> Environment: * setting property: log4j.skipJansi=false does not
> enable Jansi under * win 7 x86
> * with System.setProperty("log4j.skipJansi", "false");
> with
> * jansi-1.15.jar
> * win 7 x86 Pro
> * Microsoft Visual C++ 2008 SP1 Redistributable v9.0.30729
> * Microsoft Visual C++ 2013 SP1 Redistributable v12.0.40649.5
> * Microsoft Visual C++ 2017 SP1 Redistributable v14.11.25325.0
> * jre1.8.0_144
> with ver 2.10.0
> * log4j-core-2.10.0.jar|
> * log4j-api-2.10.0.jar | does NOT enable Jansi
> vs with ver 2.3 or ver 2.9.1
> * log4j-core-2.3.jar|
> * log4j-api-2.3.jar | OK: does enable Jansi
>Reporter: Yuriy Sosov
> Labels: features, jansi
> Fix For: 2.3, 2.9.1
>
> Attachments: AnsiConsoleExample2.java, jansi.ans, log4j2.xml,
> testJansi_sample-171210. java,
> test_compiledWith_log4jver2.3__runWith_log4jver2.10.0.png,
> test_log4jver2.10.0.png, test_log4jver2.3.png
>
>
> setting property: log4j.skipJansi=false
> as below
> System.setProperty("log4j.skipJansi", "false"); // LOG4J2-2087: explicitly
> enable
> does not enable Jansi with log4j2 ver 10.0 under win 7 x86
> Jansi works ok under log4j2 ver 2.3 and ver 2.9.1
> please see the files attached for test code:
> note: all the test screens attached are the same for ver 2.3 and 2.9.1
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2167) Memory leak in Apache Tomcat/8.5.24
[
https://issues.apache.org/jira/browse/LOG4J2-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306669#comment-16306669
]
Ralph Goers commented on LOG4J2-2167:
-
You don't how log4j-web as a dependency. Are you manually shutting down Log4j
yourself?
> Memory leak in Apache Tomcat/8.5.24
> ---
>
> Key: LOG4J2-2167
> URL: https://issues.apache.org/jira/browse/LOG4J2-2167
> Project: Log4j 2
> Issue Type: Bug
> Components: Web/Servlet
>Affects Versions: 2.10.0
> Environment: OS (on AWS): ubuntu-xenial-16.04-amd64-server-20171121.1
> (ami-fcc4db98)
> Server version:Apache Tomcat/8.5.24
> Server built: Nov 27 2017 13:05:30 UTC
> Server number: 8.5.24.0
> JVM Version: 1.8.0_151-b12
> JVM Vendor:Oracle Corporation
>Reporter: Christian Salway
>
> I'm introducing log4j2 as the logger into my application and when I do that,
> on a reload, undeploy or stop of the Application, a memory leak is left,
> which only happens once I introduce the logger into the code.
> {noformat}
> The following web applications were stopped (reloaded, undeployed), but their
> classes from previous runs are still loaded in memory, thus causing a memory
> leak (use a profiler to confirm):
> /myapp
> {noformat}
> My log4j2.xml:
> {code:xml}
>
>
>
>
>
>
> fileName="${env:CATALINA_BASE}/logs/app-${date:-mm-dd}.log">
>
>
>
>
>
>
>
>
>
>
> {code}
> My dependencies in pom.xml:
> {code:xml}
>
> org.apache.logging.log4j
> log4j-api
> 2.10.0
>
>
> org.apache.logging.log4j
> log4j-core
> 2.10.0
>
> {code}
> My WebServlet:
> {code:java}
> import org.apache.logging.log4j.Logger;
> import org.apache.logging.log4j.LogManager;
> import javax.servlet.ServletException;
> import javax.servlet.annotation.WebServlet;
> import javax.servlet.http.HttpServlet;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> import java.io.IOException;
> import java.io.PrintWriter;
> @WebServlet(name = "Servlet", urlPatterns = {"/servlet"}, loadOnStartup = 1)
> public class Servlet extends HttpServlet {
> private final Logger logger = LogManager.getLogger(Servlet.class);
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
> logger.info("doGet");
> PrintWriter out = response.getWriter();
> out.print("Servlet loaded");
> out.flush();
> out.close();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (LOG4J2-2163) Objects held in SortedArrayStringMap cannot be filtered during serialization
[ https://issues.apache.org/jira/browse/LOG4J2-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-2163. - Resolution: Fixed > Objects held in SortedArrayStringMap cannot be filtered during serialization > > > Key: LOG4J2-2163 > URL: https://issues.apache.org/jira/browse/LOG4J2-2163 > Project: Log4j 2 > Issue Type: Bug > Components: API >Affects Versions: 2.10.0 >Reporter: Ralph Goers >Assignee: Ralph Goers > Fix For: 2.10.1 > > > Objects within SortedArrayStringMap are serialized to byte arrays and > deserialized to objects using a separate ObjectInputStream. This prevents > users from being able to filter the classes being deserialized. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (LOG4J2-2163) Objects held in SortedArrayStringMap cannot be filtered during serialization
[ https://issues.apache.org/jira/browse/LOG4J2-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers closed LOG4J2-2163. --- > Objects held in SortedArrayStringMap cannot be filtered during serialization > > > Key: LOG4J2-2163 > URL: https://issues.apache.org/jira/browse/LOG4J2-2163 > Project: Log4j 2 > Issue Type: Bug > Components: API >Affects Versions: 2.10.0 >Reporter: Ralph Goers >Assignee: Ralph Goers > Fix For: 2.10.1 > > > Objects within SortedArrayStringMap are serialized to byte arrays and > deserialized to objects using a separate ObjectInputStream. This prevents > users from being able to filter the classes being deserialized. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (LOG4J2-2037) Include SLF4J in log4j-bom
[
https://issues.apache.org/jira/browse/LOG4J2-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16307079#comment-16307079
]
Ralph Goers commented on LOG4J2-2037:
-
I came up with the idea of "import scope" and implemented it in Maven, so I
have a pretty good understanding of how it is supposed to be used. The bill of
materials pom file exists so that you can easily include all of the
dependencies for a project and the versions without having to manually specify
them all in your project's pom. It would be inappropriate for log4j to dictate
the versions of other projects you should be using. If you want those projects
you should include the pom files they provide.
Case 2 is especially troubling. You say your project is compiling with SLF4J
and Log4j 2 is only needed at run time. Yet you want Log4j to bring in the
version of SLF4J? That really doesn't make a lot of sense.
I am closing this as I don't it is something we would want to do.
> Include SLF4J in log4j-bom
> --
>
> Key: LOG4J2-2037
> URL: https://issues.apache.org/jira/browse/LOG4J2-2037
> Project: Log4j 2
> Issue Type: Improvement
>Affects Versions: 2.9.0
> Environment: Maven
>Reporter: Arend v. Reinersdorff
>
> Currently log4j-bom only includes Log4j 2 dependencies. It would be nice
> log4j-bom would also include an slf4j-api dependency (and maybe other
> optional dependencies).
> Currently when using Log4j 2 as a backend for SLF4J the Maven dependency
> management would look like this:
> {code:xml}
>
>
>
> org.slf4j
> slf4j-api
> 1.7.25
>
>
> org.apache.logging.log4j
> log4j-bom
> 2.9.0
> pom
> import
>
>
>
> {code}
>
> If log4j-bom would specify a dependency for slf4j-api:
> * Dependency management entry for slf4j-api would no longer be needed
> * Keeping the dependency versions of Log4j 2 and SLF4J in sync would much
> easier. When the dependency version of log4j-bom is increased, it would
> automatically set the dependency version of slf4j-api.
> As an example see [spring-boot-dependencies |
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.springframework.boot%22%20AND%20a%3A%22spring-boot-dependencies%22]
> BOM which conveniently specifies many optional Spring Boot dependencies.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
