of what I've been working on for
> > the
> > > past several months have all been Mesos-managed containers, so startup
> > has
> > > been mostly delegated to environment variables for configuration).
> > >
> > > The autocomplete feature sou
None
> of them have it which is why I ended up creating
> https://github.com/garydgregory/jcommander-addons/blob/master/README.md
>
> This is a pain because I should not need two libraries to cover the JRE.
>
> If you want this kind of stuff for you library, let me know...
>
>
I created https://issues.apache.org/jira/browse/LOG4J2-2011 for this.
On Thu, Aug 10, 2017 at 8:29 Remko Popma wrote:
> Hi Gary,
>
> Love the add-ons. Definitely interested.
> Let me ping you offlist to see how we can collaborate on this.
>
> Remko
>
> On Wed, Aug 9, 2
Picocli is designed to be included as source with minimal impact. That's why
it's a single source file.
Users should not have to specify a command line parser library jar just to run
our Log4j2 utility applications.
> On Aug 15, 2017, at 2:06, Matt Sicker wrote:
>
> Embedding a single clas
Thank you for retracting your -1, Gary.
All,
Would core.tools be a better place for this package, just core, or is
core.util okay?
On Tue, Aug 15, 2017 at 3:03 AM, Gary Gregory
wrote:
> Can we please avoid "util" packages, that just tells me "I can't be
> bothered to think of a good name". Just
OK, I will move them to core.tools.
On Wed, Aug 16, 2017 at 4:32 AM, Matt Sicker wrote:
> I kind of consider the tools package for command line tools, so it sorta
> does make sense to include the command line parser in the same package.
>
> On 14 August 2017 at 17:36, Remko
Gary, the change you propose in the LOG4J2-1888 branch look good to me.
Should be fine to merge.
On Tue, Aug 15, 2017 at 7:20 AM, ASF subversion and git services (JIRA) <
j...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/LOG4J2-1888?page=
> com.atlassian.jira.plugin.system.i
I like the idea of having it as a parameter to ConsoleAppender, that would
make it easy for users to find.
No problem changing the default behaviour to not using Jansi.
Do we still retain the current system property with its current semantics
(so setting skipJansi=false would also enable colorize
I like the idiom where setter methods return `this`, so users can chain
methods; thanks for making that change.
On Fri, Aug 18, 2017 at 5:41 AM, Gary Gregory
wrote:
> Hi All and FYI:
>
> I plan on redoing the SocketOptions class as a real builder by making all
> accessors return this.
>
> Any o
r 3.0 I think.
>
> Gary
>
>> On Thu, Aug 17, 2017 at 4:10 PM, Remko Popma wrote:
>>
>> I like the idiom where setter methods return `this`, so users can chain
>> methods; thanks for making that change.
>>
>>
>> On Fri, Aug 18, 2017 at
No objection to creating logger names from Class.getCanonicalName() instead
of Class.getName(). I assume that this means we don't need a custom
toLoggerName(Class)
method.
Question for our Scala experts: does Class.getCanonicalName() preserve the
trailing $ in Scala classes?
At some point there w
Jenkins may be using an old Java 9:
JDK[/home/jenkins/tools/java/jigsaw-jdk-9-ea-b156]
Also, it seems this method was previously called `getPid`. It must have
been renamed recently.
http://www.javaworld.com/article/3176874/java-language/java-9s-other-new-enhancements-part-3.html
On Mon, Aug 21,
Yes, renamed in build 166 apparently.
https://bugs.openjdk.java.net/browse/JDK-8178347
On Mon, Aug 21, 2017 at 13:40 Remko Popma wrote:
> Jenkins may be using an old Java 9:
>
> JDK[/home/jenkins/tools/java/jigsaw-jdk-9-ea-b156]
>
> Also, it seems this method was previously call
gt;
>> The only change I am now talking about is replacing getName() with
>> getCannonicalName().
>>
>> Gary
>>
>>> On Aug 19, 2017 18:00, "Remko Popma" wrote:
>>>
>>> No objection to creating logger names from Class.getCanon
rom "set" to "with" now?
>
> Gary
>
>> On Thu, Aug 17, 2017 at 4:21 PM, Remko Popma wrote:
>>
>> That's fine I think.
>>
>> (Shameless plug) Every java main() method deserves http://picocli.info
>>
>>> On Aug 18, 20
What I don't like about this proposal is that LogManager.getLogger(Class)
would end up working differently than
o.a.l.l.core.LoggerContext.getLogger(Class). (One uses Class.getName, the
other Class.getCanonicalName.)
Why not just use org.apache.logging.log4j.core.
LoggerContext.getLogger(clazz.get
> On Aug 23, 2017, at 2:22, Gary Gregory wrote:
>
>> On Tue, Aug 22, 2017 at 10:27 AM, Remko Popma wrote:
>>
>> What I don't like about this proposal is that LogManager.getLogger(Class)
>> would end up working differently than
>> o.a.l.l.core.
+1
Tested with
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-11T01:41:47+09:00)
Maven home: C:\apps\apache-maven-3.3.9\bin\..
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: C:\apps\jdk1.8.0_131\jre
Default locale: en_US, platform encoding: MS932
OS name: "wi
If anyone has a script for recursively checking the checksums of a directory
tree I'd be much obliged.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Aug 30, 2017, at 14:36, Ralph Goers wrote:
>
> Here is my +1
>
> Ralph
>
>> On Aug 26, 2017, at 7:45 PM, Ralph G
e 1 has passed with
> +1 votes from Gary Gregory, Matt Sicker, Mikael Ståldal, Remko Popma, and
> Ralph Goers. No other votes were cast.
>
> I will continue with the release process.
>
> Ralph
Blogged: https://blogs.apache.org/logging/entry/log4j-2-9-released
(Shameless plug) Every java main() method deserves http://picocli.info
> On Aug 31, 2017, at 9:26, Ralph Goers wrote:
>
> The Apache Log4j 2 team is pleased to announce the Log4j 2.9.0 release!
>
> Apache Log4j is a well known
log4j-container?
(To be more generic than javaee)
> On Sep 7, 2017, at 4:56, Ralph Goers wrote:
>
> Yes, the intent would be to allow containers to use Log4j as their logging
> implementation.
>
> Ralph
>
>> On Sep 6, 2017, at 12:26 PM, Mikael Ståldal wrote:
>>
>> Is the point to integrate
On Sep 7, 2017, at 7:39, Gary Gregory wrote:
>
> The word container is so vague... container of what? Files, Applications,
> NoSQL things? How about app-container?
>
> Gary
>
>> On Wed, Sep 6, 2017 at 4:07 PM, Remko Popma wrote:
>>
>> log4j-container?
>>
n could enforce that all arguments
>> passed into a log event must be limited to immutable primitive types. In
>> this mode deadlocks could no longer occur because rogue recursions would
>> actively prevented.
>>
>> On 10 Sep 2017 3:43 p.m., "Remko Popma (JIRA
I've looked at this before but couldn't figure it out. I'll take another look.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Sep 12, 2017, at 9:00, Matt Sicker wrote:
>
> I'm pretty sure I've seen that failure (or something similar at least)
> several times before
Isn't it the opposite? Giving them the same module name will prevents them from
being used together, which is what we want:
http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html?m=1
"JPMS will simply refuse to start a modulepath where two modules have the same
name, even if they contain
I'll try to put in a fix for
https://issues.apache.org/jira/browse/LOG4J2-1988?filter=-1
(java.util.ConcurrentModificationException with AsyncLogger?) today.
Stretch goal: https://issues.apache.org/jira/browse/LOG4J2-2031 (Messages
appear out of order in log file (was: Log4j2 log file not refl
+1
Builds fine, checksums good.
On Mon, Sep 18, 2017 at 4:07 PM, Ralph Goers
wrote:
> This is a vote to release Log4j 2.9.1, the next version of the Log4j 2
> project.
>
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't rele
I started writing the blog post for 2.9.1.
Quick question: no changes to the announcement text this time, is that
correct?
On Thu, Sep 21, 2017 at 1:12 PM, Ralph Goers
wrote:
> My +1
>
> Ralph
>
> > On Sep 18, 2017, at 12:07 AM, Ralph Goers
> wrote:
> >
> > This is a vote to release Log4j 2.9.1
Ralph,
Would it be possible to include the new wording in the 2.9.1 announcement email?
Remko
> On Sep 22, 2017, at 7:17, rpo...@apache.org wrote:
>
> Repository: logging-log4j2
> Updated Branches:
> refs/heads/master 3f5d58cd3 -> 8b5d644d5
>
>
> Fix wording of 2.9.1 change item (LOG4J2-20
was
never released)."?
(Shameless plug) Every java main() method deserves http://picocli.info
> On Sep 22, 2017, at 8:06, Ralph Goers wrote:
>
> I changed it some, yes.
>
> Ralph
>
>> On Sep 21, 2017, at 2:55 PM, Remko Popma wrote:
>>
>> I started wri
Blogged:
https://blogs.apache.org/logging/entry/log4j-2-9-1-released
(Shameless plug) Every java main() method deserves http://picocli.info
> On Sep 22, 2017, at 9:32, Ralph Goers wrote:
>
> As of Log4j 2.9.0, the Log4j API was modified to use java.util.ServiceLoader
> to locate Log4j impleme
That's certainly possible.
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 wrote:
>
> In looking at the implementations
be honest, item 1 is the one I find more appealing. It reminds me of how
> OS/2’s support for Windows was not what people really wanted vs the way
> Windows NT handled it.
>
> Ralph
>
>> Begin forwarded message:
>>
>> From: Remko Popma
>> Subject: R
> is now at 1.1.11 and 1.2.3. I am not really clear on what is different
> between 1.1.x and 1.2.x.
>
> Ralph
>
>> On Sep 24, 2017, at 9:50 PM, Remko Popma wrote:
>>
>> Ok I see now.
>> It would certainly be good to have more ammunition to argue for u
Thanks for reviewing.
Good catch, a null check is needed to prevent NPEs.
But null passwords are possible so perhaps make it like this:
return password == null ? null : password.toCharArray();
> On Sep 26, 2017, at 1:08, Gary Gregory wrote:
>
>> On Mon, Sep 25, 2017 at 10:00 AM, wrote:
>>
Sounds to me that Ralph's analysis shows that doing the binding ourselves may
not be worth doing since we can't get an advantage by either improving people's
perception nor improve performance. Unless I'm missing something.
> On Sep 26, 2017, at 16:34, Mikael Ståldal wrote:
>
> I don't thin
I think that's a good idea. (I really wish we could have fewer duplicate emails
though.)
Remko
> On Oct 13, 2017, at 6:59, Dominik Psenner wrote:
>
> Stuff that requires human intervention should stay prominent. The rest can
> go away. :-)
>
> 2017-10-12 23:06 GMT+02:00 Ralph Goers :
>
>> I
We don't have much choice I think.
As Ralph pointed out, we have to change the default value as it can cause
application startup to fail...
> On Oct 13, 2017, at 4:25, Gary Gregory wrote:
>
> My preference is to leave it as. The 2nd option is to add jansi=true|false
> to the ConsoleAppender
You mean we may want to do something like this in the future?
module org.apache.logging.log4j {
exports org.apache.logging.log4j;
exports org.apache.logging.log4j.message;
exports org.apache.logging.log4j.simple;
exports org.apache.logging.log4j.spi;
exports org.apache.logging.
My bad.
On Wed, Oct 18, 2017 at 12:22 AM, wrote:
> Repository: logging-log4j2
> Updated Branches:
> refs/heads/master ff5e664cd -> 247c91d01
>
>
> Revert "LOG4J2-2060 AbstractDatabaseManager should make a copy of
> LogEvents before holding references to them: AsyncLogger log events are
> mutab
I agree with Gary: this is just another Layout. Should not need another
repo...
Prototyping on another branch makes sense.
On Fri, Oct 20, 2017 at 1:23 AM, Gary Gregory
wrote:
> Bleh, ANOTHER repo? We have so many already... but I see what the big
> picture is. Would this add a new layout in Cor
The error went away on my machine and the Jenkins build started passing after
reverting back to 3.2.18.RELEASE
> On Oct 24, 2017, at 4:51, Ralph Goers wrote:
>
> OK. So I am guessing that the errors are happening on a unit test that uses
> Spring’s mock classes and those were upgraded in 4.
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:
>
> Can you use the new system property naming scheme? This would be
> log4j2.skipJansi. That property would work regardless wit
directly related to the Jansi library.
> On Oct 25, 2017, at 4:40, Mikael Ståldal wrote:
>
> If we are going to rename it, I would like to invert it to
> "log4j2.enableJansi" (default false). I think negative properties with true
> default are confusing.
>
>
y be filterable based on
> at least the exception supertype, but any sort of filter like that could be
> useful in power user scenarios as well.
>
>> On 24 October 2017 at 22:07, Gary Gregory wrote:
>>
>> On Tue, Oct 24, 2017 at 5:47 PM, Remko Popma
>> wrote
I just finished reading it.
Looks great Matt!
Enjoy giving the presentation!
Remko
(Shameless plug) Every java main() method deserves http://picocli.info
> On Oct 31, 2017, at 6:26, Ole Ersoy wrote:
>
> That's the key - Gotta make it more fun! Keep it fresh - Ziplock fresh!
> Freshaliciou
I don’t know either language but I’d be more interested in learning Kotlin than
learning Scala.
OTOH I’m not sure how much time I’ll be able to contribute to Chainsaw so not
sure how much that should count for.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Nov 1
ote:
>
> Considering it takes about 2-3 months of daily use of Scala to get
> comfortable, perhaps Kotlin would be a better choice. It's a simpler
> language and is supposed to be easy for Java developers to pick up.
>
>> On 10 November 2017 at 19:43, Remko Popma wrote:
>>
ars.
>
> As mentioned in an earlier reply, this framework could be useful for
> Kotlin/JavaFX: <https://github.com/edvin/tornadofx>
>
>> On 10 November 2017 at 22:12, Remko Popma wrote:
>>
>> Now that I think of it, all else being equal, the combination of Kotlin
I’ll take a look tomorrow.
> On Nov 10, 2017, at 22:47, Ralph Goers wrote:
>
> Please review this commit as I want to make sure I didn’t make any mistakes.
>
> Ralph
>
>
>> On Nov 10, 2017, at 6:46 AM, rgo...@apache.org wrote:
>>
>> Repository: logging-log4j2
>> Updated Branches:
>> refs/
I’ve built several Swing-based apps and know Swing fairly well. I’ve only got
my feet wet with JavaFX.
Both are big frameworks with a significant learning curve.
Personally I’d use JavaFX, if only to make working on the project an
interesting learning experience.
> On Nov 12, 2017, at 9:13,
central at apache or do I need to build and install locally to test?
> >
> > thanks
> >
> > On 11/11/2017, 18:32, "Ralph Goers" wrote:
> >
> >Ok. I’m waiting on feedback on this before I start a release.
> >
> >Ralph
> >
> >
Aggreement-> Agreement
(Away from pc)
On Tue, Nov 14, 2017 at 0:50 wrote:
> Repository: logging-log4j2
> Updated Branches:
> refs/heads/master d85f39abc -> 8b71dbbf1
>
>
> Add PR notice to README
>
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit:
> http://git-w
Sorry, I still see one misspelled Aggreement
(Away from pc)
> On Nov 14, 2017, at 1:02, rgo...@apache.org wrote:
>
> Repository: logging-log4j2
> Updated Branches:
> refs/heads/master ac82a0d78 -> 7ade3025b
>
>
> Fix typo
>
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2
Gary,
Just wondering: how do you keep track of library version updates? Is there
a tool to get notified when there’s an update?
Amazing job by the way!
Remko
(Shameless plug) Every java main() method deserves http://picocli.info
No objection, and thanks for RM-ing!
Remko
> On Nov 16, 2017, at 14:04, Gary Gregory wrote:
>
> Great! And thank you for RM'ing again.
>
> Gary
>
> On Wed, Nov 15, 2017 at 9:31 PM, Ralph Goers
> wrote:
>
>> Unless someone objects I plan to start the release process for Log4j 2.10
>> tomor
The build now fails on windows.
I always see this error:
expected: C:\Users\remko\AppData\Local\Temp\/hadoop.log Actual:
C:\Users\remko\AppData\Local\Temp\/hadoop.log
java.nio.file.FileSystemException:
C:\Users\remko\AppData\Local\Temp\hadoop.log: The process cannot access the
file because it is
017, at 20:46, Mikael Ståldal wrote:
>
> Does it help if you add:
>
>appender.stop(10, TimeUnit.SECONDS);
>
> after line 171 in Log4j1ConfigurationFactoryTest.java (last in the try block)?
>
>
>> On 2017-11-19 05:41, Remko Popma wrote:
>> The build now
When I upgraded picocli to 2.0.3 a few weeks ago I made sure all tests passed
on Windows. CI builds are ok.
I also did a successful Log4j2 build on Windows yesterday when looking at pull
request #134.
This is very odd.
> On Nov 20, 2017, at 12:49, Ralph Goers wrote:
>
> All of these erro
time: 27:57 min
[INFO] Finished at: 2017-11-20T14:56:18+09:00
[INFO] Final Memory: 56M/518M
[INFO]
----
On Mon, Nov 20, 2017 at 2:10 PM, Remko Popma wrote:
> When I upgraded picocli to 2.0.3 a few weeks ago I made sure all
he tests use String.format
with %n to avoid this exact issue.
>
> Ralph
>
>
>> On Nov 19, 2017, at 11:12 PM, Remko Popma wrote:
>>
>> Building current master (211326b) succeeds for me when running `mvn clean
>> verify` on
>>
>> Apache Maven
:57+09:00
[INFO] Final Memory: 55M/451M
[INFO]
--------
On Mon, Nov 20, 2017 at 5:06 PM, Remko Popma wrote:
>
> > On Nov 20, 2017, at 15:21, Ralph Goers
> wrote:
> >
> > Oh, and I wouldn’t be surprised if the problem is caused by you using
> MS
urationFactoryTest.java:173)
> > >>>>>>
> > >>>>>>
> > >>>>>> I think Remko fixed that in master.
> > >>>>>>
> > >>>>>>
> > >>>>> Building master
I'll prepare the usual blog post.
On Thu, Nov 23, 2017 at 11:57 AM, Ralph Goers
wrote:
> This vote has passed with binding +1 votes from Mikael Ståldal, Matt
> Sicker, Remko Popma, and Ralph Goers, a binding -1 from Gary Gregory, and
> a non-binding +1 from Daan Hoogland.
>
This took me a while to get right, so let me share it.
Below unix command can be used to replace the markdown links to HTML links
in a text file:
sed -i -e 's/\[\([^\]*\)\](\([^)]*\))/\1<\/a>/g'
RELEASE-NOTES.md
Tricky points were that sed does not recognize the non-greedy qualifier, so
you need
Really?
Looking at announcement.vm they seem identical.
> On Nov 23, 2017, at 16:59, Ralph Goers wrote:
>
> Thanks, although the announcement is going to contain a bit more text than is
> in the release notes.
>
> Ralph
>
>> On Nov 23, 2017, at 12:06 AM, Remk
Interesting:
https://github.com/dblock/log4jna/blob/master/README.md
Maybe we should link to this from our site somewhere. Like a section on 3rd
party appenders or so?
Guys, if any of your findings should be reflected in the Log4j2
documentation for web applications, please let us know (I'm not following
this discussion in enough detail to judge whether the Log4j2 docs need
adjustment).
Documentation patches are always welcome!
On Thu, Nov 23, 2017 at 10:54 PM,
Generally it doesn’t make sense to expect ThreadLocal lookups to work with
async appender/loggers. Another lookup should be used.
I haven’t looked at the code but I expect that the subject is cached somehow.
Perhaps this should be changed (to no caching) so that the user experience is
consiste
Ok, you have some fair points there.
Main take-away for me is that if we want Log4j2's API to become ubiquitous
it needs to be at least painless for everyone.
Don't known about the "too much stuff" in log4j-api - bit vague and not
actionable.
What can we do, concretely?
log4j-api
-
1) I'
rsion 53 bytecode).
We can extract those classes into a temp directly, rename them back to the
canonical extension, and use the same class loader that loaded the other
log4j-api classes to load the Java 9 classes from the temp directory.
If this fails, we fall back to the Java 7-compatible implementa
On second thought, without a custom class loader we’d first need to copy
these classes into the classpath.
This may not always be possible and sounds like a bad idea anyway.
So please ignore my previous email.
On Sun, Dec 3, 2017 at 8:38 Remko Popma wrote:
>
> > On Dec 3, 2017, at 1:
From Java 9, interfaces can have private methods that can be called from
interface default methods. This is to reduce duplicate code in default method
implementations.
> On Dec 3, 2017, at 20:44, Mikael Ståldal wrote:
>
>> On 2017-12-03 00:24, Matt Sicker wrote:
>> It's too bad that Java 8
Interesting!
Can you point to an example of how this works? I’m trying to understand what
changes would be required.
Remko
(Shameless plug) Every java main() method deserves http://picocli.info
> On Dec 9, 2017, at 15:30, Jeffrey Shaw wrote:
>
> Hello,
> I've found that I am able to use Sca
But how would this filter be installed given that there is no configuration
file? Aren't we back to a system property to install this filter?
On Tue, Jan 2, 2018 at 12:27 PM, Ralph Goers (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/LOG4J2-1944?page=
> com.atlassian.jira.plugin.s
The build repeatedly gets stuck at the OSGi module...
[ERROR]
testMissingImportOfCoreOsgiPackage(org.apache.logging.log4j.osgi.tests.equinox.EquinoxLoadApiBundleTest)
Time elapsed: 0.58 s <<< ERROR!
org.osgi.framework.BundleException: Error reading bundle content.
Caused by: java.io.FileNotFoundE
> On Jan 9, 2018, at 4:49, ggreg...@apache.org wrote:
>
> Repository: logging-log4j2
> Updated Branches:
> refs/heads/master 2352052d0 -> 9637dc558
>
>
> [LOG4J2-2177] Replace use of deprecated Core API
> org.apache.logging.log4j.core.impl.Log4jLogEvent.Builder.setContextMap(Map String>). Add
I don’t think that creating a AbstractBatchedAppender/Manager would help with
batching.
Log4j2 currently already provides core batching support for appender
implementors with the `LogEvent.endOfBatch` attribute.
LogEvent producers, if they know that more events will follow, should set this
a
Here is the smart batching link:
https://mechanical-sympathy.blogspot.jp/2011/10/smart-batching.html?m=1
Remko
(Shameless plug) Every java main() method deserves http://picocli.info
On Wed, Jan 10, 2018 at 8:14 Remko Popma wrote:
> I don’t think that creating a AbstractBatchedAppender/Mana
the same applies to AsyncAppender, right?
>
>> On 2018-01-10 00:14, Remko Popma wrote:
>> Log4j2 internally uses this with async logging: with async logging, the
>> “producer” is the async logging queue. The queue “knows“ whether it’s empty
>> or whether more events will fo
No objection, but please do this in a way that existing users of this appender
are not affected.
So if the new behavior is incompatible with the current behavior, then the new
behavior should be switched on explicitly in configuration.
Remko
(Shameless plug) Every java main() method deserve
How about moving all of these (generic database support, jdbc and jpa) together
into a single separate module?
Something like:
log4j-db
I don’t see much value into splitting them up further, but perhaps that’s just
me.
Remko
(Shameless plug) Every java main() method deserves http://picocli
Fri, Jan 12, 2018 at 10:14 PM, Remko Popma wrote:
>>
>> How about moving all of these (generic database support, jdbc and jpa)
>> together into a single separate module?
>>
>> Something like:
>>
>> log4j-db
>>
>> I don’t see much value into spli
les: JPA and JDBC, then the generic .db package needs to
> stay in log4j-core. Which would be OK for now.
>
> Gary
>
> On Fri, Jan 12, 2018 at 11:16 PM, Remko Popma
> wrote:
>
> > Okay perhaps just two modules then?
> >
> > By the way, I have work in progre
tåldal" wrote:
>>
>> As usual, I think we should avoid optional dependencies.
>>
>>
>> That means more modules.
>>
>> Maybe we can start small here with a log4j-jpa module.
>>
>> Gary
>>
>>
>>
>>
>>>
I’m hoping to complete https://issues.apache.org/jira/browse/LOG4J2-1883 in a
week or two.
That would bring a new log4j-core-java9 module and should probably be called
2.11 if that can be included.
Remko
(Shameless plug) Every java main() method deserves http://picocli.info
> On Jan 14, 20
No objection from me.
Let’s make it a community goal to speed up the Log4j2 build. We should start by
creating a JIRA epic (it’s in maintenance now but when it’s back up).
(Shameless plug) Every java main() method deserves http://picocli.info
> On Jan 15, 2018, at 6:11, Ralph Goers wrote:
>
Doesn't that depend on the generic type T of the Layout?
For example, MessageLayout extends AbstractLayout returns a
Message instance.
You could return a ByteBuffer, but generally for an efficient binary layout
I would look at the encode method instead.
On Tue, Jan 16, 2018 at 11:45 PM, Mikael Stå
all of the LogEvent
> attributes. Even so, you could have AbstractLayout if you
> wanted the serialized version of the LogEvent. It can also be anything else
> that implements Serializable.
>
> Ralph
>
> > On Jan 16, 2018, at 8:06 AM, Remko Popma wrote:
> >
> > D
Reducing the time it takes to run the core tests is key.
It would be great if we could specify which tests should be forked, and run the
rest non-forked. Perhaps we need to enhance Surefire. Or can JUnit 5 help
somehow (haven’t looked at it yet)?
Remko
(Shameless plug) Every java main() met
Mikael, Ralph,
Have you really thought through the implications of having a separate
repository for each module? The overhead is very large!
It would mean:
* a separate website for each repo (our current Log4j2 website only knows
about the modules in the logging-log4j project).
* a separate relea
This looks promising:
http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html
(especially the @NotThreadSafe annotation, potentially in combination with
JUnit Suits)
On Sun, Jan 21, 2018 at 13:12 Remko Popma wrote:
> Mikael, Ralph,
>
>
Log4j2 is not like Maven. Maven (I assume) has a plugin API. Log4j2 modules
depend on the internals of log4j-core.
I agree with Gary that not being able to verify that a core change doesn’t
break any modules when they live outside the main project is a valid concern.
Why are we talking about
Gary,
If you’re looking for a “to accomplish X, do Y”, see the FAQ.
https://logging.apache.org/log4j/2.x/faq.html#troubleshooting
(Shameless plug) Every java main() method deserves http://picocli.info
> On Jan 23, 2018, at 5:46, Gary Gregory wrote:
>
> On Mon, Jan 22, 2018 at 12:49 PM, Ralph
+1
(Shameless plug) Every java main() method deserves http://picocli.info
> On Jan 23, 2018, at 7:29, Matt Sicker wrote:
>
> I'll add my +1 from earlier. We still need another +1, though it's only
> been two days so far, so we still have time.
>
>> On 20 January 2018 at 16:54, Matt Sicker wro
Nice!!
(Shameless plug) Every java main() method deserves http://picocli.info
> On Jan 23, 2018, at 14:25, Gary Gregory wrote:
>
> On Mon, Jan 22, 2018 at 9:45 PM, Gary Gregory
> wrote:
>
>> Hm, it already uses the mock stuff!
>>
>> I reduced test delays in the MockProducer introduced in com
> On Jan 23, 2018, at 7:29, Ralph Goers wrote:
>
> IMO the main repo should contain the stuff 80% (or more) of our user’s use
> and the stuff that is common across all plugins. So the file appenders and
> console appenders all belong, probably most of the existing lookups and
> filters. Sinc
This solution should work. Thanks for taking care of this, Gary!
One thing, why are the new fields capitalized? It makes the field names look
like class names in the code. I’ve never seen that convention. Should they not
be simply lower case?
(Shameless plug) Every java main() method deserves h
I see what you mean. Hmm...
FYI, this feature (LOG4J2-1883) adds the following classes. I added them to
core.util, but they could still be moved to another package:
* Instant
* PreciseClock
* MutableInstant
* DummyPreciseClock
* SystemMillisClock
I would not consider moving the existing time-re
1 - 100 of 595 matches
Mail list logo
