Re: `a.o.l.l.core.parser` package removal

[Mikael Ståldal]

Then users or 3rd parties can implement their own parsers if they need to.

It might be useful to have parsers for some common formats like GELF, 
Logstash or RFC-5424, and that can be implemented without using Jackson 
if necessary.


/Mikael


On 2024-01-07 10:38, Mikael Ståldal wrote:
What about (re)moving the classes which actually depends on Jackson 
(AbstractJacksonLogEventParser, JsonLogEventParser, XmlLogEventParser, 
YamlLogEventParser), but keeping the interfaces (LogEventParser, 
TextLogEventParser, ParseException) in log4j-core?


/Mikael


On 2024-01-05 11:25, Volkan Yazıcı wrote:
I support the idea of removing the Jackson-based `LogEvent` parser. 
Back in

the days when `JsonLayout` was the only JSON-formatted layout, it might
have made sense to provide deserialization support next to serialization.
With `JsonTemplateLayout`, where the JSON structure is controlled by the
user, the deserialization companion is not only impossible, but also
doesn't make sense anymore.

@Piotr, do you propose removing it in `2.x` or `main`? My preference 
would

be both.

On Tue, Jan 2, 2024 at 12:09 PM Piotr P. Karwasz 


wrote:


Hi,

While working on PR#2142[1] I noticed that we have an
`a.o.l.l.core.parser` package that depends on Jackson.

Since Log4j itself never parses log events, I would propose to remove
it from `log4j-core` and optionally move it somewhere else (Chainsaw
or Flume?).

My main concern is vulnerability exposure:

  * I would like to prevent CVEs like CVE-2019-17571[2] from being
published against `log4j-core` in the future. Dealing with CVEs that
say "code that we never use is vulnerable to..." bring a lot of
useless PR/documentation work: we'll need to explain to users how to
mitigate a vulnerability that is almost never exploitable and our
users will also have to evaluate the exploitability of the CVE in
their own applications,
  * in some not so far future we'll need to publish VEX records to
comply with regulation. Every time Jackson will publish a
deserialization vulnerability, we'll need to state that we are
vulnerable.

What do you think?

Piotr

[1] https://github.com/apache/logging-log4j2/pull/2142
[2] https://www.cvedetails.com/cve/CVE-2019-17571/

Re: `a.o.l.l.core.parser` package removal

[Mikael Ståldal]

What about (re)moving the classes which actually depends on Jackson 
(AbstractJacksonLogEventParser, JsonLogEventParser, XmlLogEventParser, 
YamlLogEventParser), but keeping the interfaces (LogEventParser, 
TextLogEventParser, ParseException) in log4j-core?


/Mikael


On 2024-01-05 11:25, Volkan Yazıcı wrote:

I support the idea of removing the Jackson-based `LogEvent` parser. Back in
the days when `JsonLayout` was the only JSON-formatted layout, it might
have made sense to provide deserialization support next to serialization.
With `JsonTemplateLayout`, where the JSON structure is controlled by the
user, the deserialization companion is not only impossible, but also
doesn't make sense anymore.

@Piotr, do you propose removing it in `2.x` or `main`? My preference would
be both.

On Tue, Jan 2, 2024 at 12:09 PM Piotr P. Karwasz 
wrote:


Hi,

While working on PR#2142[1] I noticed that we have an
`a.o.l.l.core.parser` package that depends on Jackson.

Since Log4j itself never parses log events, I would propose to remove
it from `log4j-core` and optionally move it somewhere else (Chainsaw
or Flume?).

My main concern is vulnerability exposure:

  * I would like to prevent CVEs like CVE-2019-17571[2] from being
published against `log4j-core` in the future. Dealing with CVEs that
say "code that we never use is vulnerable to..." bring a lot of
useless PR/documentation work: we'll need to explain to users how to
mitigate a vulnerability that is almost never exploitable and our
users will also have to evaluate the exploitability of the CVE in
their own applications,
  * in some not so far future we'll need to publish VEX records to
comply with regulation. Every time Jackson will publish a
deserialization vulnerability, we'll need to state that we are
vulnerable.

What do you think?

Piotr

[1] https://github.com/apache/logging-log4j2/pull/2142
[2] https://www.cvedetails.com/cve/CVE-2019-17571/

Re: [log4j] Release 2.20.0 missing tests.jar

[Mikael Ståldal]

Thanks.

Updated my blog post about it:

https://www.staldal.nu/tech/2022/11/02/how-to-capture-log-events-in-tests-with-log4j-2/

/Mikael


On 2023-03-01 21:06, Piotr P. Karwasz wrote:

Hi Mikael,

On Wed, 1 Mar 2023 at 20:41, Mikael Ståldal  wrote:

It seems like the 2.20.0 release is missing the
log4j-core-2.20.0-tests.jar, that used to be part of the releases. Is
that intentional?


See

https://issues.apache.org/jira/browse/LOG4J2-3650

for more explanations and:

https://lists.apache.org/thread/mfc5llrbtzb94pmyw401jlf3kn6llp9r

for the discussion.

Piotr

[log4j] Release 2.20.0 missing tests.jar

[Mikael Ståldal]

It seems like the 2.20.0 release is missing the 
log4j-core-2.20.0-tests.jar, that used to be part of the releases. Is 
that intentional?

Re: [VOTE] Release Log4j 2.15.1-rc1

[Mikael Ståldal]

I agree too. I was just worried that we wouldn't remove Message Lookups 
until 3.x. Removing them in the next minor release (2.16.0) is reasonable.



On 2021-12-13 10:12, Volkan Yazıcı wrote:

I agree with both of your points Remko.

On Mon, Dec 13, 2021 at 2:40 AM 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 that security change (removing Message
Lookups) in such a 2.16.0 release and not add other features.
This will reduce the testing burden for people looking to upgrade.



On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
wrote:


Volkan,

While ASF rules say a -1 vote is not a veto for all practical purposes

the

release manager is going to consider it a blocker.

A release that removes JNDI will prevent people from inadvertently using
the JNDI Lookup, JMS, or JndiContextSelector
without understanding the security risk using them. Message Lookups are a
different problem. We are not disabling JNDI
so people can re-enable message lookups. That would be crazy. We are
disabling JNDI because, despite all the fixes we
have made, I still don’t trust it.

We have all agreed Message Lookups need to be killed in master. If we are
all in agreement to kill them now in 2.x I’m
fine with that but the two are separate issues.

If you are OK with the release than your vote should be anything but -1.
If you really feel it needs a -1 then we need to see
if we are all ok completely removing the option to re-enable message
lookups. I would completely understand if that is what
you want and I would support that so please don’t feel pressured to give
in.

Ralph



On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:

You don't need my vote. As far as I count, you already have more than

3.


I can imagine Ralph and the rest have worked sleeplessly for days.

Hence

if

they think disabling JNDI buys us a benefit, so be it.

If not millions, tens of thousands of people tried to upgrade Log4j to
2.15.0 recently. A release where JNDI lookup disabled will only adress
people who still (astonishingly!) want to use "message lookups" –

correct

me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring

more

confusion than benefit to the general audience. I think the fix to the
vulnerability is to disable message lookups, not patches to the JNDI
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 project.

On Sun, Dec 12, 2021 at 9:47 PM 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
) feels urgent

enough

to
warrant another shortened vote window.
A larger change like removing message lookups should not be rushed out

like

this, it needs review time.

Second, do we really want to do this? Are we not overreacting?
Would it not be better to remove lookups in message parameters only?
(In implementation terms, resolve all lookups *before* interpolating

the

message parameters?)

Also, let me state the obvious, lookups *in configuration* are

tremendously

useful and should not be removed.
This may be obvious to some of us, but I just want to make sure there

is no

confusion about that (because I personally was confused about this at

some

point). :-)

Finally, if we decide to do this, should a 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 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 Sun, Dec 12, 2021 at 9:01 PM Matt Sicker 

wrote:


Those were already disabled in 2.15.0.

Matt Sicker


On Dec 12, 2021, at 13:41, Volkan Yazıcı 

wrote:


I very well recognize your heroic effort on tackling this issue

and

I am

very thankful for that.
I vote -1, because I want message (not configuration!) lookups to

be

removed.

Message lookups create a vast attack surface. Anything they offer

can

simply be implemented by the user.


On Sun, Dec 12, 2021 at 4:48 AM Matt Sicker 

wrote:


This is a vote to release Log4j 2.15.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 release because...

The vote will remain open for 72 hours (or more if required).

All

votes

are welcome and we encourage everyone to test the release, but

only

Logging

PMC votes are “officially” counted. 

Re: Removing message lookups in master

[Mikael Ståldal]

I would say that log messages and log message parameter are as much (or 
as little) controlled by the application. I don't think it make sense to 
see them differently from a security perspective.


Just as some code might do:
  logger.info("some message {}", userInput);

Other code might do:
  logger.info("some message " + userInput);

And if you use the Scala API, parameters get merged into the log message 
since you would use Scala string interpolation:

https://logging.apache.org/log4j/scala/index.html

(There might also exist 3rd-party language bindings or other wrappers of 
Log4j where parameters are merged into into the log message before 
passed to Log4j.)


I think that lookups should be removed from both log message and log 
message parameters.



On 2021-12-10 11:50, Remko Popma wrote:

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 problems can be found during review/audit.

I cannot imagine a scenario where doing lookups against the message
parameters is useful.
There could be such a scenario, but then the application should do this
explicitly, with something like

logger.info("some message {}", doExplicitLookup(param));

I haven't looked at the fix in enough detail, but removing lookups in
logging message parameters sounds reasonable.
Not sure how easy it would be to implement this though.


On Fri, Dec 10, 2021 at 7:31 PM Volkan Yazıcı  wrote:


Shall we completely remove message lookups (which are only used by
PatternLayout) in master?

Re: Logging to Datadog

[Mikael Ståldal]

JIRA issue created: https://issues.apache.org/jira/browse/LOG4J2-3197

I think that the API key prefix is outside of the JSON, so the end 
result is not proper JSON. I suppose that the Datadog service will 
pre-parse the received event to extract the API key, and then parse the 
rest as JSON. Like this:


MY_API_KEY_HERE {"some":"json","object":"here"}

/Mikael


On 2021-11-27 11:35, Volkan Yazıcı wrote:

Thanks for the heads up Mikael! I am pretty sure JSON Template Layout can
suffice this goal – if it can't, I will make sure it can. From the Datadog
documentation you have shared
<https://docs.datadoghq.com/logs/log_collection/java>, the expected JSON
structure is not clear. They have used logstash-logback-encoder's prefix
feature
<https://github.com/logfellow/logstash-logback-encoder#prefixsuffixseparator>,
yet I couldn't understand how does it "prefix" a JSON object. For instance,
how can you prefix a JSON array with a string!? Nevertheless, I guess I
need to run this myself locally and figure that detail out. I will really
appreciate it if you can create a JIRA ticket and assign it to my name.
After making sure it works, I will get in touch with the Datadog team too.

On Sat, Nov 27, 2021 at 11:10 AM Mikael Ståldal  wrote:


The documentation for Datadog contains information on how to setup Log4j
2 to send logs to Datadog. However, for the agentless configuration, it
says its not possible with Log4j 2 and resorts to bridging to Logback.


https://docs.datadoghq.com/logs/log_collection/java/?tab=log4j2#agentless-logging

The problem is that the JSON formatted log events needs to be prefixed
with an API key (outside of the JSON structure). This is possible with
Logback, but supposedly not with Log4j 2.

This configuration is arguably a bit strange, but it would be good if
Log4j 2 could support it, since it is likely a relevant use case.

Maybe this is already possible with recent versions of Log4j 2? If not,
I believe it should be easy to add.


For the standard configuration, Datadog recommends the JSONLayout:


https://docs.datadoghq.com/logs/log_collection/java/?tab=log4j2#configure-your-logger

Maybe the new JsonPatternLayout would be more suitable?

/Mikael

Logging to Datadog

[Mikael Ståldal]

The documentation for Datadog contains information on how to setup Log4j 
2 to send logs to Datadog. However, for the agentless configuration, it 
says its not possible with Log4j 2 and resorts to bridging to Logback.


https://docs.datadoghq.com/logs/log_collection/java/?tab=log4j2#agentless-logging

The problem is that the JSON formatted log events needs to be prefixed 
with an API key (outside of the JSON structure). This is possible with 
Logback, but supposedly not with Log4j 2.


This configuration is arguably a bit strange, but it would be good if 
Log4j 2 could support it, since it is likely a relevant use case.


Maybe this is already possible with recent versions of Log4j 2? If not, 
I believe it should be easy to add.



For the standard configuration, Datadog recommends the JSONLayout:

https://docs.datadoghq.com/logs/log_collection/java/?tab=log4j2#configure-your-logger

Maybe the new JsonPatternLayout would be more suitable?

/Mikael

Success at Apache blog post about Log4j 2

[Mikael Ståldal]

https://blogs.apache.org/foundation/entry/success-at-apache-carrying-forward

Re: [log4j] log4j-core test speed breakdown

[Mikael Ståldal]

I the delay is there for the "testClose" test cast, but it slows down 
the other test methods as well, which is unintended.


I have fixed it now by breaking out the "testClose" test case to its own 
class.



On 2018-01-23 14:39, Gary Gregory wrote:

It would be nice to heard from Mike his thoughts on my change since he
added the delay in the first place. I am worried about any 'bite you later
' factor :-p

On Jan 22, 2018 11:31 PM, "Remko Popma"  wrote:


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 commit
96436fb958ce1f1a3d4f0c951f556f0709c91b15 (by Mike) from 3 seconds to 50
milliseconds. This reduces running this test case from 43 to 3 seconds.
Let's watch this test in Jenkins to make sure it still passes. It runs

fine

over and over in Eclipse and with 'mvn test -pl log4j-core
-Dtest=KafkaAppenderTest'.

If Jenkins is happy that's 40 seconds * test_runs shaved off the build.



It worked and did not break anything:
https://builds.apache.org/user/ggregory/my-views/view/

Logging/job/Log4j%202.x/3317/


Gary




Gary


On Mon, Jan 22, 2018 at 1:11 PM, Matt Sicker  wrote:

The Kafka test could probably be rewritten to use the
MockProducer/MockConsumer classes instead of presumably embedding

Kafka.



On 22 January 2018 at 14:08, Gary Gregory 

wrote:


Hi All:

Here are some number based on
https://builds.apache.org/user/ggregory/my-views/view/

Logging/job/Log4j

2.x/3315. There are some obvious low-hanging fruits.

43.078  org.apache.logging.log4j.core.appender.mom.kafka.KafkaAppend

erTest

33.799
org.apache.logging.log4j.core.appender.routing.
RoutingAppenderWithPurgingTest
20.638  org.apache.logging.log4j.core.appender.FileAppenderPermissio

nsTest

15.375
org.apache.logging.log4j.core.appender.rolling.

RollingAppenderSizeTest

14.752
org.apache.logging.log4j.core.appender.rolling.
RollingAppenderCronOnceADayTest
12.075  org.apache.logging.log4j.core.GcFreeMixedSyncAyncLoggingTest
10.031  org.apache.logging.log4j.core.async.AsyncRootReloadTest
9.835  org.apache.logging.log4j.core.GcFreeAsynchronousLoggingTest
9.295
org.apache.logging.log4j.core.appender.rolling.

RollingAppenderCronTest

9.142  org.apache.logging.log4j.core.GcFreeSynchronousLoggingTest
8.777  org.apache.logging.log4j.core.LoggerTest
8.347  org.apache.logging.log4j.core.config.TestConfigurator
8.186  org.apache.logging.log4j.core.config.

ReconfigurationDeadlockTest

8.085  org.apache.logging.log4j.core.util.WatchManagerTest
6.915  org.apache.logging.log4j.core.filter.BurstFilterTest
6.517
org.apache.logging.log4j.core.appender.rolling.
RollingAppenderCronEvery2DirectTest
6.421
org.apache.logging.log4j.core.appender.rolling.
RollingAppenderCronEvery2Test
6.11  org.apache.logging.log4j.core.PropertiesFileConfigTest
6.026  org.apache.logging.log4j.core.layout.CsvParameterLayoutTest
5.922
org.apache.logging.log4j.core.appender.rolling.
RollingAppenderSizeNoCompressTest
5.742
org.apache.logging.log4j.core.util.datetime.FastDateParser_
TimeZoneStrategyTest
5.534  org.apache.logging.log4j.core.appender.db.jpa.

JpaH2AppenderTest

5.456  org.apache.logging.log4j.core.appender.db.jpa.JpaHsqldbAppen

derTest

4.315  org.apache.logging.log4j.core.appender.TlsSyslogAppenderTest
3.536
org.apache.logging.log4j.core.appender.rolling.
RollingAppenderTempCompressedFilePatternTest
3.475
org.apache.logging.log4j.core.appender.rolling.
RollingAppenderSizeCompressPermissionsTest
3.331  org.apache.logging.log4j.core.appender.HttpAppenderTest
3.256
org.apache.logging.log4j.core.appender.routing.
DefaultRouteScriptAppenderTest
2.993  org.apache.logging.log4j.core.util.datetime.

