Re: `a.o.l.l.core.parser` package removal

Then users or 3rd parties can implement their own parsers if they need to. It might be useful to have parsers for some common formats like GELF, Logstash or RFC-5424, and that can be implemented without using Jackson if necessary. /Mikael On 2024-01-07 10:38, Mikael Ståldal wrote: What

Re: `a.o.l.l.core.parser` package removal

What about (re)moving the classes which actually depends on Jackson (AbstractJacksonLogEventParser, JsonLogEventParser, XmlLogEventParser, YamlLogEventParser), but keeping the interfaces (LogEventParser, TextLogEventParser, ParseException) in log4j-core? /Mikael On 2024-01-05 11:25, Volkan

Re: [log4j] Release 2.20.0 missing tests.jar

Thanks. Updated my blog post about it: https://www.staldal.nu/tech/2022/11/02/how-to-capture-log-events-in-tests-with-log4j-2/ /Mikael On 2023-03-01 21:06, Piotr P. Karwasz wrote: Hi Mikael, On Wed, 1 Mar 2023 at 20:41, Mikael Ståldal wrote: It seems like the 2.20.0 release is missing

[log4j] Release 2.20.0 missing tests.jar

It seems like the 2.20.0 release is missing the log4j-core-2.20.0-tests.jar, that used to be part of the releases. Is that intentional?

Re: [VOTE] Release Log4j 2.15.1-rc1

I agree too. I was just worried that we wouldn't remove Message Lookups until 3.x. Removing them in the next minor release (2.16.0) is reasonable. On 2021-12-13 10:12, Volkan Yazıcı wrote: I agree with both of your points Remko. On Mon, Dec 13, 2021 at 2:40 AM Remko Popma wrote: I am also

Re: Removing message lookups in master

I would say that log messages and log message parameter are as much (or as little) controlled by the application. I don't think it make sense to see them differently from a security perspective. Just as some code might do: logger.info("some message {}", userInput); Other code might do:

Re: Logging to Datadog

works, I will get in touch with the Datadog team too. On Sat, Nov 27, 2021 at 11:10 AM Mikael Ståldal wrote: The documentation for Datadog contains information on how to setup Log4j 2 to send logs to Datadog. However, for the agentless configuration, it says its not possible with Log4j 2 an

Logging to Datadog

The documentation for Datadog contains information on how to setup Log4j 2 to send logs to Datadog. However, for the agentless configuration, it says its not possible with Log4j 2 and resorts to bridging to Logback.

Success at Apache blog post about Log4j 2

https://blogs.apache.org/foundation/entry/success-at-apache-carrying-forward

Re: [log4j] log4j-core test speed breakdown

I the delay is there for the "testClose" test cast, but it slows down the other test methods as well, which is unintended. I have fixed it now by breaking out the "testClose" test case to its own class. On 2018-01-23 14:39, Gary Gregory wrote: It would be nice to heard from Mike his

Re: [log4j] Adding methods to org.apache.logging.log4j.core.appender.nosql.NoSqlObject

Is it really that useful to have "NoSQL" as an abstraction in the first place? Is there that much code to share? On 2018-01-22 21:43, Gary Gregory wrote: On Mon, Jan 22, 2018 at 12:30 PM, Matt Sicker wrote: Back when I wrote the initial CassandraAppender implementation, I

Re: [log4j] The shape of Log4j

., such as Kafka or JMS. These cause the core tests to take longer than necessary. 2. The size of the repo directly effects how long a build takes to run, as does the number of components in core. On Jan 24, 2018, at 2:24 PM, Mikael Ståldal <mi...@apache.org> wrote: Yes, and it's unfor

Re: [log4j] The shape of Log4j

Yes, and it's unfortunate that they get conflated. On 2018-01-21 16:55, Gary Gregory wrote: I can see two main orthogonal issues: - The size of the git repo. - The size of the log4j-core module.

Re: [log4j] The shape of Log4j

Yes, neither Git nor Maven is optimal for mono-repos since you can only tag/branch the whole repo, and only have one version for the whole build. Google have a big mono-repo, but they do not use Git, nor Maven. I think we should release and version everything in one repo together, otherwise

Re: [log4j] The shape of Log4j

