Re: [log4j] clarify "internal" vs exported packages in core - plugin API

If you want I can create a “release-2.11” or “release-2.x” branch from that commit. > On Jan 30, 2018, at 14:17, Remko Popma wrote: > > I think it’s possible to search for a commit hash in IntelliJ, but here is a > github link: >

Re: [log4j] clarify "internal" vs exported packages in core - plugin API

I think it’s possible to search for a commit hash in IntelliJ, but here is a github link: https://github.com/apache/logging-log4j2/commit/21bc3aa3bf8d8a043459c6a58e774b82a617a058 LOG4J2-2225 provide alias for SystemMillisClock so the fully qualifie… …d class name doesn't need to be published

Re: [log4j] clarify "internal" vs exported packages in core - plugin API

I agree in principal but I am having a hard time figuring out which commit that was. Ralph > On Jan 29, 2018, at 4:19 PM, Remko Popma wrote: > > Any feedback on the idea to cut a branch from commit 21bc3aa and release > 2.11 from that branch? > > In the release notes

Re: [log4j] clarify "internal" vs exported packages in core - plugin API

Fine with me either way. The earlier we release something, the better, for me ;-) Gary On Jan 29, 2018 16:20, "Remko Popma" wrote: > Any feedback on the idea to cut a branch from commit 21bc3aa and release > 2.11 from that branch? > > In the release notes we can announce

Re: [log4j] clarify "internal" vs exported packages in core - plugin API

Any feedback on the idea to cut a branch from commit 21bc3aa and release 2.11 from that branch? In the release notes we can announce that the next release will have internal classes moved and packages renamed so future releases will have binary compatibility issues. To me it makes sense to

Re: [log4j] The shape of Log4j

On Mon, Jan 29, 2018 at 2:39 PM, Matt Sicker wrote: > On 29 January 2018 at 13:10, Gary Gregory wrote: > > > > Speaking of java.sql (and javax.sql): How can we get the Maven build to > > FAIL if log4-core Java codes uses java[x].sql code? > > > > I'm

Re: Java 8

I will fix picocli before we get to that point. (Shameless plug) Every java main() method deserves http://picocli.info > On Jan 30, 2018, at 4:07, Gary Gregory wrote: > >> On Mon, Jan 29, 2018 at 11:07 AM, Remko Popma wrote: >> >> The log4j-api

Re: [log4j] The shape of Log4j

On 29 January 2018 at 13:10, Gary Gregory wrote: > > Speaking of java.sql (and javax.sql): How can we get the Maven build to > FAIL if log4-core Java codes uses java[x].sql code? > I'm not sure if there are any Maven plugins for enforcing this yet, but I'd imagine it'd be

Re: [log4j] org.apache.logging.log4j.core.appender.mom.jeromq move?

On 29 January 2018 at 10:05, Gary Gregory wrote: > How does this relate our use of OSGi "Fragment-Host" in jar files? > I'm not so sure. My OSGi experience in the past revolved around proper bundles mostly which didn't require these weird hacks. Ideally, log4j-core

Re: [log4j] The shape of Log4j

On 29 January 2018 at 15:04, Gary Gregory wrote: > > Those two are done in git master. > Thanks! > How would we deal with dependencies on Apache Commons Compress for example? > Just slice and dice the code to minimize the code depending on CC and put > that in a new

Re: [log4j] Jenkins info

Those filters were put in place a while back to prevent certain experimental Jenkins hosts from being used. Labels were given by Infra after asking about weird build failures in the past. They might not be relevant anymore, though. On 29 January 2018 at 14:59, Gary Gregory

Re: [log4j] org.apache.logging.log4j.core.appender.mom.jeromq move?

On Sun, Jan 28, 2018 at 9:17 PM, Gary Gregory wrote: > Beyond these moves, the next slice and dice would be to deal with our XML, > JSON, and YAML dependencies: > > We have no dependencies to read an XML configuration. > > For JSON and YAML configs, we use Jackson. > >

Re: [log4j] The shape of Log4j

On Sat, Jan 27, 2018 at 3:07 PM, Matt Sicker wrote: > Moving the Kafka and ZeroMQ appenders to their own modules sounds like a > good start! Appenders that require third party plugins seem to be a great > candidate for splitting into their own modules. > Those two are done in

[log4j] Jenkins info

Hi All: Our build is on !jenkins-cloud-4GB&&(ubuntu)&&!(ubuntu-eu2) ) What does that mean and why? Gary

Re: [log4j] The shape of Log4j

On Mon, Jan 29, 2018 at 7:20 AM, Gary Gregory wrote: > > > On Sun, Jan 28, 2018 at 9:35 PM, Matt Sicker wrote: > >> That's rather limiting. Here's what we're already using: >> >> * java.compiler: annotation processing (could potentially be split, but >>

Re: Java 8

On Mon, Jan 29, 2018 at 11:07 AM, Remko Popma wrote: > The log4j-api module could benefit from a util.internal package where we > move the util classes that are private and should not be exported. > Potentially an idea for a 3.0 release. > > (Shameless plug) Every java

Re: Java 8

The log4j-api module could benefit from a util.internal package where we move the util classes that are private and should not be exported. Potentially an idea for a 3.0 release. (Shameless plug) Every java main() method deserves http://picocli.info > On Jan 30, 2018, at 2:41, Remko Popma

Re: Java 8

If we want to do a 2.11 release that is binary compatible, I believe that commit 21bc3aa is the last commit to include. >From the following commit (ba658a0) we start to move classes and rename packages - this would better fit in a 3.0 release where users would expect some breaking changes in

Re: Java 8

An SPI for log4j-core is one thing (also plugin factory cleanup). I'd like to see an improved plugin cache file that doesn't require a special plugin to merge them together when shading jars (would be better to just be cat'd together like a META-INF/services/ file). Removal of deprecated APIs

Re: Java 8

I am neutral about moving to Java 8 soon. We have just recently started to make a lot of package rename changes that really belong in 3.0 and not in 2.11... We should consider doing a 2.11 release from a commit before we started to rename packages. Then doing the modules split-off and clarifying

Re: Java 8

On Mon, Jan 29, 2018 at 10:27 AM, Gary Gregory wrote: > On Mon, Jan 29, 2018 at 10:24 AM, Matt Sicker wrote: > >> I'd be +1 for Java 8, but making a 3.0 release is a different story. For >> that, I'd like to see a lot more than just the Java version

Re: Java 8

On Mon, Jan 29, 2018 at 10:24 AM, Matt Sicker wrote: > I'd be +1 for Java 8, but making a 3.0 release is a different story. For > that, I'd like to see a lot more than just the Java version increase. > I think that a 3.0 would mark: - A major change: Java 7 to Java 8 - The

Re: [log4j] The shape of Log4j

JNDI is used in log4j-web for being able to locate a LoggingContext or configuration (forget which), and there's a JNDI lookup in log4j-core. Might be other places, but those are the main ones I can remember. Essentially, anything that relies on javax.* other than for some select crypto and

Re: [log4j] clarify "internal" vs exported packages in core - plugin API

I agree with Ralph. We can still do this. Maybe we should start a 2.11 branch from an earlier commit, from before we started to rename packages, and cut a 2.11 release from that branch? On Tue, Jan 30, 2018 at 2:08 AM, Ralph Goers wrote: > If are going to call it 3.0

Re: [log4j] clarify "internal" vs exported packages in core - plugin API

If are going to call it 3.0 I would have liked to cut a release before all this modularization work and then created a branch so we could maintain it if necessary. Ralph > On Jan 29, 2018, at 10:04 AM, Gary Gregory wrote: > > On Mon, Jan 29, 2018 at 8:17 AM, Remko

Re: Java 8

+1 to Java 8 now and call the next release 3.0. Gary On Mon, Jan 29, 2018 at 10:03 AM, Ralph Goers wrote: > Ceki has started a poll to upgrade Logback to Java 8 - > https://doodle.com/poll/s7n3wk59694pmnbs s7n3wk59694pmnbs>. The last

Re: [log4j] org.apache.logging.log4j.core.appender.mom.jeromq move?

I should note that if we decide to keep things in core, like XML, they can be declared as transient (making the dependency optional) in the module-info.java file. For me the goal is to have log4j-core contain what 80% of our users want. I suspect both JSON and XML fall into that. Ralph > On

Re: [log4j] org.apache.logging.log4j.core.appender.mom.jeromq move?

I don’t know enough about OSGi to answer that. Ralph > On Jan 29, 2018, at 9:05 AM, Gary Gregory wrote: > > How does this relate our use of OSGi "Fragment-Host" in jar files? > > IOW, and for example, do I still to need to declare "Fragment-Host" in > log4j-cassandra

[log4j] clarify "internal" vs exported packages in core - plugin API

If we are going to make breaking changes in this release it may be wise to also do any package renaming in this release to keep the disruption limited to a single release instead of multiple. Specifically, I propose we take this release to do all package renaming to clarify the difference between

Re: logging-log4j2 git commit: In-line mutable local vars.

On Mon, Jan 29, 2018 at 7:39 AM, Remko Popma wrote: > I actually coded it this way deliberately. > The local variables clarify the intention and make the code self > documenting. Without the variable the reader needs to spend effort to > understand the calculation on the

Re: [log4j] org.apache.logging.log4j.core.appender.mom.jeromq move?

I haven’t looked yet but make sure the new module dependencies are added to Log4J-distribution. Ralph > On Jan 29, 2018, at 6:55 AM, Gary Gregory wrote: > > On Sun, Jan 28, 2018 at 7:38 PM, Gary Gregory > wrote: > >> >> >> On Sun, Jan 28,

Re: [log4j] The shape of Log4j

On Sun, Jan 28, 2018 at 9:35 PM, Matt Sicker wrote: > That's rather limiting. Here's what we're already using: > > * java.compiler: annotation processing (could potentially be split, but > this situation is already confusing enough for users) > * java.management: JMX > *

Re: [log4j] The shape of Log4j

On Sun, Jan 28, 2018 at 9:54 PM, Ralph Goers wrote: > I didn’t realize that java.base was that limited. Are these all required > at run time or only build? For example, the annotation processor is not > used when log4j is running so I would suspect it is required to

Re: Soliciting input: ElasticSearch receiver

And that will be in a new module ;-) Gary On Sat, Jan 27, 2018 at 6:47 PM, Matt Sicker wrote: > On the sending side, we'd want to be able to configure index name, mapping > type name, override mapping settings, bulk request (i.e., batch) size, > refresh interval overrides,

Re: [log4j] org.apache.logging.log4j.core.appender.mom.jeromq move?

On Sun, Jan 28, 2018 at 7:38 PM, Gary Gregory wrote: > > > On Sun, Jan 28, 2018 at 2:25 PM, Ralph Goers > wrote: > >> I should add that each module must have a unique package hierarchy so, in >> general, the package names should be

Re: [log4cxx] Current State

Guten Tag Matt Sicker, am Dienstag, 23. Januar 2018 um 20:31 schrieben Sie: > Could you include the fingerprint? Isn't that the following line in the file already? > Schl.-Fingerabdruck = A468 E054 E594 9AC5 8FA7 5A0E F649 2CB4 778C 3033 > Also, that site is timing out for me at > the moment.