FixedDateFormatTest

2.982
org.apache.logging.log4j.core.appender.routing.RoutesScriptA

ppenderTest

2.96  org.apache.logging.log4j.core.util.datetime.FastDateParserTest
2.562  org.apache.logging.log4j.core.tools.GenerateExtendedLoggerTest
2.547  org.apache.logging.log4j.core.appender.XmlCompleteFileAppend

erTest

2.398
org.apache.logging.log4j.core.appender.rolling.
RollingAppenderDeleteScriptFri13thTest
2.394
org.apache.logging.log4j.core.appender.rolling.

RollingAppenderTimeTest

2.381
org.apache.logging.log4j.core.appender.rolling.
RollingAppenderDeleteScriptTest
2.378  org.apache.logging.log4j.core.appender.SocketAppenderBufferS

izeTest

2.26  org.apache.logging.log4j.core.tools.GenerateCustomLoggerTest
2.19  org.apache.logging.log4j.core.appender.

ScriptAppenderSelectorTest

2.061  org.apache.logging.log4j.core.appender.AsyncAppenderTest
1.996  org.apache.logging.log4j.core.config.ConfigurationTest
1.993
org.apache.logging.log4j.core.appender.rolling.
RollingAppenderTimeAndSizeDirectTest
1.823

Re: [log4j] Adding methods to org.apache.logging.log4j.core.appender.nosql.NoSqlObject

[Mikael Ståldal]

Is it really that useful to have "NoSQL" as an abstraction in the first 
place? Is there that much code to share?



On 2018-01-22 21:43, Gary Gregory wrote:

On Mon, Jan 22, 2018 at 12:30 PM, Matt Sicker  wrote:


Back when I wrote the initial CassandraAppender implementation, I found the
existing NoSQL interfaces to be too restrictive. I found a similar problem
long ago when I was experimenting with a DynamoDB appender. Most NoSQL APIs
I've used tend to accept a generic Map for documents/records, and it was
only the Mongo API that had its own thing going on.



The good news is that the new log4j-mongodb3 appender that I have ready but
not committed (see "The Shape of Log4j" thread) is based on BSON Documents
which implement java.util.Map, so that would be a good clean up.

Maybe we could bypass this NoSqlObject-vs-NoSqlObject2 issue with a new
interface NoSqlMapObject instead of NoSqlObject?

I've not looked at the other appenders though...

Gary



With that in mind, I'd support breaking that API and redoing it entirely so
it's not as specific to Mongo/Couch. I think I still have a backlog item
about implementing a DynamoDB appender, and I'd also like to see something
similar eventually for Elasticsearch (which I've been working with
extensively lately).

On 21 January 2018 at 23:47, Gary Gregory  wrote:


Hi All,

The interface org.apache.logging.log4j.core.

appender.nosql.NoSqlObject

requires arrays in two methods:

set(String, NoSqlObject[])
set(String, Object[])

For some providers like the new MongoDB driver 3.x provider I am working

on

this causes double work. First the log4j NoSQL guts converts a list into

an

array
in org.apache.logging.log4j.core.appender.nosql.NoSqlDatabaseManager.
setFields(LogEvent,
NoSqlObject):

entity.set("contextStack", contextStack.asList().toArray());

Then, the new NoSqlObject impl I have converts that array back into a

list

to pass to Mongo.

If I wanted to add List versions of the two array APIs in NoSqlObject,
should I:

- Just add-em and adjust all providers.
- Create a NoSqlObject2 sub-interface

Thoughts?

Gary





--
Matt Sicker 

Re: [log4j] The shape of Log4j

[Mikael Ståldal]

Yes, but it is unfortunate that the worry about the main repo size make 
us hesitate splitting out stuff from log4j-core into own modules.



On 2018-01-24 22:37, Ralph Goers wrote:

They are not really orthogonal.

1. Log4j core contains some stuff that isn’t really “core” functionality., such 
as Kafka or JMS. These cause the core tests to take longer than necessary.
2. The size of the repo directly effects how long a build takes to run, as does 
the number of components in core.




On Jan 24, 2018, at 2:24 PM, Mikael Ståldal <mi...@apache.org> wrote:

Yes, and it's unfortunate that they get conflated.

On 2018-01-21 16:55, Gary Gregory wrote:

I can see two main orthogonal issues:
- The size of the git repo.
- The size of the log4j-core module.

Re: [log4j] The shape of Log4j

[Mikael Ståldal]

Yes, and it's unfortunate that they get conflated.

On 2018-01-21 16:55, Gary Gregory wrote:

I can see two main orthogonal issues:
- The size of the git repo.
- The size of the log4j-core module.

Re: [log4j] The shape of Log4j

[Mikael Ståldal]

Yes, neither Git nor Maven is optimal for mono-repos since you can only 
tag/branch the whole repo, and only have one version for the whole build.


Google have a big mono-repo, but they do not use Git, nor Maven.

I think we should release and version everything in one repo together, 
otherwise it will get very messy.



On 2018-01-22 22:58, Matt Sicker wrote:

Using Maven profiles could help, though when tagging a release, if we
didn't release every module within, then it'd get out of sync anyways. Then
it would still require building every single component in each release,
even when said components haven't changed at all.

On 22 January 2018 at 15:50, Gary Gregory  wrote:


Coming back around to the idea of One Repo to Rule Them All*TM* ... what if
we used Maven profiles to separate out the "main" build from "other"
builds?

All that is needed to move modules from one build to another is just to
edit the profile!

Re: [log4j] The shape of Log4j

[Mikael Ståldal]

On 2018-01-22 23:37, Matt Sicker wrote:

On 22 January 2018 at 16:29, Ralph Goers  wrote:


If it was up to me I would move the following Appenders: Cassandra, Flume,
JDBC, JMS, JPA, HTTP, Kafka, NoSQL, SMTP, ZeroMQ/JeroMQ, CouchDB, MongoDB.
In addition to those I would move the taglib, imx-gui and samples modules
and possibly the perf module. Although it is probably lightly used I would
consider keeping the iostreams module, although to be honest I am not sure
why it isn’t part of the api module.



I like this idea generally since those plugins are rarely updated after
being developed. 


At least Kafka appender has been updated a number of times since it was 
incepted.


> The iostreams API could be added to log4j-api.

I think we should be very careful about adding new stuff to log4j-api.

Re: [log4j] The shape of Log4j

[Mikael Ståldal]

There is no NoSQL appender. There are Cassandra, CouchDB and MongoDB 
appenders. I don't think we should bundle them together.



On 2018-01-22 23:29, Ralph Goers wrote:

If it was up to me I would move the following Appenders: Cassandra, Flume, 
JDBC, JMS, JPA, HTTP, Kafka, NoSQL, SMTP, ZeroMQ/JeroMQ, CouchDB, MongoDB. In 
addition to those I would move the taglib, imx-gui and samples modules and 
possibly the perf module. Although it is probably lightly used I would consider 
keeping the iostreams module, although to be honest I am not sure why it isn’t 
part of the api module.

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

[Mikael Ståldal]

I actually prefer to keep everything related to Log4j 2 (maybe except 
Chainsaw) in the same repository, if we can find a way to manage that 
properly.


But if we have to split it up as Ralph wants, we should do it properly 
and have one repository and release train per module (or closely related 
modules, mongodb and couchdb is not closely related in my world).


I think that having a kitchen-sink plugins repository collecting lots of 
unrelated plugins, and still having some "core" plugins in the main 
repo, would give us the worst from both worlds. Let's not go there.



On 2018-01-21 05:12, Remko Popma wrote:

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 release and release vote would need to be performed *for each
repo*. This process is so heavy that we only do it once a month for Log4j2.
Imagine doing this 10 times when we have 10 modules each in separate repos.
* synchronizing with the main Log4j project becomes checking and updating
10 projects instead of one.

All of these concerns already hold for a single log4j-plugins project, they
just multiply for each additional repo.

All,

Gary does have a point when he says we don’t have a clear plan for managing
the log4j-plugins repo. Who is going to check that the plugins still
compile after a Log4j2 release? Are we going to release a new plugins
version for each Log4j2 release? If not, when _will_ we release new
log4j-plugins versions?

Given our terrible track record for the log4j-tools project since we moved
TcpServer etc. into that repo (nobody showing interest to do the work to
release it), I agree these are valid concerns.

On the other hand, I also completely agree with Ralph that the build takes
much too long. Something needs to be done and Ralph is clearly signalling
he won't have this problem ignored any longer.

I'm not sure that moving things out of the main repo is the only solution
to make the build faster. If it really is the *only* solution, then fine.
But be mindful we are trading one problem for a set of new ones, and, just
like we can't ignore the slow build problem, we also cannot ignore the new
problems introduced by this solution (keeping the new repo(s) in sync,
building new web sites and linking them into the main site, release timing
etc).

PROPOSAL:
I think all of us should take responsibility for speeding up the build and
make it our first priority.
If you want to add anything to the main project, *first reduce the build
duration*. First find an existing test and speed it up. Only then add new
stuff, keeping the total build time to the same or less than it was
before.  Building core and running its tests used to take 8 minutes. Now it
takes 19:10 (`mvn clean package` on the whole project takes 24:22).

The core tests clearly are a major bottleneck.

Speeding up the core tests is something we can all work on. Can we split
the tests into a set that can be run multi-threaded in parallel (fastest),
a different set that does not require forking (fast) and a third set that
requires forking for every test (slowest)?

On the other hand, if we want to move things out of the main repo we need a
plan for the new repo(s). There is a one-time work of setting up web sites
and integrating them with the main site, but on an ongoing basis we need
some way to verify that a change in log4j-core did not break any plugins,
and agree to do a plugins release if it did break something.

Remko


On Sun, Jan 21, 2018 at 2:27 Ralph Goers <ralph.go...@dslextreme.com> wrote:


I am fine with doing that but we would still want a way to get to all the
plugin sites from the log4j web site. Maven does that and maintains a list
at https://maven.apache.org/plugins/ <https://maven.apache.org/plugins/>.
I think the easiest way to manage a page like that would to have it be a
separate page in the CMS that the log4j site links to.

Ralph


On Jan 20, 2018, at 8:29 AM, Mikael Ståldal <mi...@apache.org> wrote:

As I wrote recently, I don't think that having a kitchen-sink plugins

repository is a good way to solve this. Eventually that repository will get
too big.


It's better to create a new repository for each new module (or possibly

for a couple of related modules, but they should be more related than just
being Log4j plugins).



On 2018-01-19 06:31, Ralph Goers wrote:

Gary, I am complaining because I perform the releases. You never have.

We keep adding more and more crap to the build and it keeps taking longer
and longer. Af far as I am concerned that is a valid technical reason.

My -1 stands.
Ralph

On Jan 18, 2018, at 10:24 PM, Gary Gregory <garydgreg...@gmail.com>

wrote:


On Thu, Jan 18, 2018 at 10:20 PM, Ralph Goers <

ralph.go...@dslextreme.com>

wrote:


OK, but 

Re: Planning out what we can do to get Chainsaw back in the game

[Mikael Ståldal]

Nothing stops you from starting your own log viewer project based on 
whatever technology you want. If it turns out useful, we might even 
consider adopting it as an Apache Logging subproject.


I think it's better if you and we try out what we believe in 
independently, and then we will see what works best.



On 2018-01-20 21:32, Ole Ersoy wrote:
Still pretty certain you would attract a lot more talent / downloads / 
interest in general with Visual Studio Code (Typescript) and Stackblitz:


https://stackblitz.com/

It's essentially Kotlin but a lot more feature rich.

Ole

On 01/20/2018 12:00 PM, Matt Sicker wrote:

I've put out rc2 now that we have some fixes in place there.

My professional situation has changed since I proposed this. Nowadays, 
I've

been using Kotlin for a project, and I'd have to say that it would be far
more appropriate than Scala here due to being easier to learn as a Java
developer (or just in general) along with better overlap with Java best
practices (Kotlin is essentially a language inspired by Effective Java).
Plus, now that Android developers are getting more familiar with 
Kotlin as
well which could potentially attract contributors (besides being a hip 
cool

language or whatever).

On 13 November 2017 at 17:35, Ole Ersoy  wrote:


Here's a 10 minute video where an Angular timer application is built and
packaged for all desktops (Apple, M$, Linux - And all browsers) ... 
in 10

minutes.

https://www.youtube.com/watch?v=u_vMChpZMCk

If you use the youtube speedup chrome extension you can probably set the
speedup factor to 2 or 3.  That cuts it down to 3 minutes.

https://chrome.google.com/webstore/detail/youtube-playback-
speed-co/hdannnflhlmdablckfkjpleikpphncik?hl=en-US

Love that thing!



On 11/12/2017 11:37 PM, Ralph Goers wrote:


It feels to me that this whole topic has gotten side-tracked.

I think you first need to decide what you want to build before you 
decide

on technologies.  Are you building a web application or a desktop? Of
course, there might be technology that lets you do both, to some 
degree. As
far as I know, the only viable language for web applications is 
Javascript,
unless you want to build browser plugins. While there might be more 
variety
in desktop applications, the usefulness might be more limited - but 
maybe
not. After all, there are still a whole lot of desktop based tools 
around.


But then you have apps like Microsoft Office where they have built a 
web
version and a Windows desktop version and a Mac OS desktop version. 
I have

no idea how much, if any, of that code is shared, but again, that is an
option that could be considered.

So again, before going down the rabbit hole of technology discussion,
what is the scope of what the next version of Chainsaw will be?  
Will it be
an upgraded version of the existing code base that uses something 
besides
Swing, will it be something else, or do we want multiple spin-off 
projects?


Ralph

Re: logging-log4j2 git commit: [LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling through Apache Commons DBCP 2.

[Mikael Ståldal]

As I wrote recently, I don't think that having a kitchen-sink plugins 
repository is a good way to solve this. Eventually that repository will 
get too big.


It's better to create a new repository for each new module (or possibly 
for a couple of related modules, but they should be more related than 
just being Log4j plugins).



On 2018-01-19 06:31, Ralph Goers wrote:

Gary, I am complaining because I perform the releases. You never have. We keep 
adding more and more crap to the build and it keeps taking longer and longer. 
Af far as I am concerned that is a valid technical reason.

My -1 stands.

Ralph



On Jan 18, 2018, at 10:24 PM, Gary Gregory  wrote:

On Thu, Jan 18, 2018 at 10:20 PM, Ralph Goers 
wrote:


OK, but that doesn’t resolve the initial problem. The log4j 2 project is
too large.



 From what I've experienced, folks complain about the size of the api and
core jars, not the Maven project.

What is the target size/metric if it is currently "too large"? ;-)

Gary



Ralph


On Jan 18, 2018, at 10:15 PM, Gary Gregory 

wrote:


On Thu, Jan 18, 2018 at 9:43 PM, Ralph Goers 

wrote:


-1

Please revert and move this to the log4j plugins project.

Ralph


On Jan 18, 2018, at 8:54 PM, ggreg...@apache.org wrote:

Repository: logging-log4j2
Updated Branches:
refs/heads/master bb6fcd09e -> 639f093b8


[LOG4J2-2186] Add a JDBC ConnectionSource that provides pooling

through

Apache Commons DBCP 2.

Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/

commit/639f093b

Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/

639f093b

Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/

639f093b


Branch: refs/heads/master
Commit: 639f093b8103df2c2eda8d62fd12d7619d98ac04
Parents: bb6fcd0
Author: Gary Gregory 
Authored: Thu Jan 18 20:54:47 2018 -0700
Committer: Gary Gregory 
Committed: Thu Jan 18 20:54:47 2018 -0700



--

log4j-jdbc-dbcp2/pom.xml| 170

+++

.../db/jdbc/PoolingDriverConnectionSource.java  | 155

+

log4j-jdbc-dbcp2/src/site/manual/index.md   |  35 
log4j-jdbc-dbcp2/src/site/site.xml  |  52 ++
.../jdbc/PoolingDriverConnectionSourceTest.java |  96 +++
pom.xml |   1 +
src/changes/changes.xml |   3 +
src/site/xdoc/manual/appenders.xml  |  28 ++-
8 files changed, 537 insertions(+), 3 deletions(-)


--



http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/

639f093b/log4j-jdbc-dbcp2/pom.xml



--

diff --git a/log4j-jdbc-dbcp2/pom.xml b/log4j-jdbc-dbcp2/pom.xml
new file mode 100644
index 000..18e0e86
--- /dev/null
+++ b/log4j-jdbc-dbcp2/pom.xml
@@ -0,0 +1,170 @@
+
+
+
+http://maven.apache.org/POM/4.0.0; xmlns:xsi="

http://www.w3.org/2001/XMLSchema-instance;

+  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

http://maven.apache.org/xsd/maven-4.0.0.xsd;>

+  
+org.apache.logging.log4j
+log4j
+2.10.1-SNAPSHOT
+  
+  4.0.0
+
+  log4j-jdbc-dbcp2
+  Apache Log4j JDBC DBCP 2
+  
+Connection source for the JDBC Appender using on Apache Commons