On 2018-01-22 23:37, Matt Sicker wrote: On 22 January 2018 at 16:29, Ralph Goers wrote: If it was up to me I would move the following Appenders: Cassandra, Flume, JDBC, JMS, JPA, HTTP, Kafka, NoSQL, SMTP, ZeroMQ/JeroMQ, CouchDB, MongoDB. In addition to those I

Re: [log4j] The shape of Log4j

There is no NoSQL appender. There are Cassandra, CouchDB and MongoDB appenders. I don't think we should bundle them together. On 2018-01-22 23:29, Ralph Goers wrote: If it was up to me I would move the following Appenders: Cassandra, Flume, JDBC, JMS, JPA, HTTP, Kafka, NoSQL, SMTP,

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

maintains a list at https://maven.apache.org/plugins/ <https://maven.apache.org/plugins/>. I think the easiest way to manage a page like that would to have it be a separate page in the CMS that the log4j site links to. Ralph On Jan 20, 2018, at 8:29 AM, Mikael Ståldal <mi...@apache.org> wr

Re: Planning out what we can do to get Chainsaw back in the game

Nothing stops you from starting your own log viewer project based on whatever technology you want. If it turns out useful, we might even consider adopting it as an Apache Logging subproject. I think it's better if you and we try out what we believe in independently, and then we will see what

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

