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
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 Y
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
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?
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
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:
log
making sure it 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
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.
https://docs.datadoghq.com/logs/log_collection/java/?tab=log4j2#agentless-loggi
https://blogs.apache.org/foundation/entry/success-at-apache-carrying-forward
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 thought
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 found the
existing
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 wrote:
Yes, and it's unfortunate that they get conflated
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.
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 it
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 would move the taglib, imx-gui an
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, ZeroMQ/Jer
st
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 wrote:
As I wrote recently, I don't
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 w
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 th
7 00:34, Ralph Goers 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 wrote:
Why do we need to change the version number?
On 2018-01-14 22:11, Ralph Goers wrote:
I don’t be
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 2
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
efficient binary
layout
I would look at the encode method instead.
On Tue, Jan 16, 2018 at 11:45 PM, Mikael Ståldal
wrote:
How is a binary layout (extending AbstractLayout) supposed to implement
the toSerializable method in the Layout interface?
Why is that method there?
How is a binary layout (extending AbstractLayout) supposed to implement
the toSerializable method in the Layout interface?
Why is that method there?
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.
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 an
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 ta
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 s
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
https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/RandomAccessF
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 h
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 here
m
wrote:
Thanks for the link, Mikael. I'll take a look at it.
I added some plumbing to core to allow clients to
pass
a
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-log4j
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?
Did not help for me.
On 2017-12-23 06:46, Matt Sicker wrote:
That OSGi test failure looks like one that could maybe be solved by doing a
"mvn install -DskipTests" first as it's trying to find a snapshot jar.
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: /opt/jvm/jdk1.8.0_144
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?
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 wrote:
Do we plan to do a 2.10.1, or will next release
Do we plan to do a 2.10.1, or will next release be 2.11.0?
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 wro
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.
---
x27;t 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 shou
icker 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 wrote:
I am looking at https://issues.apache.org/jira/browse/LOG4J
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?
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 i
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
s
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 re
I fully understand Oleg's point of view.
If we aim for Log4j 2's API to be the standard logging API/facade for
Java/JVM (eventually replacing SLF4J), then we have painted ourselves
into a corner by allowing log4j-api to grow out of bounds, and not
paying enough attention to the compatibility p
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 includin
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.
modify.
Ralph
On Nov 25, 2017, at 7:52 AM, Mikael Ståldal 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.
Java 9 modules.
Ralph
On Nov 25, 2017, at 7:54 AM, Mikael Ståldal 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 general, we have too
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
apache.sn
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.
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.
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.
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 throug
Event
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 Cha
tEffectiveLevel())) {
// call the loggers appenders to process the event
localLogger.callAppenders(event);
}
}
Scott
On 11/20/17, Mikael Ståldal wrote:
I took a look at the Chainsaw source code, and tried to remove its
dependency on Log4j 1 and migrate to Log
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 and
I took a look at the Chainsaw source code, and tried to remove its
dependency on Log4j 1 and migrate to Log4j 2.
That was not easy, Chainsaw heavily depends on intricate Log4j 1
implementation details. There is a lot of tedious but straight-forward
search/replace kind of work to do. But quite
even build
it :-(
Gayr
On Mon, Nov 20, 2017 at 2:28 PM, Mikael Ståldal 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 that has no
impact o
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 wro
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] Log4j1ConfigurationFactoryTest
+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, release
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 org.apache.logging.log4j.core.appender.
d deserves http://picocli.info
On Nov 19, 2017, at 20:46, Mikael Ståldal 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 fails on
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: C:\Users\remko\AppData\Local\Temp\/had
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.
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.
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.
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
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 m
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, 2017
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. Ther
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. There
8:04 AM, Gary Gregory
wrote:
Oh, I added a section to the main index:
#h3 Integrating with Application Servers
Version 2.10.0 introduces a the module log4j-appserver to improve
integration with Apache Tomcat and Eclipse Jetty.
Gary
On Sun, Nov 12, 2017 at 10:10 AM, Mikael Ståldal wrote:
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 Chains
to use the JMSReceiver.
On 11/12/17, Mikael Ståldal 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/MessageListener
It see
per to
pick
up on than Scala, so that also helps with adoption in theory.
On 11 November 2017 at 10:23, Mikael Ståldal 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 develo
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:
ht
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 S
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: <
h
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) though
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/
bash:
On 2017-11-12 16:00, Gary Gregory wrote:
On Sun, Nov 12, 2017 at 7:25 AM, Mikael Ståldal 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/markdown/index.md.vm
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
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
ier for a C# or JavaScript developer to
pick
up on than Scala, so that also helps with adoption in theory.
On 11 November 2017 at 10:23, Mikael Ståldal 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
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 have
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 wrote:
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
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
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/
$ 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:
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 pre-Ja
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 certain dependencies in use alr
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:
https://github.c
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 wrote:
I think this page is out of date:
https://logging.apache.org/log4j/2
Why does it need to escape slash '/'?
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.
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 I
1 - 100 of 341 matches
Mail list logo