DBCP 2.

+  
+  
+${basedir}/..
+Log4j JDBC DBCP 2 Documentation
+/log4j-jdbc-dbcp2
+org.apache.logging.log4j.jdbc.dbcp2
+  
+
+  
+
+  org.apache.logging.log4j
+  log4j-core
+
+
+  org.apache.commons
+  commons-dbcp2
+  2.2.0
+
+
+
+  junit
+  junit
+
+
+  org.apache.logging.log4j
+  log4j-api
+  test-jar
+
+
+  org.apache.logging.log4j
+  log4j-core
+  test-jar
+
+
+  com.h2database
+  h2
+  test
+
+  
+
+  
+
+  
+org.apache.felix
+maven-bundle-plugin
+
+  
+org.apache.logging.log4j.core.appender.

db.jdbc

+*
+  
+
+  
+
+  
+  
+
+  
+org.apache.maven.plugins
+maven-changes-plugin
+${changes.plugin.version}
+
+  
+
+  changes-report
+
+  
+
+
+  

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

[Mikael Ståldal]

Well, that's a decision we have to make. So far, logging-log4j-plugins 
has not been released yet, so we are now free do decide how to do it.


I guess that logging-log4j-plugins over time will contain a diverse set 
of appenders, layouts and other plugins for Log4j 2, each one in its own 
Maven module. Those plugins will normally not be releated to each other.


I can see some advantages, and some disadvantages, with versioning and 
releasing plugins independently from core.


But to gain those advantages, each plugin should have it's own version 
and release schedule. To have one version/release for all plugins (but 
different from core) does not make sense to me, it will give us all 
disadvantages, but few of the advantages.


When thinking about it, it's probably not even a good idea to have
a logging-log4j-plugins repository in the first place. Instead we should 
create a new repository for each new plugin. And have a way to quickly 
bootstrap such reposisory with needed boilerplate, maybe with a Maven 
archetype.


And since we haven't started using the logging-log4j-plugins repository 
yet, we have the oppourtunity to do it differently.



On 2018-01-17 00:34, Ralph Goers wrote:

Because logging-log4j-plugins is released separately from logging-log4j2 and 
the versions would not line up.

Ralph


On Jan 16, 2018, at 2:31 PM, Mikael Ståldal <mi...@apache.org> wrote:

Why do we need to change the version number?

On 2018-01-14 22:11, Ralph Goers wrote:

I don’t believe the components listed in the subject line should be part of the 
main flume build and would like to see them moved to the logging-log4j-plugins 
project. The only problem is that the modules and maven coordinates need to 
change since the version numbers will be going backwards. I would propose we 
solve that by adding “plugin” to the jar names.

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

[Mikael Ståldal]

I originally developed log4j-liquibase. I have not used it or Liquibase 
itself for quite some time now.


It might be so that the next version of Liquibase will make that module 
obsolete. But maybe we should keep it around at least until such new 
version of Liquibase is released?



On 2018-01-15 05:51, Ralph Goers wrote:

You are correct. And after looking at the class and at Liquibase master this 
code is now completely broken and should be dropped. 3.5.3 is the latest 
Liquibase release and the code possibly still works with that, although the 
unit tests certainly don’t prove that. But the code in master has been changed 
so that our code won’t compile. Liquibase in master is also hard-coded to use 
SLF4J.

I would suggest that whoever needs this should create a PR with Liquibase. I 
have no interest in keeping this component up to date.

Note that removing this would definitely necessitate a 2.11.0 release.

Ralph


On Jan 14, 2018, at 9:25 PM, Matt Sicker  wrote:

 From when I used log4j-liquibase in the past, it doesn't log _to_
liquibase; instead, it offers an implementation of its internal logger
logic which doesn't use any existing facade by default.

On 14 January 2018 at 17:14, Ralph Goers  wrote:


Ok.

If we do this we should release that before we remove them from a Log4J
release to minimize confusion.

Sent from my iPhone


On Jan 14, 2018, at 3:47 PM, Remko Popma  wrote:

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:


I don’t believe the components listed in the subject line should be

part of the main flume build and would like to see them moved to the
logging-log4j-plugins project. The only problem is that the modules and
maven coordinates need to change since the version numbers will be going
backwards. I would propose we solve that by adding “plugin” to the jar
names.


Ralph









--
Matt Sicker 

Re: MongoDB, Cassandra, CouchDB, Liquibase, Flume

[Mikael Ståldal]

Why do we need to change the version number?

On 2018-01-14 22:11, Ralph Goers wrote:

I don’t believe the components listed in the subject line should be part of the 
main flume build and would like to see them moved to the logging-log4j-plugins 
project. The only problem is that the modules and maven coordinates need to 
change since the version numbers will be going backwards. I would propose we 
solve that by adding “plugin” to the jar names.

Re: [Log4j] Binary layout

[Mikael Ståldal]

I am experimenting with an Avro layout:
https://github.com/apache/logging-log4j-plugins/tree/avro-layout

It happens to be the case that the generated Avro value class implements 
Serializable, but is it appropriate to return that? Or should it return 
null? What if you want to make another binary layout, and no such 
Serializable class exist?


Maybe the Layout.toSerializable method should be documented to allow 
null return, and all call sites adapted to handle that it returns null 
(unless they assume a specific layout)?



On 2018-01-16 17:35, Ralph Goers wrote:

Well, in looking at the various uses of that method I am a bit confused.
1. The JMSAppender will use Java serialization if it isn’t a MapMessage or a 
String.
2. CassandraManager uses some sort of TypeConverter to convert the Serializable 
- but it only seems to handle a limited set of types. For example, using a 
LogEventProxy will result in a null value being inserted.
3. NoSQLDatabaseManager only uses the serializable form if it is a MapMessage.
4. What JdbcDatabaseManager does seems to depend on what the column type is.

Those are pretty much the only usages I have seen. So what should be done 
depends on how it would apply to any one of those cases. I suspect you are 
correct Remko, and that it should just return the byte array.

Ralph


On Jan 16, 2018, at 8:38 AM, Remko Popma <remko.po...@gmail.com> wrote:

I think what Mikael meant is that Serializable is just a marker interface
that does not provide any guidance on what methods to call on it to turn
the result into bytes.
Unless we want to use java serialization, and I presume one of the main
reasons for creating a custom binary layout (other than performance) is to
avoid java serialization and the associated security risks.

How should a custom binary layout turn the result of `toSerializable` into
bytes without using java serialization? - may be the question that Mikael
is trying to answer. Correct me if I'm wrong,  Mikael.
I think a custom binary layout should just return the bytes it produced
itself. Either as a byte array or as a ByteBuffer.


On Wed, Jan 17, 2018 at 12:23 AM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:


I think MessageLayout is a special case as it only returns the message
portion of the LogEvent. Most Layouts return 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 <remko.po...@gmail.com> 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åldal <mi...@apache.org>

wrote:



How is a binary layout (extending AbstractLayout) supposed to implement
the toSerializable method in the Layout interface?

Why is that method there?

[Log4j] Binary layout

[Mikael Ståldal]

How is a binary layout (extending AbstractLayout) supposed to implement 
the toSerializable method in the Layout interface?


Why is that method there?

[Log4j] Release plan?

[Mikael Ståldal]

Will the next release be 2.10.1 or 2.11.0?

If 2.10.1, I start seeing a few new features in master branch that might 
not be appropriate for a patch release.

Re: [log4j] Move JDBC appender to own module?

[Mikael Ståldal]

As usual, I think we should avoid optional dependencies.


On 2018-01-13 10:16, Remko Popma wrote:

I meant to keep the jdbc and the generic db package together.

log4j-db:  generic db + jdbc
log4j-jpa: requires javax.persistance

We can also keep all of these in a single module `log4j-db` with an
optional dependency on javax.persistance.

More modules gives more flexibility but also more complexity, so I lean
towards keeping things together where possible until the flexibility is
really needed.

[Log4j] Messages and garbage free logging

[Mikael Ståldal]

In http://logging.apache.org/log4j/2.x/manual/messages.html we say:

"Although it may seem more expensive than passing the message format and 
parameters directly to the event, testing has shown that with modern 
JVMs the cost of creating and destroying events is minor, especially 
when complex tasks are encapsulated in the Message instead of the 
application."


This text was written back in 2012, and has not been changed since. 
Maybe this text should be adjusted due to the introduction of garbage 
free logging?


I just fixed a few other minor obsolete things in that file.

Re: Event batch

[Mikael Ståldal]

And 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 follow immediately and it will set the `endOfBatch` 
attribute accordingly. Appenders downstream from the async logging queue will 
flush their buffer when they see the end of a batch.

Re: Event batch

[Mikael Ståldal]

I guess that you are supposed to use LogEvent.isEndOfBatch() to know 
when to flush log events to final destination.


Our file and stream based appenders do that. See 
https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/RandomAccessFileAppender.java#L156



On 2018-01-09 14:46, Apache wrote:

The Logging api only allows you to log a single event at a time so it doesn’t 
make sense for an appender to have a method that accepts multiple events since 
it can’t happen. That said, appenders can queue the events and send them 
downstream in batches. I believe some of the appenders do that now.

Is there some use case I am not aware of where this method could be called?

Ralph


On Jan 9, 2018, at 6:02 AM, Jochen Wiedmann  wrote:

Hi,

currently writing my first appender, and wondering about the following:

The Appender interface specifies a method for logging a single event.
However, my custom Appender would greatly benefit in terms of
performance, if I could implement an additional method
append(LogEvent[] events). Now, I wonder if such batching has been
omitted from the API intentionally. Or, alternatively, if I might
replace my custom logger with a modified instance of AsyncAppender?

Re: [log4j] and Apache HttpClient

[Mikael Ståldal]

I think that we should at least make a release with fix for 
https://issues.apache.org/jira/browse/LOG4J2-2126 before we try to 
convince anyone to use Log4j for something which might be used on Android.



On 2018-01-08 16:37, Gary Gregory wrote:

Hi All:

Over on the d...@hc.apache.org list, we have a thread called "Using SLF4J as
a logging facade; Re: Disagreement on Log4J2" where Oleg (our lead and main
author) has proposed moving from Log4j2 to SLF4J for the next HttpClient
Alpha.

(I had initially switched HC from Commons Logging to Log4j 2)

Android is the main contention. The size of the API is another but we
cannot do anything about that.

Your comments to at least provide direction and expectations would be most
welcome.

Thank you,
Gary

Re: [jira] [Commented] (LOG4J2-2162) KafkaAppender fails application startup when bootstrap server are not available

[Mikael Ståldal]

Do we have a generic way of doing this, so you don't have to implement 
the same for every appender?



On 2018-01-03 18:58, Gary Gregory (JIRA) wrote:

Gary Gregory commented on LOG4J2-2162:
--

We need the same kind of reconnect logic the JMS Appender uses here. I am 
likely to need this soon as well...


KafkaAppender fails application startup when bootstrap server are not available
---

 Key: LOG4J2-2162
 URL: https://issues.apache.org/jira/browse/LOG4J2-2162
 Project: Log4j 2
  Issue Type: Bug
  Components: Appenders
Affects Versions: 2.8.2, 2.10.0
 Environment: Tried on Windows 10, IDE Eclipse Oxygen
Reporter: Shwetank Sharma
  Labels: kafka, newbie
 Attachments: log4j2.xml


When the server mentioned in bootstrap.servers property in kafka appender are 
not available.
For e.g. Unable to resolve DNS etc.
The application isn't starting and the java process terminates after trying to 
connect to the server.
Failure to initialize the appender should not block the application process and 
other appenders, just like file appender, for e.g. when file path is not 
resolvable, it moves forward.
Attached log4j2.xml.
Tried wrapping it in async appender as well, does not provide expected result 
as the issue is with initialization of appender.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [log4j] providing sourcewith Message

[Mikael Ståldal]

ebug(final Marker marker, final String

message)

{

logIfEnabled(getCaller(), Level.DEBUG, marker,

message,

(Throwable)

null);
}
instead of the current
public void debug(final Marker marker, final String

message)

{

logIfEnabled(FQCN, Level.DEBUG, marker, message,

(Throwable)

null);

}
But the amount of changes required to get it into the

LogEvent

was

large.

OTOH, if we create a CallerLocationMessage that

contains

the

StackTraceElement and then have existing Messages

extend

that

then we

could

store the location in the Message if it is a

CallerLocationMessage.

Calling

getCaller() in this way would be much better since it

is

at a

fixed

depth

from the caller.

With Java 9 this could become:
public void debug(final Marker marker, final String

message)

{

logIfEnabled(stackWalker.walk(

s->s.skip(1).findFirst(),

Level.DEBUG,

marker, message, (Throwable) null);
}
although that would pass a StackFrame instead of a

StackTraceElement.

The

only problems with this is that there is still some

overhead

in

calling

StackWalker like this. Also, if this is called from a

facade,

such as

log4j-slf4j-impl then the number of levels that have to

be

skipped

would

be

different.

I would really prefer if there was some way to capture

the

line

number

information for the various loggers when the annotation

processor

runs

at

compile time.

Ralph


On Dec 9, 2017, at 1:22 PM, Jeffrey Shaw <

shawj...@gmail.com



wrote:


Thanks for the link, Mikael. I'll take a look at it.

I added some plumbing to core to allow clients to

pass

a

StackTraceElement

to loggers. I'd like a code review. I'm happy to try

other

methods.

See

the

following commit.
https://github.com/shawjef3/logging-log4j2/commit/

9c42073e9ca4f25a2f4075b1791eee2893534c54


On Sat, Dec 9, 2017 at 10:09 AM, Mikael Ståldal <

mi...@apache.org>

wrote:



Have you tried the Log4j Scala API?

http://logging.apache.org/

log4j/2.x/manual/scala-api.

html


It does currently not support this, but it uses

Scala

macros, and

this

could be added there. But log4j-api and/or

log4j-core

probably

needs

to

adapted as well.



On 2017-12-09 07:30, Jeffrey Shaw wrote:


Hello,
I've found that I am able to use Scala macros to

provide

compile-time

source information for log messages. However, I

don't

see

a way

to

inject

this into log4j's logging mechanism.

I'm wondering if there is something I'm missing, or

if

LogEvent's

getSource
method could be duplicated in Message.

We could then have zero-overhead location

information

in

logs.

I'm

thinking
that tools other than Scala could also take

advantage

of

this.













--
Matt Sicker <boa...@gmail.com>







--
Matt Sicker <boa...@gmail.com>










--
Matt Sicker <boa...@gmail.com>









--
Matt Sicker <boa...@gmail.com>

Re: [log4j] release 2.10.1

[Mikael Ståldal]

Yes, it does.

On 2017-12-23 17:39, Ralph Goers wrote:

I am using the same version of Maven and Java. Does your reactor order match 
mine?

Re: [log4j] release 2.10.1

[Mikael Ståldal]

I just tried with latest master. No errors in log4j-api, but in log4j-osgi:


$ mvn -v
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T17:41:47+01:00)

Maven home: /opt/apache-maven-3.3.9
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: /opt/jvm/jdk1.8.0_144/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.10.0-42-generic", arch: "amd64", family: 
"unix"



$ mvn clean install

[ERROR] Tests run: 5, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 
2.051 s <<< FAILURE! - in 
org.apache.logging.log4j.osgi.tests.felix.FelixLoadApiBundleTest
[ERROR] 
testMissingImportOfCoreOsgiPackage(org.apache.logging.log4j.osgi.tests.felix.FelixLoadApiBundleTest) 
 Time elapsed: 0.408 s  <<< ERROR!
org.osgi.framework.BundleException: Unable to cache bundle: 
file:///home/mikes/programproject/logging-log4j2/log4j-samples/configuration/target/log4j-samples-configuration-2.10.1-SNAPSHOT.jar
Caused by: java.io.FileNotFoundException: 
/home/mikes/programproject/logging-log4j2/log4j-samples/configuration/target/log4j-samples-configuration-2.10.1-SNAPSHOT.jar 
(No such file or directory)


[ERROR] 
testSimpleLogInAnOsgiContext(org.apache.logging.log4j.osgi.tests.felix.FelixLoadApiBundleTest) 
 Time elapsed: 0.063 s  <<< ERROR!
org.osgi.framework.BundleException: Unable to cache bundle: 
file:///home/mikes/programproject/logging-log4j2/log4j-samples/configuration/target/log4j-samples-configuration-2.10.1-SNAPSHOT.jar
Caused by: java.io.FileNotFoundException: 
/home/mikes/programproject/logging-log4j2/log4j-samples/configuration/target/log4j-samples-configuration-2.10.1-SNAPSHOT.jar 
(No such file or directory)


WARNING: sun.reflect.Reflection.getCallerClass is not supported. This 
will impact performance.
ERROR StatusLogger No log4j2 configuration file found. Using default 
configuration: logging only errors to the console. Set system property 
'log4j2.debug' to show Log4j2 internal initialization logging.
[ERROR] Tests run: 5, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 
2.095 s <<< FAILURE! - in 
org.apache.logging.log4j.osgi.tests.equinox.EquinoxLoadApiBundleTest
[ERROR] 
testMissingImportOfCoreOsgiPackage(org.apache.logging.log4j.osgi.tests.equinox.EquinoxLoadApiBundleTest) 
 Time elapsed: 0.635 s  <<< ERROR!

org.osgi.framework.BundleException: Error reading bundle content.
Caused by: java.io.FileNotFoundException: 
/home/mikes/programproject/logging-log4j2/log4j-samples/configuration/target/log4j-samples-configuration-2.10.1-SNAPSHOT.jar 
(No such file or directory)


[ERROR] 
testSimpleLogInAnOsgiContext(org.apache.logging.log4j.osgi.tests.equinox.EquinoxLoadApiBundleTest) 
 Time elapsed: 0.037 s  <<< ERROR!

org.osgi.framework.BundleException: Error reading bundle content.
Caused by: java.io.FileNotFoundException: 
/home/mikes/programproject/logging-log4j2/log4j-samples/configuration/target/log4j-samples-configuration-2.10.1-SNAPSHOT.jar 
(No such file or directory)


[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] 
EquinoxLoadApiBundleTest>AbstractLoadBundleTest.testMissingImportOfCoreOsgiPackage:239->AbstractLoadBundleTest.getDummyBundle:81 
» Bundle
[ERROR] 
EquinoxLoadApiBundleTest>AbstractLoadBundleTest.testSimpleLogInAnOsgiContext:269->AbstractLoadBundleTest.getDummyBundle:81 
» Bundle
[ERROR] 
FelixLoadApiBundleTest>AbstractLoadBundleTest.testMissingImportOfCoreOsgiPackage:239->AbstractLoadBundleTest.getDummyBundle:81 
» Bundle
[ERROR] 
FelixLoadApiBundleTest>AbstractLoadBundleTest.testSimpleLogInAnOsgiContext:269->AbstractLoadBundleTest.getDummyBundle:81 
» Bundle

[INFO]
[ERROR] Tests run: 10, Failures: 0, Errors: 4, Skipped: 0

[Log4j] Incorrect information about markers in SLF4J documentation

[Mikael Ståldal]

I just realized that the documentation for SLF4J contain incorrect 
information about markers:


https://www.slf4j.org/faq.html#marker_interface
https://www.slf4j.org/faq.html#fatal

It says that only Logback support markers, while in fact Log4j 2 also 
supports it.


Maybe we should report a bug? https://www.slf4j.org/faq.html#fatal

Re: [Log4j] Next release?

[Mikael Ståldal]

Not at the moment.


On 2017-12-11 20:02, Ralph Goers wrote:

It will be 2.10.1 unless we have new features to add that warrant a minor 
version bump.  Do you have new features to add?

Ralph



On Dec 11, 2017, at 11:54 AM, Mikael Ståldal <mi...@apache.org> wrote:

Do we plan to do a 2.10.1, or will next release be 2.11.0?

[Log4j] Next release?

[Mikael Ståldal]

Do we plan to do a 2.10.1, or will next release be 2.11.0?

Re: [log4j] providing sourcewith Message

[Mikael Ståldal]

Have you tried the Log4j Scala API?

http://logging.apache.org/log4j/2.x/manual/scala-api.html

It does currently not support this, but it uses Scala macros, and this 
could be added there. But log4j-api and/or log4j-core probably needs to 
adapted as well.



On 2017-12-09 07:30, Jeffrey Shaw wrote:

Hello,
I've found that I am able to use Scala macros to provide compile-time
source information for log messages. However, I don't see a way to inject
this into log4j's logging mechanism.

I'm wondering if there is something I'm missing, or if LogEvent's getSource
method could be duplicated in Message.

We could then have zero-overhead location information in logs. I'm thinking
that tools other than Scala could also take advantage of this.

Re: [jira] [Resolved] (LOG4J2-2146) The maven bundle plugin fails due to Java 9

[Mikael Ståldal]

This used to be very annoying, and now it works fine.

Thanks Ralph!


On 2017-12-07 07:41, Ralph Goers (JIRA) wrote:


  [ 
https://issues.apache.org/jira/browse/LOG4J2-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-2146.
-
Resolution: Fixed
 Fix Version/s: 2.10.1


The maven bundle plugin fails due to Java 9
---

 Key: LOG4J2-2146
 URL: https://issues.apache.org/jira/browse/LOG4J2-2146
 Project: Log4j 2
  Issue Type: Improvement
  Components: API
Affects Versions: 2.10.0
Reporter: Ralph Goers
 Fix For: 2.10.1


The Log4j2 API build fails if the clean lifecycle is not specified. This is 
because of problems in the Maven Bundle Plugin. The latest version of the 
plugin does not ignore module-info.class and the bnd tool does not ignore 
classes in META-INF/versions.

Re: [Log4j] Header/footer and thread context

[Mikael Ståldal]

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 multiple SmtpAppenders). This is very confusing.


This feature was apparently added as part of 
https://issues.apache.org/jira/browse/LOG4J2-1192 by Gary. And I see now 
in the JIRA discussion that someone noticed this odd behaviour already.


We should fix this, I reopened LOG4J2-1192.

(You don't have to use ThreadContext, or async appender/logger to get 
this confusing behaviour.)



On 2017-12-03 12:54, Mikael Ståldal wrote:
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 need to document this, 
and make the behaviour consistent (i.e. it should not work for sync 
logging either, which it by accident do now).



On 2017-11-30 23:35, Remko Popma wrote:
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 consistent.


(Shameless plug) Every java main() method deserves http://picocli.info


On Dec 1, 2017, at 6:05, Matt Sicker <boa...@gmail.com> wrote:

I'm not sure if this use case makes much sense. Dynamic data like that
makes more sense in the message itself, though I'm sure there are 
several

ways to do this.


On 30 November 2017 at 15:02, Mikael Ståldal <mi...@apache.org> wrote:

I am looking at https://issues.apache.org/jira/browse/LOG4J2-2007

What is the expected behavior here? Should there be any thread 
context for

header/footer?

I guess it should be consistent for sync and async logging, which it 
isn't
right now. But maybe the async case is correct in not includin any 
thread

context in header/footer, and the sync case incorrect?

Re: [Log4j] Header/footer and thread context

[Mikael Ståldal]

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 need to document this, 
and make the behaviour consistent (i.e. it should not work for sync 
logging either, which it by accident do now).



On 2017-11-30 23:35, Remko Popma wrote:

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 
consistent.

(Shameless plug) Every java main() method deserves http://picocli.info


On Dec 1, 2017, at 6:05, Matt Sicker <boa...@gmail.com> wrote:

I'm not sure if this use case makes much sense. Dynamic data like that
makes more sense in the message itself, though I'm sure there are several
ways to do this.


On 30 November 2017 at 15:02, Mikael Ståldal <mi...@apache.org> wrote:

I am looking at https://issues.apache.org/jira/browse/LOG4J2-2007

What is the expected behavior here? Should there be any thread context for
header/footer?

I guess it should be consistent for sync and async logging, which it isn't
right now. But maybe the async case is correct in not includin any thread
context in header/footer, and the sync case incorrect?

Re: SLF4J now requires Java 6

[Mikael Ståldal]

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?

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

[Mikael Ståldal]

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 in the API. Even if we did that it still would not work in 
Android so long as the API contains module-info.java, because that class can 
only be compiled for Java 9.  So there really is no way to provide decent 
support for Java 9 and android at the same time.

According to Gary’s findings, even if HttpClient switches to SLF4J they are 
going to be in the same boat with the 1.8.x releases.

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

[Mikael Ståldal]

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 
solved first.

Re: [Log4j] Apache HttpClient 5, Log4j and Slf4j

[Mikael Ståldal]

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 regular users to need a compile dependency on log4j-core 
anyway.


So I don't have an easy solution to fix it now, this is more a 
retrospective to figure out why we ended up in this unfourtate 
situation, and how do avoid that happening again in the future.


If I were to redesign Log4j 2 from scratch, I would consider not putting 
this into log4j-api:


- All classes in org.apache.logging.log4j.message (only the interfaces 
in API, except ReusableMessage and ThreadInformation)

- Most (or ideally all) stuff in org.apache.logging.log4j.spi
- The org.apache.logging.log4j.status package
- Most (or ideally all) stuff in org.apache.logging.log4j.util (since 
they would not be needed anymore)


Some of it would go into log4j-core, some into a new log4j-spi module.

I think that the growing-out-of-bounds started with the garbage-free epic.

log4j-api.jar is now 249 KB, slf4j-api.jar is 41 KB.


On 2017-12-02 15:34, Remko Popma wrote:

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.

[Log4j] Header/footer and thread context

[Mikael Ståldal]

I am looking at https://issues.apache.org/jira/browse/LOG4J2-2007

What is the expected behavior here? Should there be any thread context 
for header/footer?


I guess it should be consistent for sync and async logging, which it 
isn't right now. But maybe the async case is correct in not includin any 
thread context in header/footer, and the sync case incorrect?

[Log4j] Closing resolved JIRA issues

[Mikael Ståldal]

How should we handle closing of resolved JIRA issues?

Idealy, the original reporter should close after verifying, but quite 
often they never do.


I usually close the resolved issues I am assigned to shortly after it is 
released. I just did with a bunch of issues released with 2.10.0.

Re: [Log4j] Wrong version of Scala API in documentation

[Mikael Ståldal]

Nice, done.

On 2017-11-25 17:52, Ralph Goers wrote:

You can also directly fix the web site. See 
https://wiki.apache.org/logging/ManagingTheWebSite 
<https://wiki.apache.org/logging/ManagingTheWebSite>. You only need to check 
out the log4j directory and the specific version you want to modify.

Ralph


On Nov 25, 2017, at 7:52 AM, Mikael Ståldal <mi...@apache.org> wrote:

This page: https://logging.apache.org/log4j/2.x/maven-artifacts.html

instructs users to use version 2.10.0 of the Scala API, which is wrong, it 
doesn't exist. It should be 11.0.

I have fixed it in Git master.

Re: [Log4j] ProcessIdUtil

[Mikael Ståldal]

I suggest that next time we want to add a Java 9 version of something 
not actuallly used in log4j-api, we create a Java 9 version of 
log4j-core and put it there.



On 2017-11-25 17:53, Ralph Goers wrote:

It is there because there is a Java 9 version of it and I did not want to make 
multiple Java 9 modules.

Ralph


On Nov 25, 2017, at 7:54 AM, Mikael Ståldal <mi...@apache.org> wrote:

Regarding https://issues.apache.org/jira/browse/LOG4J2-2126

Why is ProcessIdUtil in log4j-api in the first place? It is only used from 
log4j-core. Can't we move it to log4j-core?

I think that in general, we have too much things in log4j-api, and that causes 
problems like this.

Re: Build failed in Jenkins: Log4j 2.x #3197

[Mikael Ståldal]

What does this mean? Is this a problem in our build, or a temporary 
infrastructure problem?



On 2017-11-25 16:01, Apache Jenkins Server wrote:

ERROR: Failed to deploy metadata: Could not transfer metadata 
org.apache.logging.log4j:log4j-osgi:2.10.1-SNAPSHOT/maven-metadata.xml from/to 
apache.snapshots.https 
(https://repository.apache.org/content/repositories/snapshots): Failed to 
transfer file: 
https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-osgi/2.10.1-SNAPSHOT/maven-metadata.xml.
 Return code is: 400, ReasonPhrase: Bad Request.
org.apache.maven.artifact.deployer.ArtifactDeploymentException: Failed to 
deploy metadata: Could not transfer metadata 
org.apache.logging.log4j:log4j-osgi:2.10.1-SNAPSHOT/maven-metadata.xml from/to 
apache.snapshots.https 
(https://repository.apache.org/content/repositories/snapshots): Failed to 
transfer file: 
https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-osgi/2.10.1-SNAPSHOT/maven-metadata.xml.
 Return code is: 400, ReasonPhrase: Bad Request.
at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:143)
at 
hudson.maven.reporters.MavenArtifactRecord.deploy(MavenArtifactRecord.java:208)
at hudson.maven.RedeployPublisher.perform(RedeployPublisher.java:176)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:736)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:682)
at 
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1073)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:627)
at hudson.model.Run.execute(Run.java:1762)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:419)
Caused by: org.eclipse.aether.deployment.DeploymentException: Failed to deploy 
metadata: Could not transfer metadata 
org.apache.logging.log4j:log4j-osgi:2.10.1-SNAPSHOT/maven-metadata.xml from/to 
apache.snapshots.https 
(https://repository.apache.org/content/repositories/snapshots): Failed to 
transfer file: 
https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-osgi/2.10.1-SNAPSHOT/maven-metadata.xml.
 Return code is: 400, ReasonPhrase: Bad Request.
at 
org.eclipse.aether.internal.impl.DefaultDeployer.deploy(DefaultDeployer.java:348)
at 
org.eclipse.aether.internal.impl.DefaultDeployer.deploy(DefaultDeployer.java:245)
at 
org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:420)
at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:139)
... 11 more
Caused by: org.eclipse.aether.transfer.MetadataTransferException: Could not 
transfer metadata 
org.apache.logging.log4j:log4j-osgi:2.10.1-SNAPSHOT/maven-metadata.xml from/to 
apache.snapshots.https 
(https://repository.apache.org/content/repositories/snapshots): Failed to 
transfer file: 
https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-osgi/2.10.1-SNAPSHOT/maven-metadata.xml.
 Return code is: 400, ReasonPhrase: Bad Request.
at 
org.eclipse.aether.connector.basic.MetadataTransportListener.transferFailed(MetadataTransportListener.java:43)
at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355)
at 
org.eclipse.aether.connector.basic.BasicRepositoryConnector.put(BasicRepositoryConnector.java:288)
at 
org.eclipse.aether.internal.impl.DefaultDeployer.deploy(DefaultDeployer.java:342)
... 14 more
Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer 
file: 
https://repository.apache.org/content/repositories/snapshots/org/apache/logging/log4j/log4j-osgi/2.10.1-SNAPSHOT/maven-metadata.xml.
 Return code is: 400, ReasonPhrase: Bad Request.
at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:635)
at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:557)
at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:539)
at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:533)
at 
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:513)
at 
org.eclipse.aether.transport.wagon.WagonTransporter$PutTaskRunner.run(WagonTransporter.java:644)
at 

[Log4j] ProcessIdUtil

[Mikael Ståldal]

Regarding https://issues.apache.org/jira/browse/LOG4J2-2126

Why is ProcessIdUtil in log4j-api in the first place? It is only used 
from log4j-core. Can't we move it to log4j-core?


I think that in general, we have too much things in log4j-api, and that 
causes problems like this.

[Log4j] Wrong version of Scala API in documentation

[Mikael Ståldal]

This page: https://logging.apache.org/log4j/2.x/maven-artifacts.html

instructs users to use version 2.10.0 of the Scala API, which is wrong, 
it doesn't exist. It should be 11.0.


I have fixed it in Git master.

Re: [Chainsaw] Next step: Log4j 2

[Mikael Ståldal]

On 2017-11-21 17:06, Matt Sicker wrote:

This could present an opportunity to standardize some of the log4j-core
APIs that other applications may need as well.


Sounds like a good idea.

Re: [Chainsaw] Next step: Log4j 2

[Mikael Ståldal]

Could you go through the Chainsaw codebase and remove all unused/ 
obsolete stuff in there?


Preferrably also stuff that will be obsolete when we have migrated to 
away from Log4j 1.


In a separate branch for now.


On 2017-11-20 23:17, Scott Deboy wrote:

Awesome!

Re: appenders:

We went through a couple of code re-orgs back in 2011 and 2013, some
stuff was moved out of Chainsaw to apache-log4j-extras.  Looks like
some was left behind.

You can define Chainsaw as an appender yourself - so the UI starts if
it's in the log4j xml config file.

Because Chainsaw is an appender itself (a graphical one), Chainsaw
hooks in to the existing log4j configuration dynamically as an
appender to receive events, and we use that plumbing to process all
events received by a Receiver.

After building a LoggingEvent from the source, a Receiver pushes the
event to the appender framework by calling:

 // get the "local" logger for this event from the
 // configured repository.
 Logger localLogger =
 getLoggerRepository().getLogger(event.getLoggerName());

 // if the logger level is greater or equal to the level
 // of the event, use the logger to append the event.
 if (event.getLevel()
 .isGreaterOrEqual(localLogger.getEffectiveLevel())) {
 // call the loggers appenders to process the event
 localLogger.callAppenders(event);
 }
   }


Scott

Re: [Chainsaw] Next step: Log4j 2

[Mikael Ståldal]

I also think that we shouldn't consider Chainsaw to be part of, or a 
subproject of, Log4j. It should be its own project (within Apache 
Logging Services).


And we should try to not couple it too tightly with Log4j 2. It can 
depend on both log4j-api and log4j-core, and use classes like LogEvent 
from log4j-core. But maybe we should try to avoid using the 
configuration framework in log4j-core (the fact that it now uses the 
configuration framework in Log4j 1 makes it considerably harder to 
migrate away from it).



