Yes, but should be fixed nonetheless.
Yes, The fact that you can’t find the File appender or Logger elements
indicates that plugin processing is not working. I have no idea why that would
be since they are all part of log4j-core.
Ralph
> On Nov 7, 2020, at 7:13 PM, Gary Gregory wrote:
>
>
Probably harmless:
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for org.apache.logging.log4j:log4j-core:jar:2.14.0
[WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique:
I am building from the RC tag and I tried 'mvn clean install' again and I
wonder if there is something wrong with my set up somehow, note this log
output before the failure:
2020-11-07 19:47:14,085 main ERROR Null object returned for File in
Appenders.
2020-11-07 19:47:14,086 main ERROR Unable to
The main hurdle for my day job is that Java 11 is not supported on all
hardware platforms yet, specifically, some of our customers run our apps on
IBM i/Series. That should not stop Log4j 3 to require Java 11 of course.
It's just one data point. To make the migration even slower, even when Java
11
One of the goals for 3.0 is to have it fully support the Java Platform Module
System. Currently, we are required to have a java 8 project and a java 9
project and merge them. If we say that 3.0 will only support Java 11+ then we
can get rid of these extra projects and add module-info.java to
It looks like it will do that - there is an xmllayout that I haven't
paid too much attention to in the past.
Part of this is that I really need to update some of the documentation
for log4cxx to show the possible options for how to do things. The
chainsaw documentation could also be updated as
If I recall correctly, log4cxx supports the log4j xml format over tcp.
Scott
On Sat, Nov 7, 2020, 11:49 AM Matt Sicker wrote:
> It would limit the supported classes to a safe allowlist. Ideally, we
> should be using both standardized logging formats (including de facto
> standards like GELF)
Looks like changing the default retry timeout to be at least 1 second
on Windows is useful due to some timing granularity issue there.
On Fri, 6 Nov 2020 at 02:11, Volkan Yazıcı wrote:
>
> Last month I spent quite some time fixing failing tests on release-2.x. I
> succeeded in fixing some
+1
Tested using
mvn -version
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T12:00:29-07:00)
Maven home: /opt/maven/maven
Java version: 1.8.0_265, vendor: Amazon.com Inc., runtime:
/Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home/jre
Default
It would limit the supported classes to a safe allowlist. Ideally, we
should be using both standardized logging formats (including de facto
standards like GELF) as well as developing a proper binary logging
format proposed a few years ago.
On Sat, 7 Nov 2020 at 13:45, Robert Middleton wrote:
>
>
Chainsaw supports log4j1 xml format via tcp or local file, and supports
parsing of arbitrary plain text formats via LogFilePatternReceiver (tailing
of log files, including via ssh).
Scott
On Sat, Nov 7, 2020, 11:45 AM Robert Middleton wrote:
> Would this be a total removal of the Java
Would this be a total removal of the Java deserialization? I ask
because I think I've used that before with log4cxx to send log
messages to chainsaw.
Alternatively, I guess the better question is "should chainsaw support
structured log messages input?" I know that there was something about
Please fork non-vote stuff to a different thread.
I have tested with Oracle JDK 8 144 & 202, Corretto 8.272 and AdoptOpenJDK
8.272 on two different MacBook Pros both running macOS Catalina 10.15.7. I
don’t get any failing tests on any of them although on one machine I do get
sporadic test
+1
Signatures and checksums good, builds and tests fine, site looks good.
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
Java version: 1.8.0_242, vendor: AdoptOpenJDK, runtime:
Great, thanks! I've been trying to consolidate our parent poms into
the logging-parent pom to ease the configuration maintenance.
On Sat, 7 Nov 2020 at 11:07, Scott Deboy wrote:
>
> Updated to version 3 of the parent pom and clean site:site package
> runs fine, pushed to master.
>
> On 11/7/20,
Any use of deserialization over the network (or from untrusted input
sources in general) should use an allowlist of deserializable classes.
That's what we did in log4j2's serialized log event receiver code a
few years ago, for example:
https://github.com/apache/logging-log4j2/commit/5dcc192
I assume reverse-connect is still fine (SocketHubAppender/Receiver),
as Chainsaw is being configured to reach a specific (assumed trusted)
endpoint, yes?
On 11/6/20, Scott Deboy wrote:
> Holy cow. February?
>
> I have zero problem with us nuking the object serialization receiver
> support. I
Updated to version 3 of the parent pom and clean site:site package
runs fine, pushed to master.
On 11/7/20, Matt Sicker wrote:
> Looks like we need to either fix this pom or the parent pom.
>
> On Fri, Nov 6, 2020 at 21:34 Mr. Jenkins
> wrote:
>
>> *BUILD FAILURE*
>> Build URL
>>
Looks like removal of the parent pom is now causing CI failures. We need
either the ASF parent pom or our logging one.
On Fri, Nov 6, 2020 at 21:32 wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> sdeboy pushed a commit to branch master
> in repository
Looks like we need to either fix this pom or the parent pom.
On Fri, Nov 6, 2020 at 21:34 Mr. Jenkins
wrote:
> *BUILD FAILURE*
> Build URL
> https://ci-builds.apache.org/job/Logging/job/chainsaw/job/master/10/
> Project: master
> Date of build: Sat, 07 Nov 2020 03:32:20 +
> Build duration:
Would you all mind replying with what OS, Java versions, build commands, an
so on, you validated the release candidate?
I think it would be good to know FTR what kind of coverage we got for a RC.
Gary
On Fri, Nov 6, 2020, 19:51 Volkan Yazıcı wrote:
> +1
>
> Thanks so much to everyone who put
+1
Remko.
On Sat, Nov 7, 2020 at 8:46 AM Ralph Goers
wrote:
> This is a vote to release Log4j 2.14.0, the next version of the Log4j 2
> project.
>
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
>
> The
22 matches
Mail list logo