As I wrote recently, I don't think that having a kitchen-sink plugins repository is a good way to solve this. Eventually that repository will get too big. It's better to create a new repository for each new module (or possibly for a couple of related modules, but they should be more related

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

wrote: Because logging-log4j-plugins is released separately from logging-log4j2 and the versions would not line up. Ralph On Jan 16, 2018, at 2:31 PM, Mikael Ståldal <mi...@apache.org> wrote: Why do we need to change the version number? On 2018-01-14 22:11, Ralph Goers wrote: I don’t b

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

I originally developed log4j-liquibase. I have not used it or Liquibase itself for quite some time now. It might be so that the next version of Liquibase will make that module obsolete. But maybe we should keep it around at least until such new version of Liquibase is released? On

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

Why do we need to change the version number? On 2018-01-14 22:11, Ralph Goers wrote: I don’t believe the components listed in the subject line should be part of the main flume build and would like to see them moved to the logging-log4j-plugins project. The only problem is that the modules and

Re: [Log4j] Binary layout

returns a Message instance. You could return a ByteBuffer, but generally for an efficient binary layout I would look at the encode method instead. On Tue, Jan 16, 2018 at 11:45 PM, Mikael Ståldal <mi...@apache.org> wrote: How is a binary layout (extending AbstractLayou

[Log4j] Binary layout

How is a binary layout (extending AbstractLayout) supposed to implement the toSerializable method in the Layout interface? Why is that method there?

[Log4j] Release plan?

Will the next release be 2.10.1 or 2.11.0? If 2.10.1, I start seeing a few new features in master branch that might not be appropriate for a patch release.

Re: [log4j] Move JDBC appender to own module?

As usual, I think we should avoid optional dependencies. On 2018-01-13 10:16, Remko Popma wrote: I meant to keep the jdbc and the generic db package together. log4j-db: generic db + jdbc log4j-jpa: requires javax.persistance We can also keep all of these in a single module `log4j-db` with

[Log4j] Messages and garbage free logging

In http://logging.apache.org/log4j/2.x/manual/messages.html we say: "Although it may seem more expensive than passing the message format and parameters directly to the event, testing has shown that with modern JVMs the cost of creating and destroying events is minor, especially when complex

Re: Event batch

And the same applies to AsyncAppender, right? On 2018-01-10 00:14, Remko Popma wrote: Log4j2 internally uses this with async logging: with async logging, the “producer” is the async logging queue. The queue “knows“ whether it’s empty or whether more events will follow immediately and it will

Re: Event batch

I guess that you are supposed to use LogEvent.isEndOfBatch() to know when to flush log events to final destination. Our file and stream based appenders do that. See

Re: [log4j] and Apache HttpClient

I think that we should at least make a release with fix for https://issues.apache.org/jira/browse/LOG4J2-2126 before we try to convince anyone to use Log4j for something which might be used on Android. On 2018-01-08 16:37, Gary Gregory wrote: Hi All: Over on the d...@hc.apache.org list, we

Re: [jira] [Commented] (LOG4J2-2162) KafkaAppender fails application startup when bootstrap server are not available

Do we have a generic way of doing this, so you don't have to implement the same for every appender? On 2018-01-03 18:58, Gary Gregory (JIRA) wrote: Gary Gregory commented on LOG4J2-2162: -- We need the same kind of reconnect logic the JMS Appender uses

Re: [log4j] providing sourcewith Message

StackTraceElement to loggers. I'd like a code review. I'm happy to try other methods. See the following commit. https://github.com/shawjef3/logging-log4j2/commit/ 9c42073e9ca4f25a2f4075b1791eee2893534c54 On Sat, Dec 9, 2017 at 10:09 AM, Mikael Ståldal < mi...@apache.org> wrot

Re: [log4j] release 2.10.1

Yes, it does. On 2017-12-23 17:39, Ralph Goers wrote: I am using the same version of Maven and Java. Does your reactor order match mine?

Re: [log4j] release 2.10.1

I just tried with latest master. No errors in log4j-api, but in log4j-osgi: $ mvn -v Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) Maven home: /opt/apache-maven-3.3.9 Java version: 1.8.0_144, vendor: Oracle Corporation Java home:

[Log4j] Incorrect information about markers in SLF4J documentation

I just realized that the documentation for SLF4J contain incorrect information about markers: https://www.slf4j.org/faq.html#marker_interface https://www.slf4j.org/faq.html#fatal It says that only Logback support markers, while in fact Log4j 2 also supports it. Maybe we should report a bug?

Re: [Log4j] Next release?

Not at the moment. On 2017-12-11 20:02, Ralph Goers wrote: It will be 2.10.1 unless we have new features to add that warrant a minor version bump. Do you have new features to add? Ralph On Dec 11, 2017, at 11:54 AM, Mikael Ståldal <mi...@apache.org> wrote: Do we plan to do a

[Log4j] Next release?

Do we plan to do a 2.10.1, or will next release be 2.11.0?

Re: [log4j] providing sourcewith Message

Have you tried the Log4j Scala API? http://logging.apache.org/log4j/2.x/manual/scala-api.html It does currently not support this, but it uses Scala macros, and this could be added there. But log4j-api and/or log4j-core probably needs to adapted as well. On 2017-12-09 07:30, Jeffrey Shaw

Re: [jira] [Resolved] (LOG4J2-2146) The maven bundle plugin fails due to Java 9

This used to be very annoying, and now it works fine. Thanks Ralph! On 2017-12-07 07:41, Ralph Goers (JIRA) wrote: [ https://issues.apache.org/jira/browse/LOG4J2-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers resolved LOG4J2-2146.

Re: [Log4j] Header/footer and thread context

have to use ThreadContext, or async appender/logger to get this confusing behaviour.) On 2017-12-03 12:54, Mikael Ståldal wrote: It does work for the subject and body, see the new unit test SmtpAppenderAsyncTest i just pushed to Git master. And I think this behaviour make sense and should

Re: [Log4j] Header/footer and thread context

<boa...@gmail.com> wrote: I'm not sure if this use case makes much sense. Dynamic data like that makes more sense in the message itself, though I'm sure there are several ways to do this. On 30 November 2017 at 15:02, Mikael Ståldal <mi...@apache.org> wrote: I am look

Re: SLF4J now requires Java 6

On 2017-12-03 00:24, Matt Sicker wrote: It's too bad that Java 8 and 9 added language features that would have been immensely useful for maintaining a backwards compatible API (default and private methods on interfaces), Did Java 9 add anything more than Java 8 for this?

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

OK. I was not aware of this. I thought that it was the Java 9 implementation (StackLocator/ProcessIdUtil) that caused the problem. On 2017-12-03 06:30, Ralph Goers wrote: Let’s go back to this post. Assume we figured out how to get rid of all the stuff you consider to be not required to be

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

Yes, log4j-core-android would be a good idea. But yes, we have to solve the API problem first. On 2017-12-02 17:40, Ralph Goers wrote: FWIW, it would make sense to me to make a log4j-core-android that is a subset of what is in core, if that is possible. Of course, the API problem has to be

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

The problem is that we cannot just remove stuff from log4j-api now, since that would break binary/source compatibility for existing users. If I understand it correctly, due to the Java 9 modules, if we move stuff from log4j-api to log4j-core we have to change package, right? And we don't want

[Log4j] Header/footer and thread context

I am looking at https://issues.apache.org/jira/browse/LOG4J2-2007 What is the expected behavior here? Should there be any thread context for header/footer? I guess it should be consistent for sync and async logging, which it isn't right now. But maybe the async case is correct in not

[Log4j] Closing resolved JIRA issues

How should we handle closing of resolved JIRA issues? Idealy, the original reporter should close after verifying, but quite often they never do. I usually close the resolved issues I am assigned to shortly after it is released. I just did with a bunch of issues released with 2.10.0.

Re: [Log4j] Wrong version of Scala API in documentation

modify. Ralph On Nov 25, 2017, at 7:52 AM, Mikael Ståldal <mi...@apache.org> wrote: This page: https://logging.apache.org/log4j/2.x/maven-artifacts.html instructs users to use version 2.10.0 of the Scala API, which is wrong, it doesn't exist. It should be 11.0. I have fixed it in Git master.

Re: [Log4j] ProcessIdUtil

Java 9 modules. Ralph On Nov 25, 2017, at 7:54 AM, Mikael Ståldal <mi...@apache.org> wrote: Regarding https://issues.apache.org/jira/browse/LOG4J2-2126 Why is ProcessIdUtil in log4j-api in the first place? It is only used from log4j-core. Can't we move it to log4j-core? I think that in g

Re: Build failed in Jenkins: Log4j 2.x #3197

What does this mean? Is this a problem in our build, or a temporary infrastructure problem? On 2017-11-25 16:01, Apache Jenkins Server wrote: ERROR: Failed to deploy metadata: Could not transfer metadata org.apache.logging.log4j:log4j-osgi:2.10.1-SNAPSHOT/maven-metadata.xml from/to

[Log4j] ProcessIdUtil

Regarding https://issues.apache.org/jira/browse/LOG4J2-2126 Why is ProcessIdUtil in log4j-api in the first place? It is only used from log4j-core. Can't we move it to log4j-core? I think that in general, we have too much things in log4j-api, and that causes problems like this.

[Log4j] Wrong version of Scala API in documentation

This page: https://logging.apache.org/log4j/2.x/maven-artifacts.html instructs users to use version 2.10.0 of the Scala API, which is wrong, it doesn't exist. It should be 11.0. I have fixed it in Git master.

Re: [Chainsaw] Next step: Log4j 2

On 2017-11-21 17:06, Matt Sicker wrote: This could present an opportunity to standardize some of the log4j-core APIs that other applications may need as well. Sounds like a good idea.

Re: [Chainsaw] Next step: Log4j 2

Could you go through the Chainsaw codebase and remove all unused/ obsolete stuff in there? Preferrably also stuff that will be obsolete when we have migrated to away from Log4j 1. In a separate branch for now. On 2017-11-20 23:17, Scott Deboy wrote: Awesome! Re: appenders: We went

Re: [Chainsaw] Next step: Log4j 2

from log4j-core. But maybe we should try to avoid using the configuration framework in log4j-core (the fact that it now uses the configuration framework in Log4j 1 makes it considerably harder to migrate away from it). On 2017-11-20 21:41, Mikael Ståldal wrote: I took a look at the Chainsaw

Re: [Chainsaw] Next step: Log4j 2

ctiveLevel())) { // call the loggers appenders to process the event localLogger.callAppenders(event); } } Scott On 11/20/17, Mikael Ståldal <mi...@apache.org> wrote: I took a look at the Chainsaw source code, and tried to remove its dependency on Log

Re: [Chainsaw] Next step: Log4j 2

We should complete the release of the current code before merging any of this stuff, but we can start this work in a branch while waiting for the release. On 2017-11-20 21:41, Mikael Ståldal wrote: I took a look at the Chainsaw source code, and tried to remove its dependency on Log4j 1

Re: [VOTE] Release Log4j 2.10.0-rc1

it :-( Gayr On Mon, Nov 20, 2017 at 2:28 PM, Mikael Ståldal <mi...@apache.org> wrote: I agree with Ralph. On 2017-11-20 20:03, Ralph Goers wrote: Unless you find something else I am not inclined to rerun the release just to fix a unit test where we know what the problem is and th

Re: [VOTE] Release Log4j 2.10.0-rc1

I agree with Ralph. On 2017-11-20 20:03, Ralph Goers wrote: Unless you find something else I am not inclined to rerun the release just to fix a unit test where we know what the problem is and that has no impact on the code customers use. Ralph On Nov 20, 2017, at 11:56 AM, Gary Gregory

Re: [VOTE] Release Log4j 2.10.0-rc1

Is that the complete error message? On 2017-11-20 17:41, Gary Gregory wrote: Now I get a different failure. I had run the build in Windows but from the git command line (MINGW64). That that I run from a "real" Windows command line I get: [ERROR] Errors: [ERROR]

Re: [VOTE] Release Log4j 2.10.0-rc1

+1 * Maven artifacts works in my test project. * Build of tags/log4j-2.10-rc1 works. On 2017-11-19 19:11, Ralph Goers wrote: This is a vote to release Log4j 2.10.0, the next version of the Log4j 2 project. Please download, test, and cast your votes on the log4j developers list. [] +1,

Re: Failing unit test

I made an attempt to make that test more reliable. On 2017-11-19 00:57, Ralph Goers wrote: I am preparing to do the release build and am getting the following error: Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.25 s <<< FAILURE! - in

Re: logging-log4j2 git commit: Always delete temporary file created in test

http://picocli.info On Nov 19, 2017, at 20:46, Mikael Ståldal <mi...@apache.org> wrote: Does it help if you add: appender.stop(10, TimeUnit.SECONDS); after line 171 in Log4j1ConfigurationFactoryTest.java (last in the try block)? On 2017-11-19 05:41, Remko Popma wrote: The build now

Re: logging-log4j2 git commit: Always delete temporary file created in test

Does it help if you add: appender.stop(10, TimeUnit.SECONDS); after line 171 in Log4j1ConfigurationFactoryTest.java (last in the try block)? On 2017-11-19 05:41, Remko Popma wrote: The build now fails on windows. I always see this error: expected:

Re: Jenkins build is still unstable: Log4j 2.x #3170

Makes sense, fixed. On 2017-11-18 21:17, Ralph Goers wrote: The file should be deleted before the test starts and after it finishes. If it fails for some reason it will still leave the file lying around so deleting it before the test insures a clean environment.

[Log4j] StructuredDataMessage and XML format

Can someone review my recent fix to https://issues.apache.org/jira/browse/LOG4J2-2108 ? I am not sure how it is actually supposed to work.

[Log4j]

Any thoughts about https://issues.apache.org/jira/browse/LOG4J2-2110 and https://github.com/apache/logging-log4j2/pull/128 ? I have not worked with Servlet stuff for quite long time.

Re: Jenkins build is still unstable: Log4j 2.x #3170

It works now! On 2017-11-18 13:00, Mikael Ståldal wrote: That particular test creates hadoop.log in System.getProperty("java.io.tmpdir") on purpuse to test system property replacement in configuration files. On most Linux systems (including our Jenkins machine), System.g

Re: Jenkins build is still unstable: Log4j 2.x #3170

That particular test creates hadoop.log in System.getProperty("java.io.tmpdir") on purpuse to test system property replacement in configuration files. On most Linux systems (including our Jenkins machine), System.getProperty("java.io.tmpdir") == "/tmp". I tried the test locally on my Linux

Re: Jenkins build is still unstable: Log4j 2.x #3170

Same problem again in latest build (#3182). On 2017-11-12 23:58, Ralph Goers wrote: I am not sure why this is suddenly failing with a permission denied trying to create /tmp/hadoop.log. But why is it trying to create a file there instead of under the target directory? Ralph On Nov 12,

Re: Log4j 2.10

OK for me. Thanks for the RM work. On 2017-11-16 05:31, Ralph Goers wrote: Unless someone objects I plan to start the release process for Log4j 2.10 tomorrow. I had wanted to include a fix for LOG4J2-2106 but the problem only occurs in rare situations and I am not sure how to fix it yet.

Re: Log4j 2.10

OK for me. Thanks for the RM work. On 2017-11-16 05:31, Ralph Goers wrote: Unless someone objects I plan to start the release process for Log4j 2.10 tomorrow. I had wanted to include a fix for LOG4J2-2106 but the problem only occurs in rare situations and I am not sure how to fix it yet.

Re: logging-log4j2 git commit: [LOG4J2-2114] Provide a native Log4j 2 implementation of Eclipse Jetty's org.eclipse.jetty.util.log.Logger.

Mikael Ståldal <mi...@apache.org> wrote: On 2017-11-12 16:00, Gary Gregory wrote: On Sun, Nov 12, 2017 at 7:25 AM, Mikael Ståldal <mi...@apache.org> wrote: Do we want a package-info.java in the Jetty package, like in the Tomcat package? And you should probably add a section abou

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

When starting Chainsaw, I see this warning in the log: menu 'Connect to' was NOT added because the 'Help' menu could not be located There is a "Connect to" menu though, and the "Learn more about ZeroConf" works. On 2017-11-10 20:00, Matt Sicker wrote: This is a vote to release Apache

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

the JMSReceiver. On 11/12/17, Mikael Ståldal <mi...@apache.org> wrote: When running Chainsaw, I see this error message: Failed to locate Receiver class:org.apache.log4j.net.JMSReceiver, looks like a dependent class is missing from the classpath java.lang.NoClassDefFoundError: javax/jms/MessageLi

Re: Planning out what we can do to get Chainsaw back in the game

t also helps with adoption in theory. On 11 November 2017 at 10:23, Mikael Ståldal <mi...@apache.org> wrote: I have used both Java and Scala for several years, and I have been trying out Kotlin the latest months (for Android only). I would say it is definitely easier for a developer with pri

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

In release notes in the app, it says version 2.1. On 2017-11-10 20:00, Matt Sicker wrote: This is a vote to release Apache Chainsaw 2.0.0-rc1. (Note: I've created release instructions on the new wiki: < https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>) Artifacts:

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

When starting Chainsaw, I see this warning: Could not find any local JavaDocs, you might want to consider running 'ant javadoc'. The release version will be able to access Javadocs from the Apache website. And accessing Javadocs from the Help menu does not work. On 2017-11-10 20:00, Matt

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

In the About text, it says: Please send questions, bug reports and/or feature requests to log4j-...@logging.apache.org which is obsolete. On 2017-11-10 20:00, Matt Sicker wrote: This is a vote to release Apache Chainsaw 2.0.0-rc1. (Note: I've created release instructions on the new wiki: <

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

When running Chainsaw, I see this error message: Failed to locate Receiver class:org.apache.log4j.net.JMSReceiver, looks like a dependent class is missing from the classpath java.lang.NoClassDefFoundError: javax/jms/MessageListener It seems to work anyway (without JMX support I suppose)

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

The apache-chainsaw-2.0.0-standalone.tar.gz artifact has wrong permissions set on the bin directory: $ tar -tvzf apache-chainsaw-2.0.0-standalone.tar.gz d- 0/0 0 2017-11-10 19:24 apache-chainsaw/2.0.0/bin/ after extracting: $ cd apache-chainsaw-2.0.0/ $ ls bin repo $ cd bin/

Re: logging-log4j2 git commit: [LOG4J2-2114] Provide a native Log4j 2 implementation of Eclipse Jetty's org.eclipse.jetty.util.log.Logger.

On 2017-11-12 16:00, Gary Gregory wrote: On Sun, Nov 12, 2017 at 7:25 AM, Mikael Ståldal <mi...@apache.org> wrote: Do we want a package-info.java in the Jetty package, like in the Tomcat package? And you should probably add a section about Jetty integraion in log4j-appserver/src/site/ma

Re: Planning out what we can do to get Chainsaw back in the game

Having said that, I don't mean that Ole Ersoy's idea is inherently bad. But it should be a new independent project (possibly in Apache Logging Services). On 2017-11-12 14:27, Mikael Ståldal wrote: To me, that sound like transforming it into something completely different, and a use case

Re: logging-log4j2 git commit: [LOG4J2-2114] Provide a native Log4j 2 implementation of Eclipse Jetty's org.eclipse.jetty.util.log.Logger.

Do we want a package-info.java in the Jetty package, like in the Tomcat package? And you should probably add a section about Jetty integraion in log4j-appserver/src/site/markdown/index.md.vm On 2017-11-11 23:43, Gary Gregory wrote: Please code review git master. I'm not sure I have the class

Re: Planning out what we can do to get Chainsaw back in the game

ick up on than Scala, so that also helps with adoption in theory. On 11 November 2017 at 10:23, Mikael Ståldal <mi...@apache.org> wrote: I have used both Java and Scala for several years, and I have been trying out Kotlin the latest months (for Android only). I would say it is defin

Re: Planning out what we can do to get Chainsaw back in the game

On 2017-11-12 00:57, Ole Ersoy wrote: > A chainsaw implementation in Electron would provide a better developer > and user experience I would think though But that would require a complete rewrite of the app, with no opportunity to reuse any of the existing Java code. Both Scala and Kotlin

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

Yes, that worked. On 2017-11-11 22:22, Scott Deboy wrote: I had ran mvn clean site:site install and it worked. On 11/11/17, Mikael Ståldal <mi...@apache.org> wrote: On 2017-11-10 20:00, Matt Sicker wrote: Artifacts: https://dist.apache.org/repos/dist/dev/logging/chainsaw/ svn re

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

On 2017-11-10 20:00, Matt Sicker wrote: Artifacts: https://dist.apache.org/repos/dist/dev/logging/chainsaw/ svn revision 23048 When I look at that URL, it says: Revision 23059

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

ix" On 2017-11-11 21:40, Mikael Ståldal wrote: $ git checkout chainsaw-2.0.0-rc1 $ mvn clean install [...] [INFO] --- maven-assembly-plugin:2.4:single (make-assembly) @ apache-chainsaw --- Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

$ git checkout chainsaw-2.0.0-rc1 $ mvn clean install [...] [INFO] --- maven-assembly-plugin:2.4:single (make-assembly) @ apache-chainsaw --- Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar Downloaded:

Re: Planning out what we can do to get Chainsaw back in the game

I have used both Java and Scala for several years, and I have been trying out Kotlin the latest months (for Android only). I would say it is definitely easier for a developer with primarily Java experience to pick up Kotlin than Scala, especially if that Java experience is predominately

Re: [PROPOSAL] New module log4j-jetty

On 2017-11-09 20:09, Matt Sicker wrote: On 9 November 2017 at 11:34, Gary Gregory wrote: I do not want to drag Tomcat down into my local repo or on my class path in my IDE just because I am depending on log4j-appserver's one class for Jetty logging. There are

[Log4j] Clean-up of GitHub PR:s

I am trying to do some clean-up among GitHub PR:s. * What is the status of this? https://github.com/apache/logging-log4j2/pull/107 * Is this still relevant, or can it be closed? https://github.com/apache/logging-log4j2/pull/111 * This one hasn't been touch for over a year:

Re: [Log4j] Wrong mailing list

OK, and I see that it is correct now, but was updated after the last release. Should fix itself when we do the next release then. On 2017-11-05 17:13, Matt Sicker wrote: On Sun, Nov 5, 2017 at 08:48, Mikael Ståldal <mi...@apache.org> wrote: I think this page is out of date:

[Log4j] PatternLayout %enc{HTML}

Why does it need to escape slash '/'?

[Log4j] Wrong mailing list

I think this page is out of date: https://logging.apache.org/log4j/2.x/mail-lists.html It still refer to the log4j-...@logging.apache.org mailing list. I am not sure how to change that page, it seems to not be part of the Maven site build of the project.

Re: [meta] Draft blog post about logging in general

Nice! Maybe Logstash and Graylog should be refered to as "products" rather than "projects". And since Logstash doesn't really provide the desired functionallity by itself, maybe refer to the "ELK stack" instead. On 2017-10-30 19:09, Matt Sicker wrote: In preparation for an upcoming talk

Re: [Log4j] Next release?

on Stephen Colbourne’s recommendations. Ralph On Oct 12, 2017, at 12:36 PM, Mikael Ståldal <mi...@apache.org> wrote: Is there any ongoing work that we want to wait for? I would like to do these: - https://issues.apache.org/jira/browse/LOG4J2-2062 (waiting for contributor to update

Re: Test failures in log4j-taglib

On Thu, Oct 19, 2017 at 2:14 PM, Ralph Goers <ralph.go...@dslextreme.com <mailto:ralph.go...@dslextreme.com>> wrote: I am wondering why this is suddenly failing. Was it changed recently? Ralph On Oct 19, 2017, at 1:00 PM, Mikael Ståldal <mi...@apache.org> w

Re: Test failures in log4j-taglib

wondering why this is suddenly failing. Was it changed recently? Ralph On Oct 19, 2017, at 1:00 PM, Mikael Ståldal <mi...@apache.org> wrote: The missing class, javax.servlet.SessionCookieConfig is new in Servlet API 3.x. In log4j-taglib pom, we have this dependency: javax.s

  1   2   3   4   5   6   7   >