On 2017-11-20 21:41, Mikael Ståldal wrote:
I took a look at the Chainsaw source code, and tried to remove its 
dependency on Log4j 1 and migrate to Log4j 2.


That was not easy, Chainsaw heavily depends on intricate Log4j 1 
implementation details. There is a lot of tedious but straight-forward 
search/replace kind of work to do. But quite some more tricky stuff 
which I couldn't figure out all of.


I haven't yet got it to compile, and I got tired of it for the moment. 
But I have pushed my (unfinished) work to branch "log4j-2".


Maybe we need to take another apporach. There seems to be quote some 
code there which is more or less unused, like all those Appenders (why 
does Chainsaw need appenders? shouldn't it receive log events?).


Maybe we should try to clean up the current codebase and remove as much 
unused and obsolete stuff (stuff that will be obsolete when we have 
migrated to Log4j 2) as possible before migrating?

Re: [Chainsaw] Next step: Log4j 2

[Mikael Ståldal]

But what about DBAppender, MulticastAppender, etc? Are those needed in 
the Chainsaw codebase?



On 2017-11-20 23:17, Scott Deboy wrote:

Awesome!

Re: appenders:

We went through a couple of code re-orgs back in 2011 and 2013, some
stuff was moved out of Chainsaw to apache-log4j-extras.  Looks like
some was left behind.

You can define Chainsaw as an appender yourself - so the UI starts if
it's in the log4j xml config file.

Because Chainsaw is an appender itself (a graphical one), Chainsaw
hooks in to the existing log4j configuration dynamically as an
appender to receive events, and we use that plumbing to process all
events received by a Receiver.

After building a LoggingEvent from the source, a Receiver pushes the
event to the appender framework by calling:

 // get the "local" logger for this event from the
 // configured repository.
 Logger localLogger =
 getLoggerRepository().getLogger(event.getLoggerName());

 // if the logger level is greater or equal to the level
 // of the event, use the logger to append the event.
 if (event.getLevel()
 .isGreaterOrEqual(localLogger.getEffectiveLevel())) {
 // call the loggers appenders to process the event
 localLogger.callAppenders(event);
 }
   }


Scott


On 11/20/17, Mikael Ståldal <mi...@apache.org> wrote:

I took a look at the Chainsaw source code, and tried to remove its
dependency on Log4j 1 and migrate to Log4j 2.

That was not easy, Chainsaw heavily depends on intricate Log4j 1
implementation details. There is a lot of tedious but straight-forward
search/replace kind of work to do. But quite some more tricky stuff
which I couldn't figure out all of.

I haven't yet got it to compile, and I got tired of it for the moment.
But I have pushed my (unfinished) work to branch "log4j-2".

Maybe we need to take another apporach. There seems to be quote some
code there which is more or less unused, like all those Appenders (why
does Chainsaw need appenders? shouldn't it receive log events?).

Maybe we should try to clean up the current codebase and remove as much
unused and obsolete stuff (stuff that will be obsolete when we have
migrated to Log4j 2) as possible before migrating?

Re: [Chainsaw] Next step: Log4j 2

[Mikael Ståldal]

We should complete the release of the current code before merging any of 
this stuff, but we can start this work in a branch while waiting for the 
release.



On 2017-11-20 21:41, Mikael Ståldal wrote:
I took a look at the Chainsaw source code, and tried to remove its 
dependency on Log4j 1 and migrate to Log4j 2.


That was not easy, Chainsaw heavily depends on intricate Log4j 1 
implementation details. There is a lot of tedious but straight-forward 
search/replace kind of work to do. But quite some more tricky stuff 
which I couldn't figure out all of.


I haven't yet got it to compile, and I got tired of it for the moment. 
But I have pushed my (unfinished) work to branch "log4j-2".


Maybe we need to take another apporach. There seems to be quote some 
code there which is more or less unused, like all those Appenders (why 
does Chainsaw need appenders? shouldn't it receive log events?).


Maybe we should try to clean up the current codebase and remove as much 
unused and obsolete stuff (stuff that will be obsolete when we have 
migrated to Log4j 2) as possible before migrating?

Re: [VOTE] Release Log4j 2.10.0-rc1

[Mikael Ståldal]

It is. But how common is it that people download the source of a 
particular release? I think that most people either download the binary 
artifacts, or build the source from latest master branch (and there it 
is already fixed).


Maybe we can include something about this in the release notes, that 
this unit test might fail in Windows.


It is unfourtante that our release process is so heavy that it takes ~1 
hour to make another RC, but that's the way it (currently) is.



On 2017-11-20 20:33, Gary Gregory wrote:

It's just lame that if someone downloads the source they cannot even build
it :-(

Gayr

On Mon, Nov 20, 2017 at 2:28 PM, Mikael Ståldal <mi...@apache.org> wrote:


I agree with Ralph.

On 2017-11-20 20:03, Ralph Goers wrote:


Unless you find something else I am not inclined to rerun the release
just to fix a unit test where we know what the problem is and that has no
impact on the code customers use.

Ralph

On Nov 20, 2017, at 11:56 AM, Gary Gregory <garydgreg...@gmail.com>

wrote:

On Mon, Nov 20, 2017 at 10:43 AM, Gary Gregory <garydgreg...@gmail.com>
wrote:

Here it is:


[ERROR] Tests run: 13, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
1.469 s <<< FAILURE! - in org.apache.log4j.config.
Log4j1ConfigurationFactoryTest
[ERROR] testSystemProperties1(org.apache.log4j.config.
Log4j1ConfigurationFactoryTest)  Time elapsed: 0.027 s  <<< ERROR!
java.nio.file.FileSystemException:
C:\Users\ggregory\AppData\Local\Temp\hadoop.log: The process cannot
access the file because it is being used by another process.

 at org.apache.log4j.config.Log4j1ConfigurationFactoryTest
.testSystemProperties1(Log4j1ConfigurationFactoryTest.java:173)


I think Remko fixed that in master.



Building master with 'mvn clean install' passes so I would prefer another
RC that picks up Remko's fix.

Gary



Gary

On Mon, Nov 20, 2017 at 9:41 AM, Gary Gregory <garydgreg...@gmail.com>
wrote:

Wow,


Now I get a different failure. I had run the build in Windows but from
the git command line (MINGW64). That that I run from a "real" Windows
command line I get:

[ERROR] Errors:
[ERROR]   Log4j1ConfigurationFactoryTest.testSystemProperties1:173 »
FileSystem C:\Users...
[INFO]
[ERROR] Tests run: 145, Failures: 0, Errors: 1, Skipped: 0
[INFO]

Gary

On Mon, Nov 20, 2017 at 4:40 AM, Remko Popma <remko.po...@gmail.com>
wrote:

Ran another build from the release tag, with Java 7. Build succeeds.


I'll look at the checksums and the site next.

Gary, could you run another clean build?
The error messages look strange: I cannot see any difference between
the
expected and the actual result in the error output...



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.7.0_55, vendor: Oracle Corporation
Java home: C:\apps\jdk1.7.0_55\jre
Default locale: en_US, platform encoding: MS932
OS name: "windows 8.1", version: "6.3", arch: "amd64", family:
"windows"

[INFO] Reactor Summary:
[INFO]
[INFO] Apache Log4j 2 . SUCCESS [
3.940 s]
[INFO] Apache Log4j API Java 9 support  SUCCESS [
12.324 s]
[INFO] Apache Log4j API ... SUCCESS [
36.662 s]
[INFO] Apache Log4j Core .. SUCCESS
[22:30
min]
[INFO] Apache Log4j Core Integration Tests  SUCCESS
[01:26
min]
[INFO] Apache Log4j 1.x Compatibility API . SUCCESS [
19.337 s]
[INFO] Apache Log4j SLF4J Binding . SUCCESS [
10.867 s]
[INFO] Apache Log4j to SLF4J Adapter .. SUCCESS [
5.751 s]
[INFO] Apache Log4j Commons Logging Bridge  SUCCESS [
5.527 s]
[INFO] Apache Log4j Flume Bridge .. SUCCESS [
35.251 s]
[INFO] Apache Log4j Web ... SUCCESS [
13.574 s]
[INFO] Apache Log4j Tag Library ... SUCCESS [
24.771 s]
[INFO] Apache Log4j JMX GUI ... SUCCESS [
2.966 s]
[INFO] Apache Log4j Samples ... SUCCESS [
0.846 s]
[INFO] Apache Log4j Samples: Flume - Common ... SUCCESS [
4.211 s]
[INFO] Apache Log4j Samples: Flume - Remote ... SUCCESS [
3.523 s]
[INFO] Apache Log4j Samples: Flume - Embedded . SUCCESS [
9.808 s]
[INFO] Apache Log4j Samples: Configuration  SUCCESS [
4.508 s]
[INFO] Apache Log4j Samples: LoggerProperties . SUCCESS [
4.883 s]
[INFO] Apache Log4j OSGi .. SUCCESS [
9.422 s]
[INFO] Apache Log4j BOM ... SUCCESS [
1.082 s]
[INFO] Apache Log4j CouchDB ... SUCCESS [
2.306 s]
[INFO] Apache Log4j MongoDB ... SUCCESS [
4.873 s]
[INFO] Apache Log4j Cassandra ...

Re: [VOTE] Release Log4j 2.10.0-rc1

[Mikael Ståldal]

I agree with Ralph.

On 2017-11-20 20:03, Ralph Goers wrote:

Unless you find something else I am not inclined to rerun the release just to 
fix a unit test where we know what the problem is and that has no impact on the 
code customers use.

Ralph


On Nov 20, 2017, at 11:56 AM, Gary Gregory  wrote:

On Mon, Nov 20, 2017 at 10:43 AM, Gary Gregory 
wrote:


Here it is:

[ERROR] Tests run: 13, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
1.469 s <<< FAILURE! - in org.apache.log4j.config.
Log4j1ConfigurationFactoryTest
[ERROR] testSystemProperties1(org.apache.log4j.config.
Log4j1ConfigurationFactoryTest)  Time elapsed: 0.027 s  <<< ERROR!
java.nio.file.FileSystemException:
C:\Users\ggregory\AppData\Local\Temp\hadoop.log: The process cannot
access the file because it is being used by another process.

at org.apache.log4j.config.Log4j1ConfigurationFactoryTest
.testSystemProperties1(Log4j1ConfigurationFactoryTest.java:173)


I think Remko fixed that in master.



Building master with 'mvn clean install' passes so I would prefer another
RC that picks up Remko's fix.

Gary



Gary

On Mon, Nov 20, 2017 at 9:41 AM, Gary Gregory 
wrote:


Wow,

Now I get a different failure. I had run the build in Windows but from
the git command line (MINGW64). That that I run from a "real" Windows
command line I get:

[ERROR] Errors:
[ERROR]   Log4j1ConfigurationFactoryTest.testSystemProperties1:173 »
FileSystem C:\Users...
[INFO]
[ERROR] Tests run: 145, Failures: 0, Errors: 1, Skipped: 0
[INFO]

Gary

On Mon, Nov 20, 2017 at 4:40 AM, Remko Popma 
wrote:


Ran another build from the release tag, with Java 7. Build succeeds.

I'll look at the checksums and the site next.

Gary, could you run another clean build?
The error messages look strange: I cannot see any difference between the
expected and the actual result in the error output...



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.7.0_55, vendor: Oracle Corporation
Java home: C:\apps\jdk1.7.0_55\jre
Default locale: en_US, platform encoding: MS932
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"

[INFO] Reactor Summary:
[INFO]
[INFO] Apache Log4j 2 . SUCCESS [
3.940 s]
[INFO] Apache Log4j API Java 9 support  SUCCESS [
12.324 s]
[INFO] Apache Log4j API ... SUCCESS [
36.662 s]
[INFO] Apache Log4j Core .. SUCCESS
[22:30
min]
[INFO] Apache Log4j Core Integration Tests  SUCCESS
[01:26
min]
[INFO] Apache Log4j 1.x Compatibility API . SUCCESS [
19.337 s]
[INFO] Apache Log4j SLF4J Binding . SUCCESS [
10.867 s]
[INFO] Apache Log4j to SLF4J Adapter .. SUCCESS [
5.751 s]
[INFO] Apache Log4j Commons Logging Bridge  SUCCESS [
5.527 s]
[INFO] Apache Log4j Flume Bridge .. SUCCESS [
35.251 s]
[INFO] Apache Log4j Web ... SUCCESS [
13.574 s]
[INFO] Apache Log4j Tag Library ... SUCCESS [
24.771 s]
[INFO] Apache Log4j JMX GUI ... SUCCESS [
2.966 s]
[INFO] Apache Log4j Samples ... SUCCESS [
0.846 s]
[INFO] Apache Log4j Samples: Flume - Common ... SUCCESS [
4.211 s]
[INFO] Apache Log4j Samples: Flume - Remote ... SUCCESS [
3.523 s]
[INFO] Apache Log4j Samples: Flume - Embedded . SUCCESS [
9.808 s]
[INFO] Apache Log4j Samples: Configuration  SUCCESS [
4.508 s]
[INFO] Apache Log4j Samples: LoggerProperties . SUCCESS [
4.883 s]
[INFO] Apache Log4j OSGi .. SUCCESS [
9.422 s]
[INFO] Apache Log4j BOM ... SUCCESS [
1.082 s]
[INFO] Apache Log4j CouchDB ... SUCCESS [
2.306 s]
[INFO] Apache Log4j MongoDB ... SUCCESS [
4.873 s]
[INFO] Apache Log4j Cassandra . SUCCESS [
27.022 s]
[INFO] Apache Log4J Performance Tests . SUCCESS [
58.354 s]
[INFO] Apache Log4j Streaming Interface ... SUCCESS [
15.511 s]
[INFO] Apache Log4j JUL Adapter ... SUCCESS [
15.085 s]
[INFO] Apache Log4j Liquibase Binding . SUCCESS [
4.396 s]
[INFO] Apache Log4j App Server Support  SUCCESS [
1.993 s]
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 29:39 min
[INFO] Finished at: 2017-11-20T20:25:57+09:00
[INFO] Final Memory: 55M/451M
[INFO]

Re: [VOTE] Release Log4j 2.10.0-rc1

[Mikael Ståldal]

Is that the complete error message?


On 2017-11-20 17:41, Gary Gregory wrote:

Now I get a different failure. I had run the build in Windows but from the
git command line (MINGW64). That that I run from a "real" Windows command
line I get:

[ERROR] Errors:
[ERROR]   Log4j1ConfigurationFactoryTest.testSystemProperties1:173 »
FileSystem C:\Users...
[INFO]
[ERROR] Tests run: 145, Failures: 0, Errors: 1, Skipped: 0
[INFO]

Re: [VOTE] Release Log4j 2.10.0-rc1

[Mikael Ståldal]

+1

* Maven artifacts works in my test project.
* Build of tags/log4j-2.10-rc1 works.


On 2017-11-19 19:11, Ralph Goers wrote:

This is a vote to release Log4j 2.10.0, 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 release because...

The vote will remain open for 72 hours (or more if required). All votes are 
welcome and we encourage everyone to test the release, but only Logging PMC 
votes are “officially” counted. As always, at least 3 +1 votes and more 
positive than negative votes are required.

Note that this release supports SLF4J 1.7.x and SLF4J 1.8.x. Because SLF4J 
1.7.x requires implementations to include classes in the org.slf4j.impl package 
log4j-sl4j-impl cannot be used as a Java 9 module. Support for SLF4J 1.7.x will 
be removed in a future release.

Changes in this version include:

New Features

• LOG4J2-2120: Properly escape newlines and other control characters in 
JSON. Thanks to Carter Douglas Kozak.
• LOG4J2-2109: Add property to disable message pattern converter 
lookups. Thanks to Carter Douglas Kozak.
• LOG4J2-2112: MapMessage should use deep toString for values. Thanks 
to Carter Douglas Kozak.
• LOG4J2-2103: XML encoding for PatternLayout.
• LOG4J2-2114: Provide a native Log4j 2 implementation of Eclipse 
Jetty's org.eclipse.jetty.util.log.Logger.
• LOG4J2-1203: Allow filtering of line breaks in layout pattern. Thanks 
to Robert Turner.
• LOG4J2-2098: Add a noop AppenderSkeleton for applications still using 
Log4j 1.x.
• LOG4J2-2062: Add possibility of sending the key of a message to Kafka 
using KafkaAppender. Thanks to Jorge Sanchez.
• LOG4J2-2056: Modularize Log4j-api and make most other log4j jars 
automatic modules.
• LOG4J2-1431: Simplify log4j system property naming scheme.
• LOG4J2-1809: Add global configuration environment SPI.
• LOG4J2-1694: Add fields with fixed values to JSON/XML/YAML layouts. 
Thanks to Michal Dvořák.
• LOG4J2-2054: Provide ways to configure SSL that avoid plain-text 
passwords in the log4j configuration. The configuration may now specify a 
system environment variable that holds the password, or the path to a file that 
holds the password.
• LOG4J2-2071: Add 
org.apache.logging.log4j.core.config.composite.CompositeConfiguration#toString().
 Thanks to Carter Kozak.
Fixed Bugs

• LOG4J2-2107: MapMessage supports both StringBuilderFormattable and 
MultiformatMessage. Thanks to Carter Douglas Kozak.
• LOG4J2-2102: MapMessage JSON encoding will escape keys and values. 
Thanks to Carter Douglas Kozak.
• LOG4J2-2101: Non-string value in MapMessage caused 
ClassCastException. Thanks to Carter Douglas Kozak.
• LOG4J2-2091: Log4j respects the configured "log4j2.is.webapp" 
property Thanks to Carter Douglas Kozak.
• LOG4J2-2100: LevelMixIn class for Jackson is coded incorrectly
• LOG4J2-2087: Jansi now needs to be enabled explicitly (by setting 
system property log4j.skipJansi to false). To avoid causing problems for web 
applications, Log4j will no longer automatically try to load Jansi without 
explicit configuration. Thanks to Andy Gumbrecht.
• LOG4J2-2060: AbstractDatabaseManager should make a copy of LogEvents 
before holding references to them: AsyncLogger log events are mutable.
• LOG4J2-2055: If Log4j is used as the Tomcat logging implementation 
startup might fail if an application also uses Log4j.
• LOG4J2-2031: Until this change, messages appeared out of order in log 
file any time when the async logging queue was full. With this change, messages 
are only logged out of order to prevent deadlock when Log4j2 detects recursive 
logging while the queue is full.
• LOG4J2-2053: Exception java.nio.charset.UnsupportedCharsetException: 
cp65001 in 2.9.0.
• LOG4J2-1216: Nested pattern layout options broken. Thanks to Thies 
Wellpott, Barna Zsombor Klara, GFriedrich.
• LOG4J2-2070: Log4j1XmlLayout does not provide the entire stack trace, 
it is missing the caused by information. Thanks to Doug Hughes.
• LOG4J2-2036: CompositeConfiguration supports Reconfiguration. PR 
#115. Thanks to Robert Haycock.
• LOG4J2-2073: Log4j-config.xsd should make AppenderRef optional for 
each Logger element. Thanks to Patrick Lucas.
• LOG4J2-2074: The console appender should say why it cannot load JAnsi.
• LOG4J2-2085: Wrong Apache Commons CSV version referenced in the 
Javadoc of CsvParameterLayout. Thanks to István Neuwirth.
Changes

• LOG4J2-2076: Split up log4j-nosql into one module per appender.
• LOG4J2-2088: Upgrade picocli to 2.0.3 from 0.9.8.
• LOG4J2-2025: Provide support for overriding the Tomcat Log class in 
Tomcat 8.5+.
• LOG4J2-2057: Support new SLF4J binding mechanism introduced in 

Re: Failing unit test

[Mikael Ståldal]

I made an attempt to make that test more reliable.

On 2017-11-19 00:57, Ralph Goers wrote:

I am preparing to do the release build and am getting the following error:

Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.25 s <<< 
FAILURE! - in org.apache.logging.log4j.core.appender.SyslogAppenderTest
testTCPAppender(org.apache.logging.log4j.core.appender.SyslogAppenderTest)  Time 
elapsed: 0.039 s  <<< ERROR!
java.net.BindException: Address already in use
 at 
org.apache.logging.log4j.core.appender.SyslogAppenderTest.initTCPTestEnvironment(SyslogAppenderTest.java:100)
 at 
org.apache.logging.log4j.core.appender.SyslogAppenderTest.testTCPAppender(SyslogAppenderTest.java:54)

I thought I fixed this by adding a thread.join to wait for shutdown to complete 
but I got it again. This doesn’t seem to happen on every build. Before today I 
have never had this error before.

Any unit test failures during the build fail the release. Each release attempt 
takes about 45 minutes so I really need a build without failing tests. If I 
can’t figure it out I may have to disable the test.

Re: logging-log4j2 git commit: Always delete temporary file created in test

[Mikael Ståldal]

OK, but it's probably good to have appender.stop() there as well, to try 
to end cleanly.


And if you to try/catch around the deleteIfExists, it would be good to 
log any error, since that might be useful to troubleshoot any future 
file permission errors on Jenins.


But I'll let you fix it.


On 2017-11-19 13:02, Remko Popma wrote:

I have a fix, but I’ll hold off pushing it until Ralph is done with the release 
that’s in progress.

(It’s just a try/catch FileSystemException around the deleteIfExists in the 
finally block on line 174)

(Shameless plug) Every java main() method deserves http://picocli.info


On Nov 19, 2017, at 20:46, Mikael Ståldal <mi...@apache.org> 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 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 being used by another process.
at
sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at
sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
at
sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
at java.nio.file.Files.deleteIfExists(Files.java:1116)
at
org.apache.log4j.config.Log4j1ConfigurationFactoryTest.testSystemProperties1(Log4j1ConfigurationFactoryTest.java:173)

Re: logging-log4j2 git commit: Always delete temporary file created in test

[Mikael Ståldal]

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 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 being used by another process.


at
sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at
sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
at
sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
at java.nio.file.Files.deleteIfExists(Files.java:1116)
at
org.apache.log4j.config.Log4j1ConfigurationFactoryTest.testSystemProperties1(Log4j1ConfigurationFactoryTest.java:173)

Re: Jenkins build is still unstable: Log4j 2.x #3170

[Mikael Ståldal]

Makes sense, fixed.


On 2017-11-18 21:17, Ralph Goers wrote:

The file should be deleted before the test starts and after it finishes. If it 
fails for some reason it will still leave the file lying around so deleting it 
before the test insures a clean environment.

[Log4j] StructuredDataMessage and XML format

[Mikael Ståldal]

Can someone review my recent fix to 
https://issues.apache.org/jira/browse/LOG4J2-2108 ?


I am not sure how it is actually supposed to work.

[Log4j]

[Mikael Ståldal]

Any thoughts about https://issues.apache.org/jira/browse/LOG4J2-2110 and 
https://github.com/apache/logging-log4j2/pull/128 ?


I have not worked with Servlet stuff for quite long time.

Re: Jenkins build is still unstable: Log4j 2.x #3170

[Mikael Ståldal]

It works now!


On 2017-11-18 13:00, Mikael Ståldal wrote:
That particular test creates hadoop.log in 
System.getProperty("java.io.tmpdir") on purpuse to test system property 
replacement in configuration files.


On most Linux systems (including our Jenkins machine), 
System.getProperty("java.io.tmpdir") == "/tmp".


I tried the test locally on my Linux machine, and it works. But it 
leaves the /tmp/hadoop.log file behind. I changed the test to delete the 
file afterwards, maybe that will help.


Maybe someone have to manually delete /tmp/hadoop.log on the Jenkins 
machine once to get this working again. (I am not sure how to access the 
Jenkins machine to be able to do that.)

Re: Jenkins build is still unstable: Log4j 2.x #3170

[Mikael Ståldal]

That particular test creates hadoop.log in 
System.getProperty("java.io.tmpdir") on purpuse to test system property 
replacement in configuration files.


On most Linux systems (including our Jenkins machine), 
System.getProperty("java.io.tmpdir") == "/tmp".


I tried the test locally on my Linux machine, and it works. But it 
leaves the /tmp/hadoop.log file behind. I changed the test to delete the 
file afterwards, maybe that will help.


Maybe someone have to manually delete /tmp/hadoop.log on the Jenkins 
machine once to get this working again. (I am not sure how to access the 
Jenkins machine to be able to do that.)



On 2017-11-12 23:58, Ralph Goers wrote:

I am not sure why this is suddenly failing with a permission denied trying to 
create /tmp/hadoop.log. But why is it trying to create a file there instead of 
under the target directory?

Ralph


On Nov 12, 2017, at 2:39 PM, Apache Jenkins Server  
wrote:

See 

Re: Jenkins build is still unstable: Log4j 2.x #3170

[Mikael Ståldal]

Same problem again in latest build (#3182).


On 2017-11-12 23:58, Ralph Goers wrote:

I am not sure why this is suddenly failing with a permission denied trying to 
create /tmp/hadoop.log. But why is it trying to create a file there instead of 
under the target directory?

Ralph


On Nov 12, 2017, at 2:39 PM, Apache Jenkins Server  
wrote:

See 

Re: Log4j 2.10

[Mikael Ståldal]

OK for me. Thanks for the RM work.


On 2017-11-16 05:31, Ralph Goers wrote:

Unless someone objects I plan to start the release process for Log4j 2.10 
tomorrow. I had wanted to include a fix for LOG4J2-2106 but the problem only 
occurs in rare situations and I am not sure how to fix it yet. There are a lot 
of other issues that deserve looking at but nothing I can see that warrants 
waiting on.

Re: Log4j 2.10

[Mikael Ståldal]

OK for me. Thanks for the RM work.

On 2017-11-16 05:31, Ralph Goers wrote:

Unless someone objects I plan to start the release process for Log4j 2.10 
tomorrow. I had wanted to include a fix for LOG4J2-2106 but the problem only 
occurs in rare situations and I am not sure how to fix it yet. There are a lot 
of other issues that deserve looking at but nothing I can see that warrants 
waiting on.

Re: logging-log4j2 git commit: [LOG4J2-2114] Provide a native Log4j 2 implementation of Eclipse Jetty's org.eclipse.jetty.util.log.Logger.

[Mikael Ståldal]

Nice.

Too bad that Jetty doesn't support automatic discovery of logging impl 
as Tomcat do. Maybe we should issue a feature request about that?



On 2017-11-13 16:49, Gary Gregory wrote:

I also updated log4j-appserver/src/site/markdown/index.md.vm

Thank you!
Gary

On Mon, Nov 13, 2017 at 8:04 AM, Gary Gregory <garydgreg...@gmail.com>
wrote:


Oh, I added a section to the main index:

#h3 Integrating with Application Servers

Version 2.10.0 introduces a the module log4j-appserver to improve
integration with Apache Tomcat and Eclipse Jetty.

Gary

On Sun, Nov 12, 2017 at 10:10 AM, Mikael Ståldal <mi...@apache.org> wrote:


On 2017-11-12 16:00, Gary Gregory wrote:


On Sun, Nov 12, 2017 at 7:25 AM, Mikael Ståldal <mi...@apache.org>
wrote:

Do we want a package-info.java in the Jetty package, like in the Tomcat

package?

And you should probably add a section about Jetty integraion in
log4j-appserver/src/site/markdown/index.md.vm



Done. Please review.



I don't see anything about Jetty in log4j-appserver/src/site/markd
own/index.md.vm

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Mikael Ståldal]

When starting Chainsaw, I see this warning in the log:

menu 'Connect to' was NOT added because the 'Help' menu could not be located

There is a "Connect to" menu though, and the "Learn more about ZeroConf" 
works.



On 2017-11-10 20:00, Matt Sicker wrote:

This is a vote to release Apache Chainsaw 2.0.0-rc1.

(Note: I've created release instructions on the new wiki: <
https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>)

Artifacts:
https://dist.apache.org/repos/dist/dev/logging/chainsaw/
svn revision 23048

Site:
http://musigma.org/chainsaw-site/

Git:
https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
tag: chainsaw-2.0.0-rc1

All artifacts have been signed by my PGP key
id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging KEYS
file.

This vote will be open for at least 72 hours and requires at least 3 +1
votes and more +1 votes than -1 votes.

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Mikael Ståldal]

Would be nice to be able to load that as a plugin in a more dynamic 
fashion. But we can keep that for a future version, not blocking this 
release.



On 2017-11-12 20:45, Scott Deboy wrote:

That's right - we don't bundle in a JMS jar, although users can add
one to the classpath to use the JMSReceiver.

On 11/12/17, Mikael Ståldal <mi...@apache.org> wrote:

When running Chainsaw, I see this error message:

Failed to locate Receiver class:org.apache.log4j.net.JMSReceiver, looks
like a dependent class is missing from the classpath
java.lang.NoClassDefFoundError: javax/jms/MessageListener

It seems to work anyway (without JMX support I suppose) though. But I
guess some jar file with that class should be on the classpath?


On 2017-11-10 20:00, Matt Sicker wrote:

This is a vote to release Apache Chainsaw 2.0.0-rc1.

(Note: I've created release instructions on the new wiki: <
https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>)

Artifacts:
https://dist.apache.org/repos/dist/dev/logging/chainsaw/
svn revision 23048

Site:
http://musigma.org/chainsaw-site/

Git:
https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
tag: chainsaw-2.0.0-rc1

All artifacts have been signed by my PGP key
id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging
KEYS
file.

This vote will be open for at least 72 hours and requires at least 3 +1
votes and more +1 votes than -1 votes.

Re: Planning out what we can do to get Chainsaw back in the game

[Mikael Ståldal]

I see a use case for a stand-alone log viewer/analyzer application which 
doesn't require any heavy infrastructure like ElasticSearch. I would 
like Chainsaw to focus on that use case.



On 2017-11-12 05:22, Ole Ersoy wrote:
I had a brief peek.  My first impression was that the whole thing needs 
a facelift.  I'm currently I'm reviewing the ELK stack with the Kibana 
user interface as well as fluentd and Zipkin. Something that unifies 
these things would be very attractive.  If the UI is modern then even 
more so.  If we can deploy it as a progressive web app attachable to a 
GraphQL provider that gets feeds from Fluentd and the ELK stack that 
would definitely get Chainsaw back in the game.  I think you would have 
an easy time attracting a talent pool for something like that.  For 
example http://akveo.github.io/blur-admin/ is currently available on 
Github and has 8000 stars.  Could be the starting point for the next 
generation logging UI.


Cheers,

Ole


On 11/11/2017 06:09 PM, Scott Deboy wrote:

I'd love to hear what folks think of the user experience with the
'latest Chainsaw' and its feature set.

There are a ton of features.  It will be interesting to get a sense of
how many of those features we get 'for free' in any of these other UI
toolkits.  It was a lot of heavy lifting to get Swing to do what we
wanted.

Scott


On 11/11/17, Ole Ersoy <ole.er...@gmail.com> wrote:

Kotlin is almost a duplicate of Typescript, so Javascript devs should be
able to pickup on it fast.  There's a Typescript to Kotlin converter 
here:


https://github.com/Kotlin/ts2kt

Typescript is also supported in Electron:

https://electron.atom.io/blog/2017/06/01/typescript

So Kotlin should be a pretty good bridge between these worlds and 
opens up a
lot of possibilities ... Suggested Kotlin to the Hipparchus group as 
well:


https://github.com/Hipparchus-Math/hipparchus/issues/26

A chainsaw implementation in Electron would provide a better 
developer and

user experience I would think though ... as you can now use the latest
Javascript frameworks (Angular / React) and all the packages that 
come with

that ecosystem (Graphing, Widgets, etc.)

https://scotch.io/tutorials/creating-desktop-applications-with-angularjs-and-github-electron 




On 11/11/2017 04:42 PM, Matt Sicker wrote:

I've been using Java for years, Scala for several months (all of OOP,
hybrid, and pure FP styles in different projects), and other 
languages in
the past. I've certainly found Scala to be useful in the Big Data 
space,
especially when using Spark, though I've also found it useful in 
projects

that consume Java APIs.

As for Kotlin fitting well to a GUI app, based on its traction in the
Android GUI space, I had the same thought. Plus, this may attract more
contributors outside ASF who are interested in using Kotlin or 
working on

a
GUI app instead of low level Java bits.

Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to
pick
up on than Scala, so that also helps with adoption in theory.

On 11 November 2017 at 10:23, Mikael Ståldal <mi...@apache.org> wrote:


I have used both Java and Scala for several years, and I have been
trying
out Kotlin the latest months (for Android only).

I would say it is definitely easier for a developer with primarily 
Java

experience to pick up Kotlin than Scala, especially if that Java
experience
is predominately pre-Java8. If your primary experience is functional
programming like Haskell, O'Caml or F#; then Scala is probably 
easier to

pick up.

Kotlin is gaining traction in Android, since it works well there. 
Scala

is
big in Big Data (Apache Spark etc) and to some extent in 
server/backend.


Kotlin might be a better fit for a desktop UI Java app like Chainsaw.



On 2017-11-11 02:10, Gary Gregory wrote:


I think Kotlin would be more approachable than Scala... thoughts?

Gary

On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker <boa...@gmail.com> 
wrote:


On 10 November 2017 at 16:17, Robert Middleton <osfan6...@gmail.com>

wrote:

What would the advantage be of using Scala vs just normal Java?
Mostly from a curiosity standpoint; I've never done Scala so I 
don't

know it works.


The main advantage I can see is that most of the developers 
interested

in
working on v3 all prefer to work in Scala. I could go on and on 
about

Scala
over Java, but really, my comparison would all come down to 
functional
programming over object oriented programming. When it comes to 
shared

libraries like Log4j, I find Java far more appropriate and work in
that
space. In a GUI application where there is no real public API? I'd
rather
work in Scala. Kotlin was another option, but it seems like none 
of us

really have experience there.


Did you actually have trouble building?  I'm pretty sure that when I
built it a few months ago I simply opened up the project in 
Netbeans

and it built immediately as a maven project(although looking at the
POM it does look like it uses ant on the

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Mikael Ståldal]

In release notes in the app, it says version 2.1.


On 2017-11-10 20:00, Matt Sicker wrote:

This is a vote to release Apache Chainsaw 2.0.0-rc1.

(Note: I've created release instructions on the new wiki: <
https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>)

Artifacts:
https://dist.apache.org/repos/dist/dev/logging/chainsaw/
svn revision 23048

Site:
http://musigma.org/chainsaw-site/

Git:
https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
tag: chainsaw-2.0.0-rc1

All artifacts have been signed by my PGP key
id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging KEYS
file.

This vote will be open for at least 72 hours and requires at least 3 +1
votes and more +1 votes than -1 votes.

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Mikael Ståldal]

When starting Chainsaw, I see this warning:

Could not find any local JavaDocs, you might want to consider running 
'ant javadoc'. The release version will be able to access Javadocs from 
the Apache website.


And accessing Javadocs from the Help menu does not work.



On 2017-11-10 20:00, Matt Sicker wrote:

This is a vote to release Apache Chainsaw 2.0.0-rc1.

(Note: I've created release instructions on the new wiki: <
https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>)

Artifacts:
https://dist.apache.org/repos/dist/dev/logging/chainsaw/
svn revision 23048

Site:
http://musigma.org/chainsaw-site/

Git:
https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
tag: chainsaw-2.0.0-rc1

All artifacts have been signed by my PGP key
id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging KEYS
file.

This vote will be open for at least 72 hours and requires at least 3 +1
votes and more +1 votes than -1 votes.

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Mikael Ståldal]

In the About text, it says:

Please send questions, bug reports and/or feature requests to
log4j-...@logging.apache.org

which is obsolete.


On 2017-11-10 20:00, Matt Sicker wrote:

This is a vote to release Apache Chainsaw 2.0.0-rc1.

(Note: I've created release instructions on the new wiki: <
https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>)

Artifacts:
https://dist.apache.org/repos/dist/dev/logging/chainsaw/
svn revision 23048

Site:
http://musigma.org/chainsaw-site/

Git:
https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
tag: chainsaw-2.0.0-rc1

All artifacts have been signed by my PGP key
id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging KEYS
file.

This vote will be open for at least 72 hours and requires at least 3 +1
votes and more +1 votes than -1 votes.

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Mikael Ståldal]

When running Chainsaw, I see this error message:

Failed to locate Receiver class:org.apache.log4j.net.JMSReceiver, looks 
like a dependent class is missing from the classpath

java.lang.NoClassDefFoundError: javax/jms/MessageListener

It seems to work anyway (without JMX support I suppose) though. But I 
guess some jar file with that class should be on the classpath?



On 2017-11-10 20:00, Matt Sicker wrote:

This is a vote to release Apache Chainsaw 2.0.0-rc1.

(Note: I've created release instructions on the new wiki: <
https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>)

Artifacts:
https://dist.apache.org/repos/dist/dev/logging/chainsaw/
svn revision 23048

Site:
http://musigma.org/chainsaw-site/

Git:
https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
tag: chainsaw-2.0.0-rc1

All artifacts have been signed by my PGP key
id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging KEYS
file.

This vote will be open for at least 72 hours and requires at least 3 +1
votes and more +1 votes than -1 votes.

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Mikael Ståldal]

The apache-chainsaw-2.0.0-standalone.tar.gz artifact has wrong 
permissions set on the bin directory:


$ tar -tvzf apache-chainsaw-2.0.0-standalone.tar.gz
d- 0/0 0 2017-11-10 19:24 apache-chainsaw/2.0.0/bin/

after extracting:

$ cd apache-chainsaw-2.0.0/
$ ls
bin  repo
$ cd bin/
bash: cd: bin/: Permission denied

I have to do:

$ chmod +rwx bin/
$ cd bin/
$ ls
chainsaw  chainsaw.bat

Same problem with apache-chainsaw-2.0.0-standalone.zip.

Most files and directories in both .tar.gz artifacts also has 
owner/group set to "matt/staff", which might not be appropriate.



On 2017-11-10 20:00, Matt Sicker wrote:

This is a vote to release Apache Chainsaw 2.0.0-rc1.

(Note: I've created release instructions on the new wiki: <
https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>)

Artifacts:
https://dist.apache.org/repos/dist/dev/logging/chainsaw/
svn revision 23048

Site:
http://musigma.org/chainsaw-site/

Git:
https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
tag: chainsaw-2.0.0-rc1

All artifacts have been signed by my PGP key
id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging KEYS
file.

This vote will be open for at least 72 hours and requires at least 3 +1
votes and more +1 votes than -1 votes.

Re: logging-log4j2 git commit: [LOG4J2-2114] Provide a native Log4j 2 implementation of Eclipse Jetty's org.eclipse.jetty.util.log.Logger.

[Mikael Ståldal]

On 2017-11-12 16:00, Gary Gregory wrote:

On Sun, Nov 12, 2017 at 7:25 AM, Mikael Ståldal <mi...@apache.org> wrote:


Do we want a package-info.java in the Jetty package, like in the Tomcat
package?

And you should probably add a section about Jetty integraion in
log4j-appserver/src/site/markdown/index.md.vm


Done. Please review.


I don't see anything about Jetty in 
log4j-appserver/src/site/markdown/index.md.vm

Re: Planning out what we can do to get Chainsaw back in the game

[Mikael Ståldal]

Having said that, I don't mean that Ole Ersoy's idea is inherently bad. 
But it should be a new independent project (possibly in Apache Logging 
Services).



On 2017-11-12 14:27, Mikael Ståldal wrote:
To me, that sound like transforming it into something completely 
different, and a use case which there already exists quite some other 
tools for already.


Shouldn't we keep Chainsaw as a stand-alone desktop UI app?


On 2017-11-12 05:22, Ole Ersoy wrote:
I had a brief peek.  My first impression was that the whole thing 
needs a facelift.  I'm currently I'm reviewing the ELK stack with the 
Kibana user interface as well as fluentd and Zipkin. Something that 
unifies these things would be very attractive.  If the UI is modern 
then even more so.  If we can deploy it as a progressive web app 
attachable to a GraphQL provider that gets feeds from Fluentd and the 
ELK stack that would definitely get Chainsaw back in the game.  I 
think you would have an easy time attracting a talent pool for 
something like that.  For example http://akveo.github.io/blur-admin/ 
is currently available on Github and has 8000 stars.  Could be the 
starting point for the next generation logging UI.


Cheers,

Ole


On 11/11/2017 06:09 PM, Scott Deboy wrote:

I'd love to hear what folks think of the user experience with the
'latest Chainsaw' and its feature set.

There are a ton of features.  It will be interesting to get a sense of
how many of those features we get 'for free' in any of these other UI
toolkits.  It was a lot of heavy lifting to get Swing to do what we
wanted.

Scott


On 11/11/17, Ole Ersoy <ole.er...@gmail.com> wrote:
Kotlin is almost a duplicate of Typescript, so Javascript devs 
should be
able to pickup on it fast.  There's a Typescript to Kotlin converter 
here:


https://github.com/Kotlin/ts2kt

Typescript is also supported in Electron:

https://electron.atom.io/blog/2017/06/01/typescript

So Kotlin should be a pretty good bridge between these worlds and 
opens up a
lot of possibilities ... Suggested Kotlin to the Hipparchus group as 
well:


https://github.com/Hipparchus-Math/hipparchus/issues/26

A chainsaw implementation in Electron would provide a better 
developer and

user experience I would think though ... as you can now use the latest
Javascript frameworks (Angular / React) and all the packages that 
come with

that ecosystem (Graphing, Widgets, etc.)

https://scotch.io/tutorials/creating-desktop-applications-with-angularjs-and-github-electron 




On 11/11/2017 04:42 PM, Matt Sicker wrote:

I've been using Java for years, Scala for several months (all of OOP,
hybrid, and pure FP styles in different projects), and other 
languages in
the past. I've certainly found Scala to be useful in the Big Data 
space,
especially when using Spark, though I've also found it useful in 
projects

that consume Java APIs.

As for Kotlin fitting well to a GUI app, based on its traction in the
Android GUI space, I had the same thought. Plus, this may attract more
contributors outside ASF who are interested in using Kotlin or 
working on

a
GUI app instead of low level Java bits.

Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to
pick
up on than Scala, so that also helps with adoption in theory.

On 11 November 2017 at 10:23, Mikael Ståldal <mi...@apache.org> wrote:


I have used both Java and Scala for several years, and I have been
trying
out Kotlin the latest months (for Android only).

I would say it is definitely easier for a developer with primarily 
Java

experience to pick up Kotlin than Scala, especially if that Java
experience
is predominately pre-Java8. If your primary experience is functional
programming like Haskell, O'Caml or F#; then Scala is probably 
easier to

pick up.

Kotlin is gaining traction in Android, since it works well there. 
Scala

is
big in Big Data (Apache Spark etc) and to some extent in 
server/backend.


Kotlin might be a better fit for a desktop UI Java app like Chainsaw.



On 2017-11-11 02:10, Gary Gregory wrote:


I think Kotlin would be more approachable than Scala... thoughts?

Gary

On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker <boa...@gmail.com> 
wrote:


On 10 November 2017 at 16:17, Robert Middleton <osfan6...@gmail.com>

wrote:

What would the advantage be of using Scala vs just normal Java?
Mostly from a curiosity standpoint; I've never done Scala so I 
don't

know it works.


The main advantage I can see is that most of the developers 
interested

in
working on v3 all prefer to work in Scala. I could go on and on 
about

Scala
over Java, but really, my comparison would all come down to 
functional
programming over object oriented programming. When it comes to 
shared

libraries like Log4j, I find Java far more appropriate and work in
that
space. In a GUI application where there is no real public API? I'd
rather
work in Scala. Kotlin was another option, but it seems like none 
of us

really have experience there.


Did you actual

Re: logging-log4j2 git commit: [LOG4J2-2114] Provide a native Log4j 2 implementation of Eclipse Jetty's org.eclipse.jetty.util.log.Logger.

[Mikael Ståldal]

Do we want a package-info.java in the Jetty package, like in the Tomcat 
package?


And you should probably add a section about Jetty integraion in
log4j-appserver/src/site/markdown/index.md.vm


On 2017-11-11 23:43, Gary Gregory wrote:

Please code review git master. I'm not sure I have the class loader right.

Gary

On Sat, Nov 11, 2017 at 2:54 PM, Ralph Goers 
wrote:


Oh, but you probably don’t want to extend AbstractLogger. You really want
the FQCN of the caller to be able to identify the ClassLoader and
LoggerContext to use and you won’t get that from AbstractLogger’s getLogger
method.

Ralph


On Nov 11, 2017, at 2:45 PM, Ralph Goers 

wrote:


Sure. Look at TomcatLogger. It does exactly what you are trying to do.

Ralph


On Nov 11, 2017, at 2:02 PM, Gary Gregory 

wrote:


The Javadoc for Log4j's LoggerAdapter says "This registry should not be
used for Log4j Loggers; it is instead used for creating bridges to other
external log systems.".

In this case we are not bridging TO another log system. We are plugging
INTO Jetty's log system and subclassing Jetty's own LoggerAdapter class
(out convenience.)

Further thoughts?

Gary

On Fri, Nov 10, 2017 at 9:25 PM, Matt Sicker  wrote:


IIRC, the easiest way to support it might be to use
https://logging.apache.org/log4j/2.x/log4j-api/apidocs/
org/apache/logging/log4j/spi/AbstractLoggerAdapter.html

On 10 November 2017 at 22:16, Gary Gregory 

wrote:



I think you are correct...

Gary

On Fri, Nov 10, 2017 at 6:59 PM, Matt Sicker 

wrote:



Wouldn't this implementation contain incorrect caller location

information?


On 10 November 2017 at 19:25,  wrote:


Repository: logging-log4j2
Updated Branches:
refs/heads/master aad2f132b -> 7d52f131e


[LOG4J2-2114] Provide a native Log4j 2 implementation of Eclipse

Jetty's

org.eclipse.jetty.util.log.Logger.

Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
commit/7d52f131
Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/

7d52f131

Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/

7d52f131


Branch: refs/heads/master
Commit: 7d52f131ec1e000834bcb40343f3f2d41805c75a
Parents: aad2f13
Author: Gary Gregory 
Authored: Fri Nov 10 18:25:47 2017 -0700
Committer: Gary Gregory 
Committed: Fri Nov 10 18:25:47 2017 -0700



--

log4j-appserver/pom.xml |   8 +
.../log4j/appserver/jetty/Log4j2Logger.java | 184

+++

src/changes/changes.xml |   3 +
3 files changed, 195 insertions(+)


--



http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
7d52f131/log4j-appserver/pom.xml


--

diff --git a/log4j-appserver/pom.xml b/log4j-appserver/pom.xml
index e96b1fc..6acd77b 100644
--- a/log4j-appserver/pom.xml
+++ b/log4j-appserver/pom.xml
@@ -34,6 +34,7 @@
Web Documentation
/log4j-appserver
8.5.20
+8.2.0.v20160908 
org.apache.logging.log4j.appserver
  

@@ -56,6 +57,7 @@
  org.apache.tomcat
  tomcat-catalina
  ${tomcat.version}
+  provided
  

  org.apache.tomcat
@@ -71,6 +73,12 @@

  

+
+  org.eclipse.jetty
+  jetty-util
+  ${jetty.version}
+  provided
+




http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/
7d52f131/log4j-appserver/src/main/java/org/apache/logging/
log4j/appserver/jetty/Log4j2Logger.java


--

diff --git a/log4j-appserver/src/main/

java/org/apache/logging/log4j/

appserver/jetty/Log4j2Logger.java b/log4j-appserver/src/main/
java/org/apache/logging/log4j/appserver/jetty/Log4j2Logger.java
new file mode 100644
index 000..7d1ce14
--- /dev/null
+++ b/log4j-appserver/src/main/java/org/apache/logging/log4j/
appserver/jetty/Log4j2Logger.java
@@ -0,0 +1,184 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or

more

+ * contributor license agreements. See the NOTICE file distributed

with

+ * this work for additional information regarding copyright

ownership.

+ * The ASF licenses this file to You under the Apache license,

Version

2.0

+ * (the "License"); you may not use this file except in compliance

with

+ * the License. You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,

software

+ * distributed under the License is distributed on an "AS IS"

BASIS,

+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either 

Re: Planning out what we can do to get Chainsaw back in the game

[Mikael Ståldal]

To me, that sound like transforming it into something completely 
different, and a use case which there already exists quite some other 
tools for already.


Shouldn't we keep Chainsaw as a stand-alone desktop UI app?


On 2017-11-12 05:22, Ole Ersoy wrote:
I had a brief peek.  My first impression was that the whole thing needs 
a facelift.  I'm currently I'm reviewing the ELK stack with the Kibana 
user interface as well as fluentd and Zipkin. Something that unifies 
these things would be very attractive.  If the UI is modern then even 
more so.  If we can deploy it as a progressive web app attachable to a 
GraphQL provider that gets feeds from Fluentd and the ELK stack that 
would definitely get Chainsaw back in the game.  I think you would have 
an easy time attracting a talent pool for something like that.  For 
example http://akveo.github.io/blur-admin/ is currently available on 
Github and has 8000 stars.  Could be the starting point for the next 
generation logging UI.


Cheers,

Ole


On 11/11/2017 06:09 PM, Scott Deboy wrote:

I'd love to hear what folks think of the user experience with the
'latest Chainsaw' and its feature set.

There are a ton of features.  It will be interesting to get a sense of
how many of those features we get 'for free' in any of these other UI
toolkits.  It was a lot of heavy lifting to get Swing to do what we
wanted.

Scott


On 11/11/17, Ole Ersoy <ole.er...@gmail.com> wrote:

Kotlin is almost a duplicate of Typescript, so Javascript devs should be
able to pickup on it fast.  There's a Typescript to Kotlin converter 
here:


https://github.com/Kotlin/ts2kt

Typescript is also supported in Electron:

https://electron.atom.io/blog/2017/06/01/typescript

So Kotlin should be a pretty good bridge between these worlds and 
opens up a
lot of possibilities ... Suggested Kotlin to the Hipparchus group as 
well:


https://github.com/Hipparchus-Math/hipparchus/issues/26

A chainsaw implementation in Electron would provide a better 
developer and

user experience I would think though ... as you can now use the latest
Javascript frameworks (Angular / React) and all the packages that 
come with

that ecosystem (Graphing, Widgets, etc.)

https://scotch.io/tutorials/creating-desktop-applications-with-angularjs-and-github-electron 




On 11/11/2017 04:42 PM, Matt Sicker wrote:

