Re: [Log4j] log4j-server

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 skip the clean, so only the necessary classes are

Re: [Log4j] log4j-server

Gradle would enable you to skip the clean, so only the necessary classes are compiled before the tests are run. Much faster. You'll love it. Agreed that RM's job should be #1 priority. (Shameless plug) Every java main() method deserves http://picocli.info > On May 6, 2017, at 13:40, Gary Gre

Re: [Log4j] log4j-server

For normal development I run Eclipse. I run mvn clean install before I commit anything non-trivial. So whether I do that in last step in Maven or Gradle is the same to me. The RM's job should be #1 consideration IMO. Gary On Fri, May 5, 2017 at 9:32 PM, Remko Popma wrote: > The gitflow plugi

Re: [Log4j] log4j-server

The gitflow plugin looks promising. It seems to address the problem of the tests being run twice head-on : > >- Only builds your project once in the finish goal. e.g. if you do >release-start and rele

Re: Type of org.apache.logging.log4j.core.net.ssl.StoreConfiguration.password

Tracking here: https://issues.apache.org/jira/browse/LOG4J2-1896 Gary On Fri, May 5, 2017 at 12:46 PM, Matt Sicker wrote: > I agree with using char[] for this due to the overwriting of contents that > Remko explained. Here's a neat Stack Overflow post to back us up: > https://stackoverflow.com/

[jira] [Created] (LOG4J2-1896) Update org.apache.logging.log4j.core.net.ssl.StoreConfiguration from a String to char[] to represent its password

Gary Gregory created LOG4J2-1896: Summary: Update org.apache.logging.log4j.core.net.ssl.StoreConfiguration from a String to char[] to represent its password Key: LOG4J2-1896 URL: https://issues.apache.org/jira/br

[jira] [Updated] (LOG4J2-1896) Update org.apache.logging.log4j.core.net.ssl.StoreConfiguration from a String to char[] to represent its password

