This gets more and more confusing the more I dig into it.
SmtpAppender apparently supports PatternLayout conversions in the
subject (which is not documented), but then are done on the very first
log event sent through the SmtpAppender (or actually the SmtpManager,
which can be shared among mul
In theory…
Ralph
> On Dec 3, 2017, at 11:11 AM, Matt Sicker wrote:
>
> Plus the whole multi-version jars feature is super handy for a library like
> Log4j which can add support for each new Java version while maintaining BC
> with older Java releases without having to resort to reflection hacks
Plus the whole multi-version jars feature is super handy for a library like
Log4j which can add support for each new Java version while maintaining BC
with older Java releases without having to resort to reflection hacks and
other dynamic loading.
On 3 December 2017 at 07:00, Remko Popma wrote:
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
It does work for the subject and body, see the new unit test
SmtpAppenderAsyncTest i just pushed to Git master. And I think this
behaviour make sense and should be retained.
The question is about header/footer. I think that it doesn't make sense
to use ThreadContext lookups there. But maybe we
On 2017-12-03 00:24, Matt Sicker wrote:
It's too bad that Java 8 and 9 added language features
that would have been immensely useful for maintaining a backwards
compatible API (default and private methods on interfaces),
Did Java 9 add anything more than Java 8 for this?
OK. I was not aware of this. I thought that it was the Java 9
implementation (StackLocator/ProcessIdUtil) that caused the problem.
On 2017-12-03 06:30, Ralph Goers wrote:
Let’s go back to this post.
Assume we figured out how to get rid of all the stuff you consider to be not
required to be i
Yes, log4j-core-android would be a good idea. But yes, we have to solve
the API problem first.
On 2017-12-02 17:40, Ralph Goers wrote:
FWIW, it would make sense to me to make a log4j-core-android that is a subset
of what is in core, if that is possible. Of course, the API problem has to be
s
The problem is that we cannot just remove stuff from log4j-api now,
since that would break binary/source compatibility for existing users.
If I understand it correctly, due to the Java 9 modules, if we move
stuff from log4j-api to log4j-core we have to change package, right? And
we don't want re
