> > If your project is set up for it, you can reply to this email and have
> your
> > reply appear on GitHub as well. If your project does not have this
> feature
> > enabled and wishes so, or if the feature is enabled but not working,
> please
> > contact infrastructure at infrastruct...@apache.org or file a JIRA
> ticket
> > with INFRA.
> > ---
> >
>
--
Matt Sicker
test.LogEventFactory");
> > > > -logger.error("error message");
> > > > +logger.error("Error message");
> > > > --- End diff --
> > > >
> > > > Why does this message need to be changed?
> > > >
> > > >
> > > > ---
> > > > If your project is set up for it, you can reply to this email and
> have
> > > your
> > > > reply appear on GitHub as well. If your project does not have this
> > > feature
> > > > enabled and wishes so, or if the feature is enabled but not working,
> > > please
> > > > contact infrastructure at infrastruct...@apache.org or file a JIRA
> > > ticket
> > > > with INFRA.
> > > > ---
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker
> >
>
--
Matt Sicker
> >>>> Ralph
> >>>>
> >>>>> On Aug 12, 2017, at 11:29 AM, Gary Gregory
> >>>> wrote:
> >>>>>
> >>>>> Hi All,
> >>>>>
> >>>>> I you use nested classes to build loggers, you end up with logger
> >> names
> >>>>> like A$N1, A$N2 and so on.
> >>>>>
> >>>>> If you then set a logger level in a config using "A", it does not
> >>> affect
> >>>>> A$N1 and A$N2 as you might expect, since "$" is not a ".".
> >>>>>
> >>>>> What about treating "$" like a "."?
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> Gary
> >>>>
> >>>>
> >>>>
> >>>
> >>
>
>
>
--
Matt Sicker
web site? I can’t find it in SVN.
>
> Ralph
>
--
Matt Sicker
site checked in I can figure out how to do link
> them.
>
> Ralph
>
> > On Aug 14, 2017, at 7:00 AM, Matt Sicker wrote:
> >
> > The Scala site hasn't been committed to SVN as I wasn't exactly sure how
> to
> > go about integrating it properly.
Embedding a single class? I don't see the problem with that. We do it with
several Commons classes.
On 14 August 2017 at 11:59, Gary Gregory wrote:
> Wait a minute? We are embedding a third party jar? Yuk! -1, sorry that is
> not what I thought was happening.
>
> Gary
>
> On Aug 14, 2017 10:18,
>>> MessageFactory)
> >>>
> >>> Thoughts?
> >>>
> >>
> >> Why does it mean that?
> >>
> >
> > If we want the core to implement converting Class names to Logger names,
> > the Class must be passed down to the Core. Right now the LogManager does
> > that by calling org.apache.logging.log4j.spi.LoggerContext methods.
> These
> > methods take only String for the logger name.
>
> And that is a problem because….? I am trying to understand why
> LoggerContext will be required to accept a class name.
>
> Ralph
>
>
--
Matt Sicker
at 1:12 PM, Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
> >
> > See <https://builds.apache.org/job/Log4j%202.x/2980/display/
> redirect?page=changes>
> >
> >
>
>
>
--
Matt Sicker
til" level IMO.
> >
> > Gary
> >
> > On Mon, Aug 14, 2017 at 12:02 PM, Gary Gregory
> > wrote:
> >
> > > Ugh, not a fan, but I'll retract my -1.
> > >
> > > "a single class", yes, but a 4000 line class.
> > >
net/ssl/TestConstants.java
> @@ -17,14 +17,22 @@
> package org.apache.logging.log4j.core.net.ssl;
>
> public class TestConstants {
> -public static final String PATH = "src/test/resources/org/
> apache/logging/log4j/core/net/ssl/";
> +
> +public static final String SOURCE_FOLDER = "src/test/resources/";
> +public static final String RESOURCE_ROOT = "org/apache/logging/log4j/
> core/net/ssl/";
> +
> +public static final String PATH = SOURCE_FOLDER + RESOURCE_ROOT;
> public static final String TRUSTSTORE_PATH = PATH;
> +public static final String TRUSTSTORE_RESOURCE = RESOURCE_ROOT;
> public static final String TRUSTSTORE_FILE = TRUSTSTORE_PATH +
> "truststore.jks";
> +public static final String TRUSTSTORE_FILE_RESOURCE =
> TRUSTSTORE_RESOURCE + "truststore.jks";
> public static final char[] TRUSTSTORE_PWD = "changeit".toCharArray();
> public static final String TRUSTSTORE_TYPE = "JKS";
>
> public static final String KEYSTORE_PATH = PATH;
> +public static final String KEYSTORE_RESOURCE = RESOURCE_ROOT;
> public static final String KEYSTORE_FILE = KEYSTORE_PATH +
> "client.log4j2-keystore.jks";
> +public static final String KEYSTORE_FILE_RESOURCE = KEYSTORE_RESOURCE
> + "client.log4j2-keystore.jks";
> public static final char[] KEYSTORE_PWD = "changeit".toCharArray();
> public static final String KEYSTORE_TYPE = "JKS";
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
> 741be7fc/src/changes/changes.xml
> --
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index d1b1e13..9ff328a 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -31,6 +31,9 @@
> - "remove" - Removed
> -->
>
> +
> +Allow KeyStoreConfiguration and TrustStoreConfiguration to find
> files as resources.
> +
>
> Replace JCommander command line parser with picocli to let users
> run Log4j2 utility applications without requiring an external dependency.
>
>
>
--
Matt Sicker
t;s, no "$"s...
> > >
> > > How about that?
> > >
> > > Gary
> > >
> > > On Mon, Aug 14, 2017 at 3:24 PM, Gary Gregory
> > > wrote:
> > >
> > >> Another way to look at this is that instead of calling
I don’t want to make that change
> without consensus. I would also like to remove log4j 1 extras from the
> logging home page since it is EOL along with Log4j 1.
>
> Thoughts?
>
> Ralph
--
Matt Sicker
oint there was talk of API changes. Is that still needed?
> >>> Finally, I guess in order to keep supporting the current behaviour as
> well,
> >>> we still need to build configuration support for this >>> hierarchySeparators="./$" ... Is my understanding
-SNAPSHOT.pom
> > [JENKINS] Archiving <https://builds.apache.org/
> job/Log4j%202.x/ws/log4j-1.2-api/pom.xml> to org.apache.logging.log4j/
> log4j-1.2-api/2.9-SNAPSHOT/log4j-1.2-api-2.9-SNAPSHOT.pom
> > [JENKINS] Archiving <https://builds.apache.org/job/Log4j%202.x/ws/log4j-
> samples/configuration/pom.xml> to org.apache.logging.log4j.
> samples/log4j-samples-configuration/2.9-SNAPSHOT/
> log4j-samples-configuration-2.9-SNAPSHOT.pom
> > [JENKINS] Archiving <https://builds.apache.org/
> job/Log4j%202.x/ws/log4j-osgi/pom.xml> to org.apache.logging.log4j/
> log4j-osgi/2.9-SNAPSHOT/log4j-osgi-2.9-SNAPSHOT.pom
> > [JENKINS] Archiving <https://builds.apache.org/
> job/Log4j%202.x/ws/log4j-bom/pom.xml> to org.apache.logging.log4j/
> log4j-bom/2.9-SNAPSHOT/log4j-bom-2.9-SNAPSHOT.pom
> > [JENKINS] Archiving <https://builds.apache.org/
> job/Log4j%202.x/ws/log4j-jul/pom.xml> to org.apache.logging.log4j/
> log4j-jul/2.9-SNAPSHOT/log4j-jul-2.9-SNAPSHOT.pom
> > [JENKINS] Archiving <https://builds.apache.org/job/Log4j%202.x/ws/log4j-
> slf4j-impl/pom.xml> to org.apache.logging.log4j/
> log4j-slf4j-impl/2.9-SNAPSHOT/log4j-slf4j-impl-2.9-SNAPSHOT.pom
> > [JENKINS] Archiving <https://builds.apache.org/job/Log4j%202.x/ws/log4j-
> iostreams/pom.xml> to org.apache.logging.log4j/
> log4j-iostreams/2.9-SNAPSHOT/log4j-iostreams-2.9-SNAPSHOT.pom
> > [JENKINS] Archiving <https://builds.apache.org/
> job/Log4j%202.x/ws/pom.xml> to org.apache.logging.log4j/
> log4j/2.9-SNAPSHOT/log4j-2.9-SNAPSHOT.pom
> > [JENKINS] Archiving <https://builds.apache.org/
> job/Log4j%202.x/ws/target/log4j-2.9-SNAPSHOT-site.xml> to
> org.apache.logging.log4j/log4j/2.9-SNAPSHOT/log4j-2.9-SNAPSHOT-site.xml
> > [Fast Archiver] Compressed 72.60 KB of artifacts by 88.2% relative to
> #3004
> > [JENKINS] Archiving <https://builds.apache.org/
> job/Log4j%202.x/ws/log4j-to-slf4j/pom.xml> to org.apache.logging.log4j/
> log4j-to-slf4j/2.9-SNAPSHOT/log4j-to-slf4j-2.9-SNAPSHOT.pom
> > [JENKINS] Archiving <https://builds.apache.org/job/Log4j%202.x/ws/log4j-
> samples/flume-common/pom.xml> to org.apache.logging.log4j.
> samples/log4j-samples-flume-common/2.9-SNAPSHOT/log4j-
> samples-flume-common-2.9-SNAPSHOT.pom
> > channel stopped
> >
>
>
>
--
Matt Sicker
would
> use getCannonicalName().
>
> Any objection to adding that?
>
> Gary
>
--
Matt Sicker
wrote:
> > >
> > > On Thu, Jul 20, 2017 at 9:05 PM, Gary Gregory
> > > wrote:
> > >
> > >> On Thu, Jul 20, 2017 at 7:19 PM, Matt Sicker
> wrote:
> > >>
> > >>> I haven't been able to get to this so far this week. Been finishi
n a few rare places.)
> > >>>
> > >>> Gary
> > >>>
> > >>> On Mon, Aug 21, 2017 at 3:47 PM, Ralph Goers <
> > ralph.go...@dslextreme.com
> > >>>
> > >>> wrote:
> > >>>
> > >>>> Did you ask this question last week? Why is it needed? Why can’t
> this
> > >> be
> > >>>> handled in LogManager?
> > >>>>
> > >>>> Ralph
> > >>>>
> > >>>>> On Aug 21, 2017, at 2:10 PM, Gary Gregory
> > >>>> wrote:
> > >>>>>
> > >>>>> Hi All:
> > >>>>>
> > >>>>> I have a need for the shortcut method
> > >>>>> org.apache.logging.log4j.core.LoggerContext getLogger(Class) which
> > >> would
> > >>>>> use getCannonicalName().
> > >>>>>
> > >>>>> Any objection to adding that?
> > >>>>>
> > >>>>> Gary
> > >>>>
> > >>>>
> > >>>>
> > >>
> > >>
> > >>
> >
> >
> >
>
--
Matt Sicker
API we
> > > >> provide.
> > > >> >>>>>
> > > >> >>>>> Gary
> > > >> >>>>>
> > > >> >>>>> On Mon, Aug 21, 2017 at 4:30 PM, Ralph Goers <
> > > >> >> ralph.go...@dslextreme.com
> > > >> >>>>>
> > > >> >>>>> wrote:
> > > >> >>>>>
> > > >> >>>>>> So you are saying that your application is getting Loggers by
> > > doing
> > > >> >>>>>> LoggerContext.getLogger()? I guess I don’t really understand
> > why
> > > >> that
> > > >> >>>> is a
> > > >> >>>>>> good idea. Are you saying you have your own custom
> > LoggerContext
> > > >> and
> > > >> >>>> that
> > > >> >>>>>> you want to modify Log4j’s LoggerContext simply so you can
> > modify
> > > >> >> yours?
> > > >> >>>>>>
> > > >> >>>>>> Ralph
> > > >> >>>>>>
> > > >> >>>>>>> On Aug 21, 2017, at 3:01 PM, Gary Gregory <
> > > garydgreg...@gmail.com
> > > >> >
> > > >> >>>>>> wrote:
> > > >> >>>>>>>
> > > >> >>>>>>> My use case is that deep in the guts and call stack of my
> > > >> >> server/app, I
> > > >> >>>>>>> have a specific Core LoggerContext that I should/must use.
> > Log4j
> > > >> and
> > > >> >>>>>> other
> > > >> >>>>>>> components must co-exist in a long-lived server that have
> > > modules
> > > >> >> that
> > > >> >>>>>> are
> > > >> >>>>>>> constantly re-initialized/re-configured during development
> and
> > > >> >> testing
> > > >> >>>>>>> phases. During acceptance and production, the are fewer
> > > >> >>>> reconfigurations,
> > > >> >>>>>>> but they do happen. The bottom line is that most logging
> code
> > > >> dishes
> > > >> >>>> out
> > > >> >>>>>>> Loggers out of specific LoggerContext instances and not out
> of
> > > the
> > > >> >>>>>>> LogManager classes (only in a few rare places.)
> > > >> >>>>>>>
> > > >> >>>>>>> Gary
> > > >> >>>>>>>
> > > >> >>>>>>> On Mon, Aug 21, 2017 at 3:47 PM, Ralph Goers <
> > > >> >>>> ralph.go...@dslextreme.com
> > > >> >>>>>>>
> > > >> >>>>>>> wrote:
> > > >> >>>>>>>
> > > >> >>>>>>>> Did you ask this question last week? Why is it needed? Why
> > > can’t
> > > >> >> this
> > > >> >>>>>> be
> > > >> >>>>>>>> handled in LogManager?
> > > >> >>>>>>>>
> > > >> >>>>>>>> Ralph
> > > >> >>>>>>>>
> > > >> >>>>>>>>> On Aug 21, 2017, at 2:10 PM, Gary Gregory <
> > > >> garydgreg...@gmail.com>
> > > >> >>>>>>>> wrote:
> > > >> >>>>>>>>>
> > > >> >>>>>>>>> Hi All:
> > > >> >>>>>>>>>
> > > >> >>>>>>>>> I have a need for the shortcut method
> > > >> >>>>>>>>> org.apache.logging.log4j.core.LoggerContext
> > getLogger(Class)
> > > >> which
> > > >> >>>>>> would
> > > >> >>>>>>>>> use getCannonicalName().
> > > >> >>>>>>>>>
> > > >> >>>>>>>>> Any objection to adding that?
> > > >> >>>>>>>>>
> > > >> >>>>>>>>> Gary
> > > >> >>>>>>>>
> > > >> >>>>>>>>
> > > >> >>>>>>>>
> > > >> >>>>>>
> > > >> >>>>>>
> > > >> >>>>>>
> > > >> >>>>
> > > >> >>>>
> > > >> >>>>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >>
> > > >>
> > > >
> > >
> >
>
--
Matt Sicker
May not get a chance to work on this tonight. Haven't been feeling too well
today or yesterday. :(
On 21 August 2017 at 18:38, Matt Sicker wrote:
> I won't be free until Wednesday night at the earliest. If Ralph wants to
> start the release before that, I'm alright with t
property
names into a full unit test to verify the old names always work in the
future for BC.
On 23 August 2017 at 14:59, Gary Gregory wrote:
> I hope you fell better soon Matt.
>
> Gary
>
> On Wed, Aug 23, 2017 at 12:35 PM, Matt Sicker wrote:
>
> > May not get a chanc
gt; > Ralph
> >
> > > On Aug 26, 2017, at 11:21 AM, Ralph Goers
> > wrote:
> > >
> > >
> > > I am just about to start the release build of 2.9 so please hold off on
> > committing.
> > >
> > > Ralph
> > >
> &g
ain
> project have a dependency on that?
> >
> > Ralph
> >
> >> On Aug 26, 2017, at 11:21 AM, Ralph Goers
> wrote:
> >>
> >>
> >> I am just about to start the release build of 2.9 so please hold off on
> committing.
> >>
> >>
Starter$2.call(ForkStarter.java:429)
> [INFO] [ERROR] at org.apache.maven.plugin.surefire.booterclient.
> ForkStarter$2.call(ForkStarter.java:406)
> [INFO] [ERROR] at java.util.concurrent.FutureTask.run(FutureTask.
> java:262)
> [INFO] [ERROR] at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1145)
> [INFO] [ERROR] at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:615)
> [INFO] [ERROR] at java.lang.Thread.run(Thread.java:745)
> [INFO] [ERROR]
> [INFO] [ERROR] -> [Help 1]
> [INFO] [ERROR]
>
>
--
Matt Sicker
Ralph Goers
> wrote:
> >
> > The regular build ran fine. I’m trying it again.
> >
> > Ralph
> >
> >> On Aug 26, 2017, at 1:18 PM, Gary Gregory
> wrote:
> >>
> >> How about trying with Java 8?
> >>
> >> G
> >>
Works for me. I'll wait until the release is finalized.
On 26 August 2017 at 17:00, Ralph Goers wrote:
> I’d prefer not to add enhancements until after the release vote.
>
> Ralph
>
> > On Aug 26, 2017, at 1:58 PM, Matt Sicker wrote:
> >
> > Sounds good. Do
ira/browse/LOG4J2-1974>: Update
> >> ZeroMQ's JeroMQ from 0.4.1 to 0.4.2.
> >> LOG4J2-1869 <https://issues.apache.org/jira/browse/LOG4J2-1869>: Update
> >> Kafka client from 0.10.1.1 to 0.10.2.0
> >> LOG4J2-1962 <https://issues.apache.org/jira/browse/LOG4J2-1962>: Update
> >> Kafka client from 0.10.2.0 to 0.11.0.0
> >> LOG4J2-1872 <https://issues.apache.org/jira/browse/LOG4J2-1872>: Update
> >> JavaMail from 1.5.5 to 1.5.6.
> >> LOG4J2-1879 <https://issues.apache.org/jira/browse/LOG4J2-1879>: Update
> >> JAnsi from 1.14 to 1.15.
> >> LOG4J2-1877 <https://issues.apache.org/jira/browse/LOG4J2-1877>:
> Missing
> >> documentation for Max index limit in DefaultRolloverStrategy. Thanks to
> >> Chandra Tungathurthi.
> >> LOG4J2-1899 <https://issues.apache.org/jira/browse/LOG4J2-1899>: Add
> >> missing getters to classes in package org.apache.logging.log4j.core.
> >> net.ssl.
> >> LOG4J2-1900 <https://issues.apache.org/jira/browse/LOG4J2-1900>: Update
> >> JAnsi from 1.15 to 1.16.
> >> LOG4J2- <https://issues.apache.org/jira/browse/LOG4J2->: Update SLF4J
> >> from 1.7.24 to 1.7.25.
> >> LOG4J2-1938 <https://issues.apache.org/jira/browse/LOG4J2-1938>: Update
> >> Jackson from 2.8.7 to 2.8.9.
> >> LOG4J2-1970 <https://issues.apache.org/jira/browse/LOG4J2-1970>: Update
> >> HdrHistogram from 2.1.8 to 2.1.9.
> >> LOG4J2-1975 <https://issues.apache.org/jira/browse/LOG4J2-1975>: Update
> >> javax.persistence from 2.1.0 to 2.1.1.
> >> LOG4J2-1976 <https://issues.apache.org/jira/browse/LOG4J2-1976>: Update
> >> org.osgi.core from 4.3.1 to 6.0.0.
> >> Tag:
> >> a) for a new copy do "git clone https://git-wip-us.apache.org/
> >> repos/asf/logging-log4j2.git <https://git-wip-us.apache.
> >> org/repos/asf/logging-log4j2.git>" and then "git checkout
> >> tags/log4j-2.9-rc1”
> >> b) for an existing working copy to “git pull” and then “git checkout
> >> tags/log4j-2.9-rc1”
> >> Web Site: <http://rgoers.github.io/log4j2-site/index.html>http://
> >> rgoers.github.io/log4j2-site/index.html <http://rgoers.github.io/
> >> log4j2-site/index.html>
> >>
> >> Maven Artifacts: https://repository.apache.org/content/repositories/
> >> orgapachelogging-1029/ <https://repository.apache.
> >> org/content/repositories/orgapachelogging-1029/>
> >>
> >> Distribution archives: https://dist.apache.org/repos/
> >> dist/dev/logging/log4j/ <https://dist.apache.org/
> >> repos/dist/dev/logging/log4j/>
> >>
> >> You may download all the Maven artifacts by executing:
> >> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> >> https://repository.apache.org/content/repositories/
> >> orgapachelogging-1029/org/apache/logging/log4j/ <
> >> https://repository.apache.org/content/repositories/
> >> orgapachelogging-1029/org/apache/logging/log4j/>/ <
> >> https://repository.apache.org/content/repositories/
> >> orgapachelogging-1025/org/apache/logging/log4j/>
> >> Ralph
> >>
> >>
> >>
>
>
>
--
Matt Sicker
Any particular reason this is tagged as 2.9.0 instead of 2.9?
On 27 August 2017 at 19:03, Matt Sicker wrote:
>
>
> On 27 August 2017 at 11:23, Ralph Goers
> wrote:
>
>> Matt added an exclude for the docker file back before the 2.8. release.
>> I’m not sure why.
>
017 at 9:15 AM, Matt Sicker wrote:
>
> > Any particular reason this is tagged as 2.9.0 instead of 2.9?
> >
> > On 27 August 2017 at 19:03, Matt Sicker wrote:
> >
> > >
> > >
> > > On 27 August 2017 at 11:23, Ralph Goers
> > > wrot
rticle/pgp-security-weakness-exposed/>.
Side note: if we stick to calling this version 2.9.0, I'd like to stick
with that naming scheme moving forward for all 2.x.0 releases.
On 28 August 2017 at 10:18, Matt Sicker wrote:
> I do like the full version number, but I'm just
On 28 August 2017 at 14:27, Mikael Ståldal wrote:
> Oops, fixed in master branch now.
>
> I changed pom.xml and doap_log4j2.rdf, is that all?
That's all the places I know of. Thanks!
>
>
>
> On 2017-08-28 17:51, Matt Sicker wrote:
>
>> * Mikael still works
or as close as
> possible obviously) so we can maximize the few boxes we have. We just don't
> have enough need to run specific Windows configurations.
>
> Now that [2] is fixed, all windows nodes have the same capabilities and
> therefore this is not an issue.
>
> Cheers,
> Dominik
>
--
Matt Sicker
//search.maven.org/#search%7Cga%7C1%7Ca%3A%22log4j-core-its%22
>
> Shouldn't it be there?
>
> Gary
>
--
Matt Sicker
have a point.
On 30 August 2017 at 10:21, Gary Gregory wrote:
> But I think that is a _good_ thing to have all modules published.
>
> Gary
>
> On Wed, Aug 30, 2017 at 9:20 AM, Matt Sicker wrote:
>
> > I was the one who published 2.8.2, and I think I simply forgot to
eally updating anything anymore other than security patches if
applicable. Would you say it's similar in .net 2?
On 30 August 2017 at 02:39, Dominik Psenner wrote:
>
> On 2017-08-29 16:12, Matt Sicker wrote:
>
>> I'm not too familiar with this area, but would using Wi
9 <https://issues.apache.org/jira/browse/LOG4J2-1869>: Update
> Kafka client from 0.10.1.1 to 0.10.2.0
> > LOG4J2-1962 <https://issues.apache.org/jira/browse/LOG4J2-1962>: Update
> Kafka client from 0.10.2.0 to 0.11.0.0
> > LOG4J2-1872 <https://issues.apache.org/jira/browse/LOG4J2-1872>: Update
> JavaMail from 1.5.5 to 1.5.6.
> > LOG4J2-1879 <https://issues.apache.org/jira/browse/LOG4J2-1879>: Update
> JAnsi from 1.14 to 1.15.
> > LOG4J2-1877 <https://issues.apache.org/jira/browse/LOG4J2-1877>:
> Missing documentation for Max index limit in DefaultRolloverStrategy.
> Thanks to Chandra Tungathurthi.
> > LOG4J2-1899 <https://issues.apache.org/jira/browse/LOG4J2-1899>: Add
> missing getters to classes in package org.apache.logging.log4j.core.
> net.ssl.
> > LOG4J2-1900 <https://issues.apache.org/jira/browse/LOG4J2-1900>: Update
> JAnsi from 1.15 to 1.16.
> > LOG4J2- <https://issues.apache.org/jira/browse/LOG4J2->: Update SLF4J
> from 1.7.24 to 1.7.25.
> > LOG4J2-1938 <https://issues.apache.org/jira/browse/LOG4J2-1938>: Update
> Jackson from 2.8.7 to 2.8.9.
> > LOG4J2-1970 <https://issues.apache.org/jira/browse/LOG4J2-1970>: Update
> HdrHistogram from 2.1.8 to 2.1.9.
> > LOG4J2-1975 <https://issues.apache.org/jira/browse/LOG4J2-1975>: Update
> javax.persistence from 2.1.0 to 2.1.1.
> > LOG4J2-1976 <https://issues.apache.org/jira/browse/LOG4J2-1976>: Update
> org.osgi.core from 4.3.1 to 6.0.0.
> > Apache Log4j 2.9.0 requires a minimum of Java 7 to build and run. Log4j
> 2.3 was the last release that supported Java 6.
> >
> > Basic compatibility with Log4j 1.x is provided through the log4j-1.2-api
> component, however it does not implement some of the very implementation
> specific classes and methods. The package names and Maven groupId have been
> changed to org.apache.logging.log4j to avoid any conflicts with log4j 1.x.
> >
> > For complete information on Apache Log4j 2, including instructions on
> how to submit bug reports, patches, or suggestions for improvement, see the
> Apache Apache Log4j 2 website:
> >
> > https://logging.apache.org/log4j/2.x/ <https://logging.apache.org/
> log4j/2.x/>
>
>
--
Matt Sicker
2.8.9 to 2.9.0.
> > LOG4J2-1868 <https://issues.apache.org/jira/browse/LOG4J2-1868>: Update
> ZeroMQ's JeroMQ from 0.3.6 to 0.4.0.
> > LOG4J2-1960 <https://issues.apache.org/jira/browse/LOG4J2-1960>: Update
> ZeroMQ's JeroMQ from 0.4.0 to 0.4.1.
> > LOG4J2-1974 <https://issues.apache.org/jira/browse/LOG4J2-1974>: Update
> ZeroMQ's JeroMQ from 0.4.1 to 0.4.2.
> > LOG4J2-1869 <https://issues.apache.org/jira/browse/LOG4J2-1869>: Update
> Kafka client from 0.10.1.1 to 0.10.2.0
> > LOG4J2-1962 <https://issues.apache.org/jira/browse/LOG4J2-1962>: Update
> Kafka client from 0.10.2.0 to 0.11.0.0
> > LOG4J2-1872 <https://issues.apache.org/jira/browse/LOG4J2-1872>: Update
> JavaMail from 1.5.5 to 1.5.6.
> > LOG4J2-1879 <https://issues.apache.org/jira/browse/LOG4J2-1879>: Update
> JAnsi from 1.14 to 1.15.
> > LOG4J2-1877 <https://issues.apache.org/jira/browse/LOG4J2-1877>:
> Missing documentation for Max index limit in DefaultRolloverStrategy.
> Thanks to Chandra Tungathurthi.
> > LOG4J2-1899 <https://issues.apache.org/jira/browse/LOG4J2-1899>: Add
> missing getters to classes in package org.apache.logging.log4j.core.
> net.ssl.
> > LOG4J2-1900 <https://issues.apache.org/jira/browse/LOG4J2-1900>: Update
> JAnsi from 1.15 to 1.16.
> > LOG4J2- <https://issues.apache.org/jira/browse/LOG4J2->: Update SLF4J
> from 1.7.24 to 1.7.25.
> > LOG4J2-1938 <https://issues.apache.org/jira/browse/LOG4J2-1938>: Update
> Jackson from 2.8.7 to 2.8.9.
> > LOG4J2-1970 <https://issues.apache.org/jira/browse/LOG4J2-1970>: Update
> HdrHistogram from 2.1.8 to 2.1.9.
> > LOG4J2-1975 <https://issues.apache.org/jira/browse/LOG4J2-1975>: Update
> javax.persistence from 2.1.0 to 2.1.1.
> > LOG4J2-1976 <https://issues.apache.org/jira/browse/LOG4J2-1976>: Update
> org.osgi.core from 4.3.1 to 6.0.0.
> > Apache Log4j 2.9.0 requires a minimum of Java 7 to build and run. Log4j
> 2.3 was the last release that supported Java 6.
> >
> > Basic compatibility with Log4j 1.x is provided through the log4j-1.2-api
> component, however it does not implement some of the very implementation
> specific classes and methods. The package names and Maven groupId have been
> changed to org.apache.logging.log4j to avoid any conflicts with log4j 1.x.
> >
> > For complete information on Apache Log4j 2, including instructions on
> how to submit bug reports, patches, or suggestions for improvement, see the
> Apache Apache Log4j 2 website:
> >
> > https://logging.apache.org/log4j/2.x/ <https://logging.apache.org/
> log4j/2.x/>
>
>
--
Matt Sicker
your email.
>
> I sent it to the dev list as one email and the announce list as a second
> email since I have to use different email addresses. But the content was
> formatted exactly the same. I suspect the announce list does extra stuff.
>
> Ralph
>
> > On Aug 31
r an existing working copy to “git pull” and then “git checkout
>> tags/log4j-2.9-rc1”
>>
>>
>> On Aug 31, 2017, at 12:46 PM, Mikael Ståldal wrote:
>>>
>>> How can I do that?
>>>
>>> On 2017-08-28 18:18, Ralph Goers wrote:
>>>
>&
en.MavenModuleSetBuild.run(
> > MavenModuleSetBuild.java:542)
> > at hudson.model.ResourceController.execute(
> > ResourceController.java:97)
> > at hudson.model.Executor.run(Executor.java:405)
> > Caused by: org.eclipse.aether.deployment.DeploymentException: Failed to
> > deploy metadata: Could not transfer metadata org.apache.logging.log4j:
> > log4j-web:2.9.1-SNAPSHOT/maven-metadata.xml from/to
> > apache.snapshots.https (https://repository.apache.
> > org/content/repositories/snapshots): Failed to transfer file:
> > https://repository.apache.org/content/repositories/
> > snapshots/org/apache/logging/log4j/log4j-web/2.9.1-
> > SNAPSHOT/maven-metadata.xml. Return code is: 400, ReasonPhrase: Bad
> > Request.
> > at org.eclipse.aether.internal.impl.DefaultDeployer.deploy(
> > DefaultDeployer.java:348)
> > at org.eclipse.aether.internal.impl.DefaultDeployer.deploy(
> > DefaultDeployer.java:245)
> > at org.eclipse.aether.internal.impl.DefaultRepositorySystem.
> > deploy(DefaultRepositorySystem.java:420)
> > at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.
> > deploy(DefaultArtifactDeployer.java:139)
> > ... 11 more
> > Caused by: org.eclipse.aether.transfer.MetadataTransferException: Could
> > not transfer metadata org.apache.logging.log4j:log4j-web:2.9.1-SNAPSHOT/
> maven-metadata.xml
> > from/to apache.snapshots.https (https://repository.apache.
> > org/content/repositories/snapshots): Failed to transfer file:
> > https://repository.apache.org/content/repositories/
> > snapshots/org/apache/logging/log4j/log4j-web/2.9.1-
> > SNAPSHOT/maven-metadata.xml. Return code is: 400, ReasonPhrase: Bad
> > Request.
> > at org.eclipse.aether.connector.basic.MetadataTransportListener.
> > transferFailed(MetadataTransportListener.java:43)
> > at org.eclipse.aether.connector.basic.BasicRepositoryConnector$
> > TaskRunner.run(BasicRepositoryConnector.java:355)
> > at org.eclipse.aether.connector.basic.
> > BasicRepositoryConnector.put(BasicRepositoryConnector.java:288)
> > at org.eclipse.aether.internal.impl.DefaultDeployer.deploy(
> > DefaultDeployer.java:342)
> > ... 14 more
> > Caused by: org.apache.maven.wagon.TransferFailedException: Failed to
> > transfer file: https://repository.apache.org/content/repositories/
> > snapshots/org/apache/logging/log4j/log4j-web/2.9.1-
> > SNAPSHOT/maven-metadata.xml. Return code is: 400, ReasonPhrase: Bad
> > Request.
> > at org.apache.maven.wagon.providers.http.
> > AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:631)
> > at org.apache.maven.wagon.providers.http.
> > AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:553)
> > at org.apache.maven.wagon.providers.http.
> > AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:535)
> > at org.apache.maven.wagon.providers.http.
> > AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:529)
> > at org.apache.maven.wagon.providers.http.
> > AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:509)
> > at org.eclipse.aether.transport.wagon.WagonTransporter$
> > PutTaskRunner.run(WagonTransporter.java:644)
> > at org.eclipse.aether.transport.wagon.WagonTransporter.
> > execute(WagonTransporter.java:427)
> > at org.eclipse.aether.transport.wagon.WagonTransporter.put(
> > WagonTransporter.java:410)
> > at org.eclipse.aether.connector.basic.BasicRepositoryConnector$
> > PutTaskRunner.runTask(BasicRepositoryConnector.java:510)
> > at org.eclipse.aether.connector.basic.BasicRepositoryConnector$
> > TaskRunner.run(BasicRepositoryConnector.java:350)
> > ... 16 more
> > [INFO] Deployment failed after 6 min 55 sec
> > Build step 'Deploy artifacts to Maven repository' changed build result to
> > FAILURE
> >
>
--
Matt Sicker
red regressions and new bugs in
> 2.9.0?
>
>
>
> On 2017-09-11 09:39, Apache wrote:
>
>> I am thinking about doing the Log4J 2.9.1 release at the end of the week
>> as there are a couple of bugs I'd like published by the time Java 9 is
>> released.
>>
>> Ralph
>>
>>
>
--
Matt Sicker
that 2.10.0 is better I am happy to
> > accommodate.
> > >> Ralph
> > >>> On Sep 11, 2017, at 8:31 AM, Gary Gregory
> > wrote:
> > >>>
> > >>> Hi All,
> > >>>
> > >>> It seems to me that the recent a
derTest.log: line 0
> expected:<...syncLoggerContext i=[0]> but was:<...syncLoggerContext
> i=[128]>
>
> Gary
>
--
Matt Sicker
t/log4j-slf4j-impl-2.9.1-SNAPSHOT-sources.jar> to
> org.apache.logging.log4j/log4j-slf4j-impl/2.9.1-
> SNAPSHOT/log4j-slf4j-impl-2.9.1-SNAPSHOT-sources.jar
> [JENKINS] Archiving <https://builds.apache.org/job/Log4j%202.x/ws/log4j-
> slf4j-impl/target/log4j-slf4j-impl-2.9.1-SNAPSHOT-test-sources.jar> to
> org.apache.logging.log4j/log4j-slf4j-impl/2.9.1-
> SNAPSHOT/log4j-slf4j-impl-2.9.1-SNAPSHOT-test-sources.jar
> [JENKINS] Archiving <https://builds.apache.org/job/Log4j%202.x/ws/log4j-
> iostreams/pom.xml> to org.apache.logging.log4j/log4j-iostreams/2.9.1-
> SNAPSHOT/log4j-iostreams-2.9.1-SNAPSHOT.pom
> [JENKINS] Archiving <https://builds.apache.org/job/Log4j%202.x/ws/pom.xml>
> to org.apache.logging.log4j/log4j/2.9.1-SNAPSHOT/log4j-2.9.1-SNAPSHOT.pom
> [JENKINS] Archiving <https://builds.apache.org/job/Log4j%202.x/ws/target/
> log4j-2.9.1-SNAPSHOT-site.xml> to org.apache.logging.log4j/
> log4j/2.9.1-SNAPSHOT/log4j-2.9.1-SNAPSHOT-site.xml
> [Fast Archiver] Compressed 72.62 KB of artifacts by 88.1% relative to #3051
> [JENKINS] Archiving <https://builds.apache.org/
> job/Log4j%202.x/ws/log4j-to-
> slf4j/pom.xml> to org.apache.logging.log4j/log4j-to-slf4j/2.9.1-SNAPSHOT/
> log4j-to-slf4j-2.9.1-SNAPSHOT.pom
> [JENKINS] Archiving <https://builds.apache.org/
> job/Log4j%202.x/ws/log4j-to-
> slf4j/target/log4j-to-slf4j-2.9.1-SNAPSHOT.jar> to
> org.apache.logging.log4j/
> log4j-to-slf4j/2.9.1-SNAPSHOT/log4j-to-slf4j-2.9.1-SNAPSHOT.jar
> [JENKINS] Archiving <https://builds.apache.org/
> job/Log4j%202.x/ws/log4j-to-
> slf4j/target/log4j-to-slf4j-2.9.1-SNAPSHOT-sources.jar> to
> org.apache.logging.log4j/log4j-to-slf4j/2.9.1-SNAPSHOT/
> log4j-to-slf4j-2.9.1-SNAPSHOT-sources.jar
> [JENKINS] Archiving <https://builds.apache.org/
> job/Log4j%202.x/ws/log4j-to-
> slf4j/target/log4j-to-slf4j-2.9.1-SNAPSHOT-test-sources.jar> to
> org.apache.logging.log4j/log4j-to-slf4j/2.9.1-SNAPSHOT/
> log4j-to-slf4j-2.9.1-SNAPSHOT-test-sources.jar
> [JENKINS] Archiving <https://builds.apache.org/job/Log4j%202.x/ws/log4j-
> samples/flume-common/pom.xml> to org.apache.logging.log4j.
> samples/log4j-samples-flume-common/2.9.1-SNAPSHOT/log4j-
> samples-flume-common-2.9.1-SNAPSHOT.pom
> channel stopped
>
--
Matt Sicker
low.*;
> import static org.apache.logging.log4j.core.tools.picocli.CommandLine.
> Help.Column.Overflow.SPAN;
> import static org.apache.logging.log4j.core.tools.picocli.CommandLine.
> Help.Column.Overflow.TRUNCATE;
> import static org.apache.logging.log4j.core.tools.picocli.Comm
pache.logging.log4j. That means changing the module name and artifact
> ID though to avoid jar hell. log4j-slf4j-to-log4j and log4j-log4j-to-slf4j?
> A bit wordy... proposals?
>
> Gary
>
>
> > Ralph
>
--
Matt Sicker
Looking closer, it says it cannot find the symbol, not the class. Missing
import statement.
On 11 September 2017 at 21:36, Gary Gregory wrote:
> I fixed something I broke...
>
> Gary
>
> On Sep 11, 2017 18:08, "Matt Sicker" wrote:
>
> > I wonder if the jenkin
ems there is some mismatch with Netty versions and APIs coming and
> going. Let me know if you can take a look.
>
> Gary
>
--
Matt Sicker
s I first tried to do, We could
> put
> >> in a bunch of code to try to detect android and disable stuff that
> doesn’t
> >> work there, but that is quite a bit of work and as far as I can tell
> none
> >> of the committers work with Android. Finally, we could create a
> >> log4j-android that contains the API combined with a minimal version of
> core.
> >>
> >> Any thoughts on this?
> >>
> >> Ralph
> >>
>
>
>
--
Matt Sicker
test Log4j 2.9.1 with Java
> 9 GA to verify that everything works fine. If not, we can do a 2.9.2 to fix
> any issues found.
>
> Then we add new features for 2.10.0.
>
>
>
> On 2017-09-12 06:18, Ralph Goers wrote:
>
>> OK. The module is commented out along with the update to changes.xml.
>>
>> Ralph
>>
>
--
Matt Sicker
d since 2.8. I have updated it to 2.9.0 now.
>
> We should make sure to update it for every release.
>
> Do we have a release checklist? On that we should add to create a Git tag,
> and update README.md.
>
--
Matt Sicker
27;t have any. Can we do that?
>
> See my discussion with the Graylog people: https://community.graylog.org/
> t/adding-a-gelf-library-in-graylog-marketplace/2413/2
>
--
Matt Sicker
the next
> board report in November or retire it.
>
> Are there any volunteers?
>
> Ralph
>
--
Matt Sicker
>>> the release to the release version and then be updated again after the
>>> release to the snapshot version. Everywhere else a version appears in
>>> things that are part of the release it is rendered via a velocity template
>>> using the release version in the pom. I really do not want to be manually
>>> updating this.
>>>
>>> Ralph
>>>
>>
--
Matt Sicker
ing working copy to “git pull” and then “git checkout
> > tags/log4j-2.9.1-rc1”
> >
> > Web Site: http://rgoers.github.io/log4j2-site/index.html
> >
> > Maven Artifacts: https://repository.apache.org/content/repositories/
> > orgapachelogging-1030
> >
> > Distribution archives: https://dist.apache.org/repos/
> > dist/dev/logging/log4j/
> >
> > You may download all the Maven artifacts by executing:
> > wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> > https://repository.apache.org/content/repositories/
> > orgapachelogging-1030/org/apache/logging/log4j/
> >
> > Ralph
> >
>
--
Matt Sicker
at 15:14, Gary Gregory wrote:
> Hi All,
>
> Scala 2.12.3 has been out for a little while. Do we need a new module to
> match?
>
> Gary
>
--
Matt Sicker
sible.
> >>>>> The trade off is that we'd need to track the SLF4J binding mechanism
> and update our implementation when this binding mechanism changes.
> >>>>>
> >>>>> What problem are we trying to solve?
> >>>>>
> >>>>> Remko
> >>>>>
> >>>>>> On Sep 25, 2017, at 7:16, Ralph Goers <mailto:ralph.go...@dslextreme.com>> wrote:
> >>>>>>
> >>>>>> In looking at the implementations of log4j-slf4j-impl and
> log4j-to-slf4j is strikes me that log4j-to-slf4j is binding to the SLF4J
> API while log4j-slf4j-impl is binding the SFL4J API to the log4j
> implementation using SLF4J’s binding mechanism. So it seems to me that
> instead of having log4j-to-slf4j call the SLF4J API we ought to be able to
> have it call the SLF4J bindings and completely bypass SLF4J itself. Some
> user’s might find this more palatable as it would remove one layer between
> the Log4j API and whatever logging implementation the user chose.
> >>>>>>
> >>>>>> Thoughts?
> >>>>>>
> >>>>>> Ralph
> >>>>>
> >>>>
> >>
> >
>
>
--
Matt Sicker
ogback specifically. We
> should support binding to any SLF4J implementation (including Logback). We
> should probably test this with Logback though, since it's one of the most
> popular SLF4J implementations.
> >
> >
> >> On 2017-09-26 03:58, Matt Sicker wrote:
&g
Or a better example would be my key being based on something in the
ThreadContext (e.g., a request or correlation ID).
On 1 October 2017 at 17:25, Matt Sicker wrote:
> I wouldn't worry too much about the Travis build, though that looks like a
> bug in our config rather than anything
/lib/jvm/java-7-oracle/bin/java
>
> https://travis-ci.org/apache/logging-log4j2/jobs/281703149
>
> Thank you.
>
--
Matt Sicker
@@
>invitations depends on many factors.
> mailing list
> The Log4j developers' primary mailing list for discussion of
> issues
> - and changes related to the project (
> log4j-...@logging.apache.org ).
> + and changes related to the project ( dev@logging.apache.org
> ).
>Subscription to the list is open, but only subscribers can post
>directly to the list.
> private list
>
>
--
Matt Sicker
for appenders and layouts in
> log4j-core. Does that apply to the managers used by appenders as well?
>
--
Matt Sicker
users are eager to get access to some newly added features:
> >> https://github.com/apache/logging-log4j2/pull/110
> >> When do we plan to do a 2.10.0 release?
> >
>
>
>
--
Matt Sicker
nd I have a hard time filtering this list because of how
> some
> > of the emails are generated.
> >
> > I would also say that we expect every committer to be subscribed to that
> > list.
> >
> > Ralph
> >
>
--
Matt Sicker
list
> >> during the quarter. In my view, having the GitHub, Jira, Jenkins,
> etc
> >> emails on the dev list skews things as they dominate they number of
> “real”
> >> discussion emails that happen on the list, which is what I think is
> the
>
ules. This is currently
> used with Apache Fluo, and thought it might be useful here.
>
> Before adding a JIRA I felt I would ask the community. Thank you!
>
> Sincerely,
> Kenneth McFarland
>
--
Matt Sicker
src/site/xdoc/manual/appenders.xml
> +++ b/src/site/xdoc/manual/appenders.xml
> @@ -1735,6 +1735,11 @@ public class JpaLogEntity extends
> AbstractLogEventWrapperEntity {
>The Kafka topic to use. Required.
>
>
> + key
o I'm not even sure how feasible it would be to cut
a release before going ahead with the next generation. If we start working
on a major version of Chainsaw without a release for the existing code,
would that need to take place in the incubator, or can we go forward here?
--
Matt Sicker
I merged my properties branch. Started a new thread about Chainsaw.
On 12 October 2017 at 16:03, Ralph Goers wrote:
> Please do work on Chainsaw. Of course, that isn’t related to a Log4j
> release (or vice versa).
>
> Ralph
>
> > On Oct 12, 2017, at 1:53 PM, Matt Sicker wr
and thought it might be useful here.
> > >
> > > Before adding a JIRA I felt I would ask the community. Thank you!
> > >
> > > Sincerely,
> > > Kenneth McFarland
> > >
> >
> >
> >
> > --
> > Matt Sicker
> >
>
--
Matt Sicker
13:01, Matt Sicker wrote:
> First off, for some reason, there are two repositories:
>
> https://github.com/apache/chainsaw
> https://github.com/apache/logging-chainsaw
>
> The second one appears to be up to date. Not sure what to do about the
> first one as it seems to be a
4 October 2017 at 13:12, Gary Gregory wrote:
> I would really stay away from Java 9 at this point. There is too much
> incompatible tooling out there at this point. I can't even run most apps
> out of the box I have laying around on Java 9 without breakage.
>
> Gary
>
> On
I also opened a ticket about the bugzilla to jira part:
https://issues.apache.org/jira/browse/INFRA-15282
On 14 October 2017 at 13:15, Matt Sicker wrote:
> I'm looking at the infra stuff right now. Found this: <
> https://issues.apache.org/jira/browse/INFRA-8439>. So it appears
e since they all support linking and compiling Java source files as
well.
--
Matt Sicker
uld find or help build a GUI that
works better for that, then that'd be great. I'm also not a fan of the
whole "embed Chrome and call it a native app" movement going on with
Electron; even Java is lightweight on the desktop in comparison!
--
Matt Sicker
's one of the lower overhead formats to parse right now
until we have some avro/thrift ones.
> Me, I've been working on a private cloud IaaS implementation for a few
> years now - almost no Java there.
>
So if I had to guess, I'd say: Go, Ruby, Python?
--
Matt Sicker
mat that should perform
> much better than SimpleDateFormat.
>
> Ralph
>
> > On Oct 15, 2017, at 12:10 PM, Matt Sicker wrote:
> >
> > On 14 October 2017 at 23:34, Scott Deboy wrote:
> >
> >> Parsing time strings to their numeric values using SimpleDateFor
gh.)
>
>
>
> On 2017-10-14 20:12, Gary Gregory wrote:
>
>> I would really stay away from Java 9 at this point. There is too much
>> incompatible tooling out there at this point. I can't even run most apps
>> out of the box I have laying around on Java 9 wit
j-core.
>
Agreed. Moving away from serialized layouts and having first class support
for any type of safer serialized layout (in this case, the existing json
layout) should be emphasized.
--
Matt Sicker
ems totally unrelated to what I committed.
>
--
Matt Sicker
osts and combine those logs into a single view in
> Chainsaw.
>
That's a pretty cool use case!
--
Matt Sicker
t; --- a/pom.xml
> +++ b/pom.xml
> @@ -216,7 +216,7 @@
>
> info
> 1.2.1
> -2.10.0
> +2.11.0
> -Xms256m -Xmx1024m
> 1.7
>
>
>
--
Matt Sicker
t; proposed.
>
> Ralph
>
> > On Oct 17, 2017, at 1:02 PM, Gary Gregory
> wrote:
> >
> > You're welcome.
> >
> > I'm finding that more and more dependencies have updated to Java 8. I'd
> > like to get there sooner rather than late
e it with Java 8. We know it
> builds fine with either Java 7 or Java 8.
> >
> > Ralph
> >
> >> On Oct 17, 2017, at 1:45 PM, Matt Sicker wrote:
> >>
> >> Perhaps it would be useful to figure out how to run tests in parallel:
> run
> >> a
of encoding and decoding the
format in Java, C++, .NET, and PHP (or as a C binding for PHP).
Potentially, this format could be inclusive with other logging projects
like Logstash, Logback, Splunk, etc.
What do you all think? Is this a good idea? Or would this be duplicating
effort from other standards alr
at 10:21, Gary Gregory wrote:
> What about BSON?
>
> Gary
>
> On Oct 19, 2017 08:41, "Matt Sicker" wrote:
>
> > I don't have the ticket on hand, but a few months ago, Remko suggested a
> > binary logging format that would allow for super fast
ranch until we understand what it looks like. If it is going
> to apply to many things it probably makes sense to be a separate repo.
>
> Ralph
>
> > On Oct 19, 2017, at 8:26 AM, Matt Sicker wrote:
> >
> > For generic structured records, I'd probably go with Avro or
R repo? We have so many already... but I see what the big
> >>> picture is. Would this add a new layout in Core? Maybe we should just
> >> start
> >>> with that... then grow...
> >>>
> >>> Gary
> >>>
> >>> On Thu, Oct 19, 201
ady... but I see what the big
>>> picture is. Would this add a new layout in Core? Maybe we should just
>>> start
>>> with that... then grow...
>>>
>>> Gary
>>>
>>> On Thu, Oct 19, 2017 at 9:57 AM, Matt Sicker wrote:
>>>
> >> splitting up log4j-nosql into its three parts.
> >>
> >> We should mention in release notes in next release that those who use
> >> log4j-nosql need to change dependency to one (or more) of log4j-couchdb,
> >> log4j-mongodb or log4j-cassandra instead.
> >>
> >
>
--
Matt Sicker
e.flapdoodle.embed
> de.flapdoodle.embed.mongo
> 2.0.0
> test
>
>
> This is what I did at work and it works like a charm.
>
> Gary
>
--
Matt Sicker
servlet-related integration years ago. The only reason I
know for using version 2.5 is that it still works with 2.5 without any
modifications, so the minimum supported version has never been increased
despite Servlet 2.5 being EOL most likely.
Matt Sicker
ct 14, 2017 11:44 AM, "kenneth mcfarland" >
> wrote:
>
> > Thank you Matt, I will try provide a patch by the end of the weekend.
> >
> > Cheers,
> > Kenneth
> >
> >
> > On Oct 14, 2017 11:02 AM, "Matt Sicker" wrote:
> >
>
enclosed pattern. The style can consist of
>a comma separated list of style names from the
> following table.
> + (See Jansi configuration.)
>
>
>Style Name
> @@ -1645,17 +1648,18 @@ W
ipJansi` with
> `log4j2.skipJansi`, in both code and documentation?
>
>
>
> > On Oct 24, 2017, at 14:03, Matt Sicker wrote:
> >
> > Can you use the new system property naming scheme? This would be
> > log4j2.skipJansi. That property would work regardless with the n
gt; On 2017-10-24 15:04, Remko Popma wrote:
> > >> You mean let’s replace all occurrences of `log4j.skipJansi` with
> > `log4j2.skipJansi`, in both code and documentation?
> > >>> On Oct 24, 2017, at 14:03, Matt Sicker wrote:
> > >>>
> >
g.md>.
Let me know what you think!
--
Matt Sicker
use different APIs ... SLF4J ... Log4J ... so if
> that were included / referenced I think it would be a plus. In case you
> feel like expanding on the integration with Logstash that would be awesome
> too. The ELK stack seems to be getting pretty popular.
>
> Cheers,
>
> Ole
&
e rest of the
> reference material (Flume, etc.) would be a valued addition.
>
>
> On 10/30/2017 02:20 PM, Matt Sicker wrote:
>
>> I could spend an entire blog post about Logstash and ELK in general, so I
>> feel it's out of scope here.
>>
>> As for the
er to the "ELK stack" instead.
Also makes sense. I'm so used to using Elasticsearch by itself, I tend to
forget it's also part of that stack.
--
Matt Sicker
19,6 +119,9 @@
>
> [TagLib] Update servlet-api provided dependency from 2.5 to 3.0.1.
>
> +
> +Update Apache Kafka kafka-clients from 0.11.0.1 to 1.0.0.
> +
>
>
>
>
>
--
Matt Sicker
1 - 100 of 1881 matches
Mail list logo