[ https://issues.apache.org/jira/browse/LOG4J2-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-1896: - Summary: Update org.apache.logging.log4j.core.net.ssl.StoreConfiguration from a String to char[]

Re: [OT] Java 9 modules drama

On Fri, May 5, 2017 at 1:58 PM, Ralph Goers wrote: > A response from RedHat - http://mail.openjdk.java.net/ > pipermail/jpms-spec-experts/2017-May/000690.html < > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/ > 2017-May/000690.html>. > Quite sensitive it seems. Gary > > Ralph > >

Re: [OT] Java 9 modules drama

My take on a higher level is that Java 9 should be released without Jigsaw and make sure all the toolchains work out of the box, Maven, Gradle, and so on. Java 9 modules smell of NIH and if I really want modules today there are solutions out there: OSGi with many implementations, JBoss Modules, and

Re: [OT] Java 9 modules drama

A response from RedHat - http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000690.html . Ralph > On May 5, 2017, at 1:49 PM, Ralph Goers wrote: > > Wow. He is basically saying that Java 9 with the m

Re: [OT] Java 9 modules drama

Wow. He is basically saying that Java 9 with the module system is going to be released whether or not the expert group approves it or not. I also noticed that the link to the Maven core developers responses immediately followed the response of Stephen Colebourne who flatly said auto modules won’

[OT] Java 9 modules drama

FYI: http://mreinhold.org/blog/to-the-jcp-ec Gary

Re: Java 9, 8, 7 and Eclipse

All those compiler passes and rules and whatnot make me think that a Makefile or Ant build would be just as simple now. :P On 5 May 2017 at 01:34, Gary Gregory wrote: > On Thu, May 4, 2017 at 10:32 PM, Gary Gregory > wrote: > > > Ah, I had Java 9. I set JAVA_HOME to Java 8 and it's off and runn

Re: Type of org.apache.logging.log4j.core.net.ssl.StoreConfiguration.password

I agree with using char[] for this due to the overwriting of contents that Remko explained. Here's a neat Stack Overflow post to back us up: https://stackoverflow.com/questions/8881291/why-is-char-preferred-over-string-for-passwords On 5 May 2017 at 04:50, Remko Popma wrote: > String objects con

[jira] [Commented] (LOG4J2-1895) Potential data race about ArrayList

[ https://issues.apache.org/jira/browse/LOG4J2-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15998862#comment-15998862 ] Matt Sicker commented on LOG4J2-1895: - Aren't those all unit tests? Although I wonder

Re: [Log4j] log4j-server

Yeah, it seems a bit easier to try experimenting with different Maven plugins first before going all in on Gradle or something else. On 5 May 2017 at 13:26, Ralph Goers wrote: > We could try using the maven gitflow plugin instead of the release plugin. > > Ralph > > > On May 5, 2017, at 11:22 AM

Re: [Log4j] log4j-server

We could try using the maven gitflow plugin instead of the release plugin. Ralph > On May 5, 2017, at 11:22 AM, Gary Gregory wrote: > > Is it possible to do mvn test and then the rest with -DskipTests? > > G > > On May 5, 2017 11:11 AM, "Ralph Goers" wrote: > >> Probably both. >> >> Ralph

Re: [Log4j] log4j-server

Is it possible to do mvn test and then the rest with -DskipTests? G On May 5, 2017 11:11 AM, "Ralph Goers" wrote: > Probably both. > > 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. > > > > O

Re: [Log4j] log4j-server

Probably both. 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. > > On 5 May 2017 at 12:12, Gary Gregory wrote: > >> Are the tests run 3 times from within the same mvn call? >> >> Gary >> >> On May

Re: [Log4j] log4j-server

It seems like it. I'm not sure if it's in release:prepare or release:perform. On 5 May 2017 at 12:12, Gary Gregory wrote: > Are the tests run 3 times from within the same mvn call? > > Gary > > On May 5, 2017 5:54 AM, "Remko Popma" wrote: > > > I don't oppose breaking things up into modules, bu

Re: [Log4j] log4j-server

Are the tests run 3 times from within the same mvn call? Gary On May 5, 2017 5:54 AM, "Remko Popma" wrote: > I don't oppose breaking things up into modules, but I'm not sure that we > want to move modules into separate repos: I've seen this in practice at > work and I worry we'll end up with a

Re: [Log4j] log4j-server

Gradle could be faster for development purposes as well as it implements the incremental compilation feature far better than Maven does. In fact, I almost never have to run "gradle clean", but "mvn clean" is a common necessity. On 5 May 2017 at 09:37, Ralph Goers wrote: > I don’t know that switc

Re: Bogus GitHub repository

Quite likely since it's not on the list here: https://git.apache.org/ On 5 May 2017 at 10:47, Mikael Ståldal wrote: > Maybe they only deleted the Git repo at Apache? > > On Fri, May 5, 2017 at 4:08 PM, Matt Sicker wrote: > > > I could have sworn I asked infra to delete that already. Guess we ne

Re: Bogus GitHub repository

Maybe they only deleted the Git repo at Apache? On Fri, May 5, 2017 at 4:08 PM, Matt Sicker wrote: > I could have sworn I asked infra to delete that already. Guess we need a > new jira ticket for it. > > On 5 May 2017 at 08:33, Mikael Ståldal wrote: > > > We still have this bogus repository on

Re: [Log4j] log4j-server

I don’t know that switching from Maven to Gradle or something else is going to solve anything. The issue isn’t Maven but how the release plugin works. If we could disable surefire during the actual release pass that would go a long way. Ralph > On May 5, 2017, at 7:33 AM, Matt Sicker wrote: >

Re: [Log4j] log4j-server

I'd be open to using Gradle if it simplifies the build system in general and especially brings speed improvements. I mostly use Gradle at work (also starting to use SBT with Scala projects, but that remains to be seen if we'll switch back to Gradle or not), and it's been pretty fast there. As I've

Re: Bogus GitHub repository

I could have sworn I asked infra to delete that already. Guess we need a new jira ticket for it. On 5 May 2017 at 08:33, Mikael Ståldal wrote: > We still have this bogus repository on GitHub: https://github.com/ > apache/logging--log4j-boot > > (note duplicate dashes) > > Can we remove it? > > T

Bogus GitHub repository

We still have this bogus repository on GitHub: https://github.com/ apache/logging--log4j-boot (note duplicate dashes) Can we remove it? The corresponding Git repo at Apache seems to be gone already. -- [image: MagineTV] *Mikael Ståldal* Senior software developer *Magine TV* mikael.stal...@ma

Re: [Log4j] log4j-server

Then I think we agree. I am open to change build tool to e.g. Gradle if that makes things easier and faster for us. On Fri, May 5, 2017 at 2:53 PM, Remko Popma wrote: > I don't oppose breaking things up into modules, but I'm not sure that we > want to move modules into separate repos: I've seen

Re: [Log4j] log4j-server

I don't oppose breaking things up into modules, but I'm not sure that we want to move modules into separate repos: I've seen this in practice at work and I worry we'll end up with a very complicated build. Are we open to the idea of using a different build tool that supports incremental builds

Re: [Log4j] log4j-server

Given the quite heavy release process we have, adding more repos adds quite a lot of manual administrative overhead for us. This is a problem since it steals time from actual development, and may also cause developers to be demotivated and eventually abandon the project. On Thu, May 4, 2017 at 6

Re: [Log4j] log4j-server

True. But it was deemed to be unacceptable to require Java 8 for the build of the main repo before we added support (and thus build requirement) for Java 9 there. On Thu, May 4, 2017 at 8:53 PM, Matt Sicker wrote: > The log4j-core repo requires Java 9 to build, so I don't see that Java 8 > limi

Re: [Log4j] log4j-server

...but the main reason for breaking up into modules is not build speed. On Fri, May 5, 2017 at 9:40 AM, Mikael Ståldal wrote: > 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

[jira] [Created] (LOG4J2-1895) Potential data race about ArrayList

yangxin created LOG4J2-1895: --- Summary: Potential data race about ArrayList Key: LOG4J2-1895 URL: https://issues.apache.org/jira/browse/LOG4J2-1895 Project: Log4j 2 Issue Type: Bug Compone

Re: Type of org.apache.logging.log4j.core.net.ssl.StoreConfiguration.password

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

[jira] [Created] (LOG4J2-1894) Potential data race in ReconfigurationDeadlockTest

yangxin created LOG4J2-1894: --- Summary: Potential data race in ReconfigurationDeadlockTest Key: LOG4J2-1894 URL: https://issues.apache.org/jira/browse/LOG4J2-1894 Project: Log4j 2 Issue Type: Bug

Re: Timing tasks

Removed duplicate Timer class. On Tue, May 2, 2017 at 1:58 PM, Mikael Ståldal wrote: > Why is this class duplicated? Can't we remove the one in log4j-core? > > On Tue, May 2, 2017 at 4:59 AM, Ralph Goers > wrote: > >> We have had this since I started log4j. It is in both core and api as >> Tim

Re: Type of org.apache.logging.log4j.core.net.ssl.StoreConfiguration.password

OK. On Fri, May 5, 2017 at 10:33 AM, Gary Gregory wrote: > Subclasses can still make the same mistake as long as it is a String. It is > just something I consider good practice. > > Gary > > On May 5, 2017 1:30 AM, "Mikael Ståldal" > wrote: > > > What about a custom implementation of StoreConfi

Re: Type of org.apache.logging.log4j.core.net.ssl.StoreConfiguration.password

Subclasses can still make the same mistake as long as it is a String. It is just something I consider good practice. Gary On May 5, 2017 1:30 AM, "Mikael Ståldal" wrote: > What about a custom implementation of StoreConfiguration.toString which > does not include the password? > > On Fri, May 5,

Re: Type of org.apache.logging.log4j.core.net.ssl.StoreConfiguration.password

What about a custom implementation of StoreConfiguration.toString which does not include the password? On Fri, May 5, 2017 at 10:28 AM, Gary Gregory wrote: > Usually toString on an object that includes a password String can end up in > places like logs that it should not be. A char[] toString do

Re: Type of org.apache.logging.log4j.core.net.ssl.StoreConfiguration.password

Usually toString on an object that includes a password String can end up in places like logs that it should not be. A char[] toString does not display its contents. Gary On May 5, 2017 12:41 AM, "Mikael Ståldal" wrote: > What are those security reasons? > > On Fri, May 5, 2017 at 2:06 AM, Gary

Re: Type of org.apache.logging.log4j.core.net.ssl.StoreConfiguration.password

What are those security reasons? On Fri, May 5, 2017 at 2:06 AM, Gary Gregory wrote: > Hi, > > I think I'd like to change the type > of org.apache.logging.log4j.core.net.ssl.StoreConfiguration.password from > String to char[] for the usual security reason. > > Thoughts? > > Gary > > -- > E-Mail:

Re: [Log4j] log4j-server

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 & > repo break-up? > > We know this breakup is adding all kinds of complexity but