I've been using Java for years, Scala for several months (all of OOP,
hybrid, and pure FP styles in different projects), and other 
languages in
the past. I've certainly found Scala to be useful in the Big Data 
space,
especially when using Spark, though I've also found it useful in 
projects

that consume Java APIs.

As for Kotlin fitting well to a GUI app, based on its traction in the
Android GUI space, I had the same thought. Plus, this may attract more
contributors outside ASF who are interested in using Kotlin or 
working on

a
GUI app instead of low level Java bits.

Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to
pick
up on than Scala, so that also helps with adoption in theory.

On 11 November 2017 at 10:23, Mikael Ståldal <mi...@apache.org> wrote:


I have used both Java and Scala for several years, and I have been
trying
out Kotlin the latest months (for Android only).

I would say it is definitely easier for a developer with primarily 
Java

experience to pick up Kotlin than Scala, especially if that Java
experience
is predominately pre-Java8. If your primary experience is functional
programming like Haskell, O'Caml or F#; then Scala is probably 
easier to

pick up.

Kotlin is gaining traction in Android, since it works well there. 
Scala

is
big in Big Data (Apache Spark etc) and to some extent in 
server/backend.


Kotlin might be a better fit for a desktop UI Java app like Chainsaw.



On 2017-11-11 02:10, Gary Gregory wrote:


I think Kotlin would be more approachable than Scala... thoughts?

Gary

On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker <boa...@gmail.com> 
wrote:


On 10 November 2017 at 16:17, Robert Middleton <osfan6...@gmail.com>

wrote:

What would the advantage be of using Scala vs just normal Java?
Mostly from a curiosity standpoint; I've never done Scala so I 
don't

know it works.


The main advantage I can see is that most of the developers 
interested

in
working on v3 all prefer to work in Scala. I could go on and on 
about

Scala
over Java, but really, my comparison would all come down to 
functional
programming over object oriented programming. When it comes to 
shared

libraries like Log4j, I find Java far more appropriate and work in
that
space. In a GUI application where there is no real public API? I'd
rather
work in Scala. Kotlin was another option, but it seems like none 
of us

really have experience there.


Did you actually have trouble building?  I'm pretty sure that when I
built it a few months ago I simply opened up the project in 
Netbeans

and it built immediately as a maven project(although looking at the
POM it do

Re: Planning out what we can do to get Chainsaw back in the game

[Mikael Ståldal]

On 2017-11-12 00:57, Ole Ersoy wrote:
> A chainsaw implementation in Electron would provide a better developer
> and user experience I would think though

But that would require a complete rewrite of the app, with no 
opportunity to reuse any of the existing Java code.


Both Scala and Kotlin have good interoperability with Java, and you can 
mix them with Java in the same project. So we can to a gradual migration.


Or am I missing something?

I have also heard that Electron has been criticized for having a very 
heavy runtime (embedded Chrome browser). That is to some extent true 
with the JVM also, but I think that Electron is worse.


I'd say we should stay on the JVM. Our options are Java 8, Kotlin or 
Scala; and Swing or JavaFX.

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Mikael Ståldal]

Yes, that worked.


On 2017-11-11 22:22, Scott Deboy wrote:

I had ran mvn clean site:site install and it worked.


On 11/11/17, Mikael Ståldal <mi...@apache.org> wrote:

On 2017-11-10 20:00, Matt Sicker wrote:

Artifacts:
https://dist.apache.org/repos/dist/dev/logging/chainsaw/
svn revision 23048


When I look at that URL, it says: Revision 23059

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Mikael Ståldal]

On 2017-11-10 20:00, Matt Sicker wrote:

Artifacts:
https://dist.apache.org/repos/dist/dev/logging/chainsaw/
svn revision 23048


When I look at that URL, it says: Revision 23059

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Mikael Ståldal]

Same issue on master branch.

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T17:41:47+01:00)

Java version: 1.8.0_144, vendor: Oracle Corporation
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", arch: "amd64", family: "unix"


On 2017-11-11 21:40, Mikael Ståldal wrote:

$ git checkout chainsaw-2.0.0-rc1

$ mvn clean install

[...]

[INFO] --- maven-assembly-plugin:2.4:single (make-assembly) @ 
apache-chainsaw ---
Downloading: 
https://repo.maven.apache.org/maven2/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar 

Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar 
(0 B at 0.0 KB/sec)

[INFO] Reading assembly descriptor: src/assembly/bin.xml
[INFO] 


[INFO] BUILD FAILURE
[INFO] 


[INFO] Total time: 17.828 s
[INFO] Finished at: 2017-11-11T21:31:50+01:00
[INFO] Final Memory: 31M/382M
[INFO] 

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:2.4:single 
(make-assembly) on project apache-chainsaw: site did not exist in the 
target directory - please run site:site before creating the assembly: 
Mojo configuration is invalid: site did not exist in the target 
directory - please run site:site before creating the assembly -> [Help 1]

[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the 
-e switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, 
please read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException




On 2017-11-10 20:00, Matt Sicker wrote:

This is a vote to release Apache Chainsaw 2.0.0-rc1.

(Note: I've created release instructions on the new wiki: <
https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>) 



Artifacts:
https://dist.apache.org/repos/dist/dev/logging/chainsaw/
svn revision 23048

Site:
http://musigma.org/chainsaw-site/

Git:
https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
tag: chainsaw-2.0.0-rc1

All artifacts have been signed by my PGP key
id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging 
KEYS

file.

This vote will be open for at least 72 hours and requires at least 3 +1
votes and more +1 votes than -1 votes.

Re: [VOTE] Release Apache Chainsaw 2.0.0-rc1

[Mikael Ståldal]

$ git checkout chainsaw-2.0.0-rc1

$ mvn clean install

[...]

[INFO] --- maven-assembly-plugin:2.4:single (make-assembly) @ 
apache-chainsaw ---
Downloading: 
https://repo.maven.apache.org/maven2/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar
Downloaded: 
https://repo.maven.apache.org/maven2/org/apache/maven/wagon/wagon-provider-api/1.0-alpha-6/wagon-provider-api-1.0-alpha-6.jar 
(0 B at 0.0 KB/sec)

[INFO] Reading assembly descriptor: src/assembly/bin.xml
[INFO] 


[INFO] BUILD FAILURE
[INFO] 


[INFO] Total time: 17.828 s
[INFO] Finished at: 2017-11-11T21:31:50+01:00
[INFO] Final Memory: 31M/382M
[INFO] 

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:2.4:single 
(make-assembly) on project apache-chainsaw: site did not exist in the 
target directory - please run site:site before creating the assembly: 
Mojo configuration is invalid: site did not exist in the target 
directory - please run site:site before creating the assembly -> [Help 1]

[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the 
-e switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, 
please read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException




On 2017-11-10 20:00, Matt Sicker wrote:

This is a vote to release Apache Chainsaw 2.0.0-rc1.

(Note: I've created release instructions on the new wiki: <
https://cwiki.apache.org/confluence/display/LOGGING/Chainsaw+Release+Guide>)

Artifacts:
https://dist.apache.org/repos/dist/dev/logging/chainsaw/
svn revision 23048

Site:
http://musigma.org/chainsaw-site/

Git:
https://git-wip-us.apache.org/repos/asf/logging-chainsaw.git
tag: chainsaw-2.0.0-rc1

All artifacts have been signed by my PGP key
id 748F15B2CF9BA8F024155E6ED7C92B70FA1C814D as included in the Logging KEYS
file.

This vote will be open for at least 72 hours and requires at least 3 +1
votes and more +1 votes than -1 votes.

Re: Planning out what we can do to get Chainsaw back in the game

[Mikael Ståldal]

I have used both Java and Scala for several years, and I have been 
trying out Kotlin the latest months (for Android only).


I would say it is definitely easier for a developer with primarily Java 
experience to pick up Kotlin than Scala, especially if that Java 
experience is predominately pre-Java8. If your primary experience is 
functional programming like Haskell, O'Caml or F#; then Scala is 
probably easier to pick up.


Kotlin is gaining traction in Android, since it works well there. Scala 
is big in Big Data (Apache Spark etc) and to some extent in server/backend.


Kotlin might be a better fit for a desktop UI Java app like Chainsaw.


On 2017-11-11 02:10, Gary Gregory wrote:

I think Kotlin would be more approachable than Scala... thoughts?

Gary

On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker  wrote:


On 10 November 2017 at 16:17, Robert Middleton 
wrote:


What would the advantage be of using Scala vs just normal Java?
Mostly from a curiosity standpoint; I've never done Scala so I don't
know it works.



The main advantage I can see is that most of the developers interested in
working on v3 all prefer to work in Scala. I could go on and on about Scala
over Java, but really, my comparison would all come down to functional
programming over object oriented programming. When it comes to shared
libraries like Log4j, I find Java far more appropriate and work in that
space. In a GUI application where there is no real public API? I'd rather
work in Scala. Kotlin was another option, but it seems like none of us
really have experience there.



Did you actually have trouble building?  I'm pretty sure that when I
built it a few months ago I simply opened up the project in Netbeans
and it built immediately as a maven project(although looking at the
POM it does look like it uses ant on the backend for some reason).



Building the project is simple enough. I had issues with:

1. Running mvn clean install does not work by default unless you run "mvn
site:site" before running "mvn install".
2. Doesn't build in Java 9.
3. The maven-release-plugin is not configured at all, so I had to do all
release steps by hand instead.

--
Matt Sicker 

Re: [PROPOSAL] New module log4j-jetty

[Mikael Ståldal]

On 2017-11-09 20:09, Matt Sicker wrote:

On 9 November 2017 at 11:34, Gary Gregory  wrote:


I do not want to drag
Tomcat down into my local repo or on my class path in my IDE just because I
am depending on log4j-appserver's one class for Jetty logging.



There are certain dependencies in use already that bring in half the
internet (e.g., any Hadoop-related dependencies), so I wouldn't worry too
much about it. ;)


I don't think we should contribute in making it worse.

https://en.wikipedia.org/wiki/Broken_windows_theory

[Log4j] Clean-up of GitHub PR:s

[Mikael Ståldal]

I am trying to do some clean-up among GitHub PR:s.

* What is the status of this? 
https://github.com/apache/logging-log4j2/pull/107


* Is this still relevant, or can it be closed? 
https://github.com/apache/logging-log4j2/pull/111


* This one hasn't been touch for over a year: 
https://github.com/apache/logging-log4j2/pull/47

Re: [Log4j] Wrong mailing list

[Mikael Ståldal]

OK, and I see that it is correct now, but was updated after the last 
release. Should fix itself when we do the next release then.



On 2017-11-05 17:13, Matt Sicker wrote:

On Sun, Nov 5, 2017 at 08:48, Mikael Ståldal <mi...@apache.org> wrote:


I think this page is out of date:
https://logging.apache.org/log4j/2.x/mail-lists.html

It still refer to the log4j-...@logging.apache.org mailing list.

I am not sure how to change that page, it seems to not be part of the
Maven site build of the project.



I think that’s controlled by the project info in the root pom.xml

[Log4j] PatternLayout %enc{HTML}

[Mikael Ståldal]

Why does it need to escape slash '/'?

[Log4j] Wrong mailing list

[Mikael Ståldal]

I think this page is out of date: 
https://logging.apache.org/log4j/2.x/mail-lists.html


It still refer to the log4j-...@logging.apache.org mailing list.

I am not sure how to change that page, it seems to not be part of the 
Maven site build of the project.

Re: [meta] Draft blog post about logging in general

[Mikael Ståldal]

Nice!

Maybe Logstash and Graylog should be refered to as "products" rather 
than "projects".


And since Logstash doesn't really provide the desired functionallity by 
itself, maybe refer to the "ELK stack" instead.



On 2017-10-30 19:09, Matt Sicker wrote:

In preparation for an upcoming talk I'll be doing for CJUG, I'm writing a
blog post about introductory concepts to logging from both a developer and
operator point of view. My current draft is available here: <
https://github.com/jvz/jvz.github.io/blob/logging/_posts/2017-10-30-logging.md>.
Let me know what you think!

Re: [Log4j] Next release?

[Mikael Ståldal]

Are we ready now?


On 2017-10-12 22:02, Ralph Goers wrote:

I have a number of issues I have grabbed. I need to look through them and see 
what I can do.

However, I want to get the Automatic-Module-Name headers in. I’ve done the work 
but am waiting to finalize what the names should be based on Stephen 
Colbourne’s recommendations.

Ralph


On Oct 12, 2017, at 12:36 PM, Mikael Ståldal <mi...@apache.org> wrote:

Is there any ongoing work that we want to wait for?

I would like to do these:

- https://issues.apache.org/jira/browse/LOG4J2-2062 (waiting for contributor to 
update his PR, will do it myself soon if he doesn't respond timey)

- https://issues.apache.org/jira/browse/LOG4J2-2069 (looks quite serious if it 
is valid)

Anything else?


On 2017-10-12 21:12, Mikael Ståldal wrote:

Some users are eager to get access to some newly added features:
https://github.com/apache/logging-log4j2/pull/110
When do we plan to do a 2.10.0 release?

Re: Test failures in log4j-taglib

[Mikael Ståldal]

It happened when Spring Framework was upgraded to 4.x.


On 2017-10-23 20:14, Ralph Goers wrote:

So does this mean that log4j-taglib no longer supports servlet 2.5?  How did 
this happen with no changes?

Ralph


On Oct 23, 2017, at 8:21 AM, Gary Gregory <garydgreg...@gmail.com> wrote:

On Thu, Oct 19, 2017 at 2:14 PM, Ralph Goers <ralph.go...@dslextreme.com 
<mailto:ralph.go...@dslextreme.com>>
wrote:


I am wondering why this is suddenly failing. Was it changed recently?

Ralph


On Oct 19, 2017, at 1:00 PM, Mikael Ståldal <mi...@apache.org> wrote:

The missing class, javax.servlet.SessionCookieConfig is new in Servlet

API 3.x. In log4j-taglib pom, we have this dependency:


 
   javax.servlet
   servlet-api
   2.5
   provided
 

That's causing the issue, when I changed it to 3.0.1 the test pass. Is

there any particular reason for keeping this at version 2.5?



I updated to 3.0.1 with [LOG4J2-2089][TagLib] Update servlet-api provided
dependency from 2.5 to 3.0.1.

Gary





On 2017-10-19 21:27, Ralph Goers wrote:

I’m not sure why that would be. AFAIK that hasn’t been modified in a

long time.

Ralph

On Oct 19, 2017, at 12:15 PM, Mikael Ståldal <mi...@apache.org> wrote:

I get a bunch of these errors in log4j-taglib when trying to build

current master branch locally:


[ERROR] Errors:
[ERROR]   CatchingTagTest.setUp:48 » NoClassDefFound javax/servlet/

SessionCookieConfig

[ERROR]   CatchingTagTest.setUp:48 » NoClassDefFound javax/servlet/

SessionCookieConfig

[ERROR]   CatchingTagTest.setUp:48 » NoClassDefFound javax/servlet/

SessionCookieConfig

[ERROR]   DumpTagTest.setUp:51 » NoClassDefFound javax/servlet/

SessionCookieConfig

[ERROR]   DumpTagTest.setUp:51 » NoClassDefFound javax/servlet/

SessionCookieConfig

Re: Test failures in log4j-taglib

[Mikael Ståldal]

The problem started here:
https://builds.apache.org/job/Log4j%202.x/3135/
https://github.com/apache/logging-log4j2/commit/9126644cf85a52859690bc8499b0c701a8db3ae7

So I guess that the upgrade from Spring Framework 3.x to 4.x by Gary 
caused it.



On 2017-10-19 22:14, Ralph Goers wrote:

I am wondering why this is suddenly failing. Was it changed recently?

Ralph


On Oct 19, 2017, at 1:00 PM, Mikael Ståldal <mi...@apache.org> wrote:

The missing class, javax.servlet.SessionCookieConfig is new in Servlet API 3.x. 
In log4j-taglib pom, we have this dependency:

  
javax.servlet
servlet-api
2.5
provided
  

That's causing the issue, when I changed it to 3.0.1 the test pass. Is there 
any particular reason for keeping this at version 2.5?


On 2017-10-19 21:27, Ralph Goers wrote:

I’m not sure why that would be. AFAIK that hasn’t been modified in a long time.
Ralph

On Oct 19, 2017, at 12:15 PM, Mikael Ståldal <mi...@apache.org> wrote:

I get a bunch of these errors in log4j-taglib when trying to build current 
master branch locally:

[ERROR] Errors:
[ERROR]   CatchingTagTest.setUp:48 » NoClassDefFound 
javax/servlet/SessionCookieConfig
[ERROR]   CatchingTagTest.setUp:48 » NoClassDefFound 
javax/servlet/SessionCookieConfig
[ERROR]   CatchingTagTest.setUp:48 » NoClassDefFound 
javax/servlet/SessionCookieConfig
[ERROR]   DumpTagTest.setUp:51 » NoClassDefFound 
javax/servlet/SessionCookieConfig
[ERROR]   DumpTagTest.setUp:51 » NoClassDefFound 
javax/servlet/SessionCookieConfig