+1
On Sun, May 9, 2021 at 12:21 PM Stephen Webb wrote:
> +1
>
> On Sun, May 9, 2021 at 1:13 PM Robert Middleton
> wrote:
>
> > As a reminder, this vote is still outstanding.
> >
> > -Robert Middleton
> >
> > On Tue, May 4, 2021 at 7:10 PM Robert Middleton
> > wrote:
> > >
> > > I've updated th
+1
On Sun, Jun 6, 2021 at 9:36 AM Robert Middleton
wrote:
> This vote is to release Apache Chainsaw 2.1.0. This fixes a few
> annoying issues with chainsaw and some other bugs, as well as updating
> some dependencies.
>
> This vote supersedes the original vote
>
> Differences from RC1:
> * Adde
I remember looking at PatternLayout performance, I reported my findings here,
hopefully they’re still useful: https://issues.apache.org/jira/browse/LOG4J2-930
If %d is used in the pattern, does the FixedDateFormat get used?
> On Aug 28, 2021, at 4:33, Ralph Goers wrote:
>
> All of that agr
ormat with
> FixedFormat.DEFAULT. The FastDateFormat alternative does not support
> microseconds, so it doesn't suffer from the same problem. I think I can
> substantially reduce the frequency we re-format dates by checking
> FixedFormat.secondFractionDigits to determine if we meed to co
I don't have access to those boxes any more.
I will be going on holiday from tomorrow without access to work email so it
will be difficult for me to find out.
One way is to assume they were new and look at what was the fastest
reported speed for 2015 SSDs.
I found this:
https://www.alphr.com/ssds/
+1
On Sat, Oct 30, 2021 at 2:13 AM Davyd McColl
wrote:
> Hi
>
> I'd like to raise a vote to release log4net 2.0.13 (this is an rc2 where
> the only difference is the archive layout for the associated source and
> binary artifacts)
>
> - there's an rc up at GitHub with release notes:
> https://gi
What do the generated files look like?
Is the output that is generated in concurrent mode longer or shorter than
the expected length?
Also, does it contain one entry (one log message) per line, or is it
scrambled? Are entries ordered by time?
On Fri, Nov 12, 2021 at 12:34 AM Ralph Goers
wrote:
>
Why not have separate entries for each change instead of this one
big thingy:
- org.eclipse.persistence:javax.persistence . 2.1.1 -> 2.2.1
- org.eclipse.persistence:org.eclipse.persistence.jpa ... 2.6.5 -> 2.6.9
- org.fusesource.jansi:jansi
+1
On Fri, Dec 10, 2021 at 1:31 AM Gary Gregory wrote:
> Sounds good.
>
> Gary
>
> On Thu, Dec 9, 2021, 11:02 Volkan Yazıcı wrote:
>
> > SetUtils is only used by log4j-web, yet it is in log4j-core. I want to
> mark
> > it as deprecated in release-2.x and remove it in master. Objections?
> >
>
+1
build succeeds and all tests pass on my windows machine.
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default loca
I would say no. Lookups are very powerful and useful.
We could consider removing JNDI lookups.
The biggest problem however is that the lookups are applied to the logging
message *parameters*.
The logging message is controlled by the application, so any lookups there
should be fine or at least any
+1
build succeeds, all tests pass
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encoding:
Shall we discuss this first please?
On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker wrote:
> If you can handle that change, I can roll a new release candidate.
>
> Matt Sicker
>
> > On Dec 12, 2021, at 14:07, Volkan Yazıcı wrote:
> >
> > I know. I want them to be removed, not disabled.
> >
> >> On
change like this be in a
point/bugfix release (2.15.1) or should it be a separate minor release like
2.16.0?
On Mon, Dec 13, 2021 at 5:10 AM Remko Popma wrote:
> Shall we discuss this first please?
>
> On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker wrote:
>
>> If you can handle t
On Mon, Dec 13, 2021 at 5:47 AM Remko Popma wrote:
> First, is this really a blocker for 2.15.1?
> I think it is prudent to do urgent releases soon.
> This JNDI change (LOG4J2-3208
> <https://issues.apache.org/jira/browse/LOG4J2-3208>) feels urgent enough
> to warrant a
> > lookup. I want to believe that users get this fact right and have already
> > disabled it. We need to be really careful with our next release. We can't
> > expect people to upgrade once a week. Putting aside the damage it does to
> > the reputation of the
>
> Gary
>
>> On Sun, Dec 12, 2021, 20:40 Remko Popma wrote:
>>
>> I am also okay with removing Message Lookups from 2.x.
>> A release with that change should be called 2.16.0 though, not 2.15.1 or
>> 2.15.2.
>>
>> Also it makes sense to *only* have
eases in a week is a lot even for me :-)
>>
>> Gary
>>
>>> On Sun, Dec 12, 2021 at 9:41 PM Remko Popma wrote:
>>> It seems that Ralph has already started to work on a PR to remove message
>>> lookups altogether from 2.x.
>>> I have come around
Hi Daniel,
The plan is to disable lookups in log messages completely in the next Log4j
release.
If you can tell us your concrete use case we may be able to advise on how
to implement it safely.
Lookups in configuration will continue to work (but JNDI will require an
extra setting to be enabled).
+1 build succeeds and tests all pass
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encodin
Hi Vladimir,
Thank you for your interest!
You mentioned that "The maintenance overheads for releasing 1.2.18 do not
seem to be severe".
Have you actually tried building the project to see if this is true?
Remko
On Tue, Dec 14, 2021 at 11:13 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wr
On Tue, Dec 14, 2021 at 11:44 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> >My understanding is it requires an extremely
> >old JDK.
> >Have you actually tried building the project to see if this is true?
>
> I was able to build the project with Maven3 and Java 1.8 by commenting ou
+1 very light validation but ran a simple test program against the binaries
On Wed, Dec 15, 2021 at 3:19 AM Carter Kozak wrote:
> +1
>
> validated the build and signatures, tests in core modules.
>
> On Tue, Dec 14, 2021, at 00:58, Ralph Goers wrote:
> > This is a vote to release Log4j 2.12.2, a
Yes. It certainly looks like it (on my phone now).
On Thu, Dec 16, 2021 at 14:53 GitBox wrote:
>
> ichux commented on a change in pull request #607:
> URL:
> https://github.com/apache/logging-log4j2/pull/607#discussion_r770242666
>
>
>
> ##
> File path: src/site/xdoc/manual/layouts.xml.v
+1
GNU signatures check ok.
Build passed with
maven clean install
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default
Hi Milind,
Please take a look at this page, which has all the details:
https://logging.apache.org/log4j/2.x/security.html
In short, the log4net library is not impacted.
Only log4j (the java library) is impacted by this vulnerability.
Kind regards,
Remko
On Sat, Dec 18, 2021 at 6:24 AM Milind W
Thank you Gary! Great catch!
On Tue, Dec 21, 2021 at 11:51 AM Gary Gregory
wrote:
> I'm not sure this is the right branch, I think log4j-2.3.x is the
> right one.
>
> Ralph?
>
> Gary
>
> On Mon, Dec 20, 2021, 21:33 wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
+1
Remko
On Tue, Dec 21, 2021 at 12:52 PM Carter Kozak wrote:
> +1
>
> -ck
>
> > On Dec 20, 2021, at 22:46, Matt Sicker wrote:
> >
> > +1
> >
> > Notes on the release:
> > * Sigs and checksums good
> > * Builds and tests fine
> > * Outdated copyright year in NOTICE.txt
> >
> > --
> > Matt Sick
-1 it does not work...
Problem running a simple pipecleaning test on Java 6 with 2.3.1...
My pipecleaning program is something simple like this
public class Pipecleaning {
public static void main(String[] args) {
org.apache.logging.log4j.LogManager.getLogger().info("HELLO
USER ${sys:u
Vladimir,
Have you had a chance to work on a patch for the security vulnerabilities?
While there is understandably not much interest in “resurrecting” the Log4j 1.x
project, overall people are positive about releasing a 1.2.18 with security
patches.
I think it would be most helpful if we can
gt; On Tue, Dec 21, 2021 at 7:37 AM Ralph Goers
>> wrote:
>>
>> Hmmm. This is not what I was expecting. If it didn’t work I would have
>> expected bad class version exceptions.
>>
>> Ralph
>>
>>>> On Dec 21, 2021, at 4:28 AM, Remko Popma
+1 I am changing my vote.
My earlier pipecleaning program failed because the config had a JmsAppender
configured in it... My bad.
Signatures are good.
Pipecleaning program works on Java 6 when I remove the JmsAppender from the
config.
On Wed, Dec 22, 2021 at 6:23 AM Ralph Goers
wrote:
> My +1
>
The Log4j1 project is EOL, and assuming that it remains EOL and we are only
doing security patches, I vote in favor of this repo change, to
facilitate making such security patches.
+1
I agree we need to get consensus on the scope of any Log4j1 work.
On Fri, Dec 24, 2021 at 8:55 AM Ralph Goers
w
The Log4j1 project is EOL, and assuming that it remains EOL and we are only
doing security patches, I vote in favor of this repo change, to
facilitate making such security patches.
+1
I agree we need to get consensus on the scope of any Log4j1 work.
On Fri, Dec 24, 2021 at 8:53 AM Matt Sicker wr
Vladimir,
There is a vote thread in progress (
https://lists.apache.org/thread/0rk0nr0pv9p2945jsrs9pp2ys57wksn3). You and
I both voted on that thread.
Looking at the number of +1 votes on that voting thread, surely you can see
that this repo will be created, and not only that, it will be created
*
+1
On Sat, Dec 25, 2021 at 6:35 AM Ralph Goers
wrote:
> +1
>
> I checked the signature and hashes and those look good.
>
> I unzipped the source and binaries. The appropriate license and notice
> files are present.
>
> I did not perform tests as I don’t have the necessary tools installed.
>
> Ra
+1
signatures and hashes ok
build ok
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encodin
+1
signatures and hashes OK
build tag log4j-2.12.4-rc1 OK
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale:
+1
Hashes and signatures OK,
build OK:
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform enco
I agree that would be great.
Meanwhile, I am using this script/command to achieve the same result:
for a in 1 256 512; do
for f in `find . -type f -name "*.sha${a}"`; do
claim=`cat $f |cut -d' ' -f1`;
actual=`shasum ${f%.sha*} -a ${a} |cut -d' ' -f1`;
if [[ "$claim" == "$actual" ]];
On Tue, Dec 21, 2021 at 2:41 AM Ralph Goers
wrote:
> Thanks Dick,
>
> I am totally unfamiliar with this. Is there somewhere to read about what
> this is all about?
>
> Ralph
>
Resending, including Dick in the recipients.
>
> > On Dec 20, 2021, at 7:18 AM, Dick Brooks <
> d...@reliableenergyana
I also like this idea and agree with separate accounts for each component.
On Fri, Dec 31, 2021 at 7:48 AM Gary Gregory wrote:
> Great idea. I would suggest one account for the each component. I'm not
> sure anyone but the PMC would care about a logging services account.
>
> Gary
>
> On Thu, Dec
+1 for Option 1
On Wed, Jan 5, 2022 at 4:51 AM Volkan Yazıcı wrote:
> +1, Option 1
>
> On Wed, 29 Dec 2021, 20:33 Christian Grobmeier
> wrote:
>
> > Hello,
> >
> > as discussed in another thread, this is a vote about the future of log4j
> > 1. This vote stays open for the usual 72h.
> > Options
+1
Signatures good, checksums good.
Build passes (ignoring rev-api problem for the mongodb3 module)
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
Remko Popma wrote:
> +1
>
> Signatures good, checksums good.
>
> Build passes (ignoring rev-api problem for the mongodb3 module)
>
> Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
> 2019-08-28T00:06:16+09:00)
> Maven home: C:\apps\apache-maven-3.6.2\bin\.
I remember we discussed changing our development process to use PRs instead
of committing directly to the release branches.
This was part of trying to increase our security score, especially the
Branch Protection part
in scorecard (https://github.com/ossf/scorecard/blob/main/docs/checks.md).
Quest
Maybe the complaints about startup time have to do with this:
note that every time a PatternParser is instantiated, we load all plugins
again...
public PatternParser(final Configuration config, final String
converterKey, final Class expectedClass,
final Class filterClass) {
this.confi
are
> themselves instantiated only on first use).
>
> On Fri, Apr 15, 2022 at 6:51 AM Remko Popma wrote:
> >
> > Maybe the complaints about startup time have to do with this:
> >
> > note that every time a PatternParser is instantiated, we load all plugins
> > a
+1
On Sat, Apr 16, 2022 at 10:01 AM Robert Middleton
wrote:
> This is a vote to release log4cxx 0.13.0.
>
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
>
> This vote will remain open for 72 hours(or mor
Hi all,
I am trying to merge the changes for LOG4J2-3472 into master, but I have
trouble building the master branch... (and I don't think it is because of
my changes)
Am I missing something?
My environment
-
C:\Users\remko\IdeaProjects\logging-log4j2>mvn --version
Apache Maven
:52, Piotr P. Karwasz wrote:
>
> Hello Remko,
>
>> On Thu, 21 Apr 2022 at 13:14, Remko Popma wrote:
>>
>> Warnings look like this:
>> [WARNING]
>>
>> C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\LogMa
itory.
> >
> > rpopma pushed a commit to branch release-2.x
> > in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
> >
> > commit 97b8c1dc4f320e855f26a0690651fc062f08361a
> > Author: Remko Popma
> > AuthorDate: Fri Apr 22 05:15:15 2022 +
+1
> On Jun 22, 2022, at 2:09, Matt Sicker wrote:
>
> Bump.
>
>> On Sat, Jun 18, 2022 at 12:07 PM Matt Sicker wrote:
>>
>> Hi all, this is a vote to release Log4j Kotlin API 1.2.0 rc4. This vote will
>> be open for at least 72 hours, requires at least 3 +1 votes and more +1
>> votes than
+1 sigs good
On Thu, Jun 30, 2022 at 8:23 PM Gary Gregory wrote:
> I just ran it again and I get the same error, so I can't validate the
> build for now.
>
> Gary
>
> On Wed, Jun 29, 2022 at 9:25 PM Matt Sicker wrote:
> >
> > If that test isn’t using the listener mechanism in LoggerContext, the
It would be truly awesome to get this to work! Triple yay!
I would keep it as simple as possible though, and not worry too much about
being super user friendly.
Asking folks to recompile to get this feature is not a big ask, and
avoiding complexity like weaving is a big advantage.
Not working for
I don’t think that’s the only sane option.
Another sane option is to ignore it.
There’s nothing that says Log4j has to implement any enhanced SLF4J APIs.
He wants to be the lowest common denominator in logging APIs, then he can’t add
APIs that aren’t supported in the major implementations.
Agree, makes sense.
> On Aug 27, 2022, at 7:50, Gary Gregory wrote:
>
> Makes sense.
>
> Gary
>
>> On Fri, Aug 26, 2022, 15:55 Ralph Goers wrote:
>>
>> Ceki never released a GA version of SLF4J 1.8. Since we are adding
>> support for SLF4J 2.0 in the next release I would suggest we also
+1 Remko
On Tue, Jan 3, 2023 at 4:57 PM Thorsten Schöning
wrote:
> Guten Tag Robert Middleton,
> am Sonntag, 1. Januar 2023 um 19:06 schrieben Sie:
>
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...
+1
On Thu, Jan 12, 2023 at 2:21 AM Matt Sicker
wrote:
> +1
>
> Thanks for working on this! Looks great!
>
> > On Jan 10, 2023, at 4:55 AM, Volkan Yazıcı wrote:
> >
> > The Apache Log4j Tools 0.1.0 release is now available for voting.
> >
> > The 0.1.0 version is the very first release of this r
gt;>
>> Gary
>>
>>
>>
>> On Tue, Apr 11, 2017 at 10:01 PM, Ralph Goers
>> wrote:
>>
>>> That’s a good point. It is a programmatic interface so it should return
>>> an error. But generally we want logging to do something reasonable o
2-1880
>
>> On Wed, Apr 12, 2017 at 2:18 AM, Remko Popma wrote:
>>
>> A better error message sounds like a good idea.
>> If you make a Jira ticket for this, please make it part of the
>> "ergonomics" epic: https://issues.apache.org/jira/browse/LOG4
2017 at 10:40 AM, Gary Gregory
> wrote:
>
>> On Wed, Apr 12, 2017 at 1:31 AM, Remko Popma
>> wrote:
>>
>>> I'd avoid changing the semantics of existing methods. I also favor 3.
>>> (initializeStrict?)
>>>
>>
>&g
out in left field WRT logging here... but it is still important IMO.
>
> Gary
>
>
> On Apr 12, 2017 8:19 AM, "Remko Popma" wrote:
>
> The javadoc doesn't tell the full story here, which is that the current
> method searches the classpath next if the spec
Moderated?
I noticed that the author enjoys taking strong positions on things but at
the same time finds it inconceivable that he could be wrong.
On Sat, Apr 15, 2017 at 1:00 AM, Ralph Goers
wrote:
> I’m not sure why my comment has not appeared…
>
> Ralph
>
> > On Apr 13, 2017, at 1:48 PM, Ralph
Everyone, I would love your feedback on this:
https://remkop.github.io/picocli/
https://github.com/remkop/picocli
It is heavily inspired by JCommander and Args4j but has improved
ergonomics, customizable help (with colors) and various other improvements.
I hope this will be useful in the log4j-t
ly be shaded
> into log4j-core for the CLI classes. Very nice!
>
>> On 15 April 2017 at 09:25, Remko Popma wrote:
>>
>> Everyone, I would love your feedback on this:
>>
>> https://remkop.github.io/picocli/
>> https://github.com/remkop/picocli
&
te use of this, being a single file, it could easily be
>> shaded
>> into log4j-core for the CLI classes. Very nice!
>>
>>> On 15 April 2017 at 09:25, Remko Popma wrote:
>>>
>>> Everyone, I would love your feedback on this:
>>>
>>> http
i_colors_and_styles
On Sun, Apr 16, 2017 at 8:15 Gary Gregory wrote:
> I use JCommander a lot. Can you explain the difference? Most applications I
> work on depend on other jars, so one more is no biggie.
>
> Thank you!
> Gary
>
> On Apr 15, 2017 7:25 AM, "Remko Popm
Asciidoc can include code snippets or whole files:
http://asciidoctor.org/docs/user-manual/#include-partial
I'm not convinced that it's desirable to generate the user manual from javadoc
though. They usually target different audiences so the content is different.
Sent from my iPhone
> On Apr
Asciidoc is much nicer than anything one can do in javadoc.
Sent from my iPhone
> On Apr 19, 2017, at 10:10, Gary Gregory wrote:
>
> Maybe from package level Javadocs?
>
> Gary
>
>> On Apr 18, 2017 5:56 PM, "Remko Popma" wrote:
>>
>> Asc
What other functionality could go into a potential log4j-lucene module? Is this
really a category?
We already have so many modules...
I'd prefer to add this to one of the existing modules (nosql?) or create a more
general module that we could lump other stuff in later.
Sent from my iPhone
>
I agree with Ralph that there are many environments that can't upgrade their
Java version but still want to use the nice features Log4j2 offers. I've also
worked in such environments. I would prefer to support older versions as long
as possible. (What that means concretely is open for discussion
How many new modules are we talking about, concretely?
Matt mentioned the StackOverflow questions about transitive dependencies
etc, but I imagine splitting log4j-core into 5 or more new modules will
also cause confusion... It won't be trivial for users to figure out which
of the many modules they
> to work as you can’t have multiple modules that export the same package.
>
> Ralph
>
>> On Apr 24, 2017, at 10:43 AM, Remko Popma wrote:
>>
>> How many new modules are we talking about, concretely?
>>
>> Matt mentioned the StackOverflow questions a
4j-couchdb
> - log4j-mongodb
> - log4j-lucene (new, under development)
>
>
>
>> On Mon, Apr 24, 2017 at 7:43 PM, Remko Popma wrote:
>>
>> How many new modules are we talking about, concretely?
>>
>> Matt mentioned the StackOverflow questions abou
gt;
> > > We should have consensus on the big picture here... are we all Ok with
> > the
> > > idea of all modules only having _required_ dependencies?
> > >
> > > Gary
> > >
> > > On Apr 25, 2017 6:57 AM, "Remko Popma" wrote:
>
What layout do we have available that does not require an external
dependency?
On Tue, May 2, 2017 at 8:38 PM, Mikael Ståldal
wrote:
> Given the inherent security problems with Java object serialization
> (highlighted by CVE-2017-5645), I do suggest that we deprecate
> SerializedLayout and remov
ternLayout can be configured to include all
>> information, but that's quite involved.
>>
>>> On Tue, May 2, 2017 at 4:11 PM, Remko Popma wrote:
>>>
>>> What layout do we have available that does not require an external
>>> dependency?
&
24).
>
> On Wed, May 3, 2017 at 3:44 AM, Matt Sicker wrote:
>
> > GelfLayout follows the standard from Graylog, similar in idea to the
> syslog
> > standard.
> >
> > On 2 May 2017 at 19:34, Remko Popma wrote:
> >
> > > That sounds good!
>
Yes, if you search for "ignoring" you should find a few other places where
error handling is done similarly.
(Shameless plug) Every java main() method deserves http://picocli.info
> On May 4, 2017, at 5:20, Gary Gregory wrote:
>
> The problem is that users see an exception in their log and pa
Why don't we focus on making the build faster instead of this module & repo
break-up?
We know this breakup is adding all kinds of complexity but we are only *hoping*
(not sure) that it will make the build faster.
The way I've heard Ralph and Matt describe it, the build currently requires the
String objects containing a password stay resident in memory even after being
garbage collected and can be obtained by reading the memory from an external
process.
char [] arrays are mutable so their content can be nulled out after
authentication is complete. This is not possible with String o
te:
>
>> I think we should continue to break up things into modules, but keep them
>> in the same repo.
>>
>>> On Fri, May 5, 2017 at 2:16 AM, Remko Popma wrote:
>>>
>>> Why don't we focus on making the build faster instead of this module
> Ralph
> > >>
> > >>> On May 5, 2017, at 10:13 AM, Matt Sicker wrote:
> > >>>
> > >>> It seems like it. I'm not sure if it's in release:prepare or
> > >>> release:perform.
> > >>>
> >
> Gary
>
>> On Fri, May 5, 2017 at 9:32 PM, Remko Popma wrote:
>>
>> The gitflow plugin looks promising. It seems to address the problem of the
>> tests being run twice head-on
>> <https://www.atlassian.com/blog/software-teams/maven-git-
>> flow-plu
> I have to be honest. Since I am on the Maven PMC - although I haven’t
> committed anything in years - I still have a preference for using it over
> other tools.
>
> Ralph
>
> > On May 5, 2017, at 10:07 PM, Remko Popma wrote:
> >
> > Gradle would enable you to
t; filters. That is why I created the log4j-plugins project. Then those
>> could
>>>> be released on their own cycle, separate from Log4j. Also, the jsp tag
>>>> library is in the same boat, but I’m not sure where a good home for that
>>>> would be sinc
Thinking of LOG4J2-1896, how does Apache HttpCore obtain the keystore password?
I wonder what other projects do to avoid putting a plaintext password in the
configuration.
(Shameless plug) Every java main() method deserves http://picocli.info
> On May 8, 2017, at 8:41, Gary Gregory wrote:
>
(Shameless plug) Every java main() method deserves http://picocli.info
> On May 9, 2017, at 15:35, Gary Gregory wrote:
>
> Hi All,
>
> On Mon, May 8, 2017 at 10:46 PM, Ralph Goers
> wrote:
>
>> So I keep reading up on Java modules and the more I do the more confused I
>> get about how this
> On May 22, 2017, at 5:30, Ralph Goers wrote:
>
> I’m not sure how to make it be any better than this. Although the Java 9
> classes could be removed we would just have to put them back in a couple of
> months when Java 9 is released. Putting them in a separate module is not a
> great option
then disable
> the deploy in the module. Then the new log4j-api could create the jar. But
> this all seems messier than what is there now. If you ignore the Java 9 stuff
> it should just work in the IDE.
>
> Ralph
>
>> On May 21, 2017, at 4:50 PM, Remko Popma wro
One idea: we could move (actually copy) the StackLocator interface to the
Java 9 module.
This allows us to build the Java 9 module first. Then, when building the
log4j-api module, the Java 9 classes can be shaded into the log4j-api jar
(excluding StackLocator since we want to compile that interface
I like log4j-samples better than log4j-server for the same reasons that Mikael
and Ralph mentioned. True, it has already been released, but the module breakup
gives us a chance to clarify our intentions.
(Shameless plug) Every java main() method deserves http://picocli.info
> On May 31, 2017,
Thanks for doing this work, Ralph!
Remko
(Shameless plug) Every java main() method deserves http://picocli.info
> On May 31, 2017, at 8:54, Ralph Goers wrote:
>
> At the request of Scott Deboy I have migrated chainsaw to git. You can view
> it at https://github.com/apache/logging-chainsaw
> <
Oleg,
Elements in the Log4j configuration can be instrumented with MBeans to
allow remote inspection and modification of an application's logging
configuration. As Matt pointed out, this can be disabled.
There is no dependency on RMI as far as I know. There is a log4j-jmx-gui
client module that c
On Thu, Jun 1, 2017 at 1:18 AM, Remko Popma wrote:
> Oleg,
>
> Elements in the Log4j configuration can be instrumented with MBeans to
> allow remote inspection and modification of an application's logging
> configuration. As Matt pointed out, this can be disabled.
>
> Ther
https://issues.apache.org/jira/browse/LOG4J2-1926 for this (with
you as the reporter).
Please feel free to modify that ticket if it is incomplete or incorrect.
Remko
On Thu, Jun 1, 2017 at 1:57 AM, Oleg Kalnichevski wrote:
> On Thu, 2017-06-01 at 01:18 +0900, Remko Popma wrote:
api works smoothly on Android.
>
>
>> On 2017-05-31 19:57, Oleg Kalnichevski wrote:
>>> On Thu, 2017-06-01 at 01:18 +0900, Remko Popma wrote:
>>> Oleg,
>>>
>>> Elements in the Log4j configuration can be instrumented with MBeans
>>> to
Ralph, thank you!!
I just tried it and it works great. All I needed to do was tell IntelliJ
IDEA to use Java 9 for the log4j-api-java9 module and it all just works in
the IDE again.
Great, thanks again!
Remko
On Mon, Jun 19, 2017 at 4:39 AM, Ralph Goers
wrote:
> I have modified the Java 9 sup
I'm on Windows but haven't seen it.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Jun 19, 2017, at 16:24, Mikael Ståldal wrote:
>
> Has anyone else seen this failure? On something else than Windows?
>
>
>> On 2017-06-05 21:21, Gary Gregory wrote:
>> Hi All,
>> T
301 - 400 of 595 matches
Mail list logo
