eans due to the use of a few
> listener-related classes, which are exposed in the API of LoggerContext.
>
>
> https://github.com/apache/logging-log4j2/blob/6219e667fdc5aa19e23b699b5eb82dd6d9c61691/log4j-core/src/main/java/org/apache/logging/log4j/core/LoggerContext.java#L23
>
> Woul
Hi.
LoggerContext contains references to java.beans due to the use of a few
listener-related classes, which are exposed in the API of LoggerContext.
https://github.com/apache/logging-log4j2/blob/6219e667fdc5aa19e23b699b5eb82dd6d9c61691/log4j-core/src/main/java/org/apache/logging/log4j/core
figuration` to accept any
> reasonable plugin as a direct subcomponent. We could either:
>
> * do what was done in `log4j-script`: we leave enough interfaces in
> `log4j-core` so that we can keep async-specific stuff in
> `AbstractConfiguration`,
> * or solve this in a more general way by introducing a marker
> `ConfigurationExtension` interface and allow all plugins that
> implement it to be direct children of the configuration.
>
> Piotr
`log4j-jdbc` or
`log4j-smtp`: `AsyncLoggerConfig` and `AsyncWaitStrategyFactoryConfig`
are plugins, the DI system will warn users if it does not know such
plugins.
The tricky part is to modify `AbstractConfiguration` to accept any
reasonable plugin as a direct subcomponent. We could either:
* do what was done in `log4j-script
> 1. Configuration has properties related to async logging:
`asyncLoggerConfigDelegate` and `asyncWaitStrategyFactory`. These
should be removed before the split, but I don't know what would be the
right way to do it.
How would that work?
Will Log4j 3 configurations be incompatible with Log4j 2 con
disruptor`
and `jctools-core` are used, we could break the async features into:
* `log4j-core-async` with the async logger, appender and a
non-optional dependency on `com.lmax:disruptor`. The async appender
does not depend on the Disruptor, but I guess that most async appender
users use it just bec
;>> On Mon, 26 Jun 2023 at 20:33, Ralph Goers
>>> wrote:
>>>>> On Jun 25, 2023, at 11:32 PM, Piotr P. Karwasz
>>>>> wrote:
>>>>>
>>>>> Hi Tim,
>>>>>
>>>>>> On Sat, 24 Jun 2023 at 22:
t 11:32 PM, Piotr P. Karwasz
>>>> wrote:
>>>>
>>>> Hi Tim,
>>>>
>>>>> On Sat, 24 Jun 2023 at 22:00, Tim Perry wrote:
>>>>>>
>>>>>> Can we publish log4j-core so it spits out a deprecation warning and just
n Sat, 24 Jun 2023 at 22:00, Tim Perry wrote:
>>>>
>>>> Can we publish log4j-core so it spits out a deprecation warning and just
>>>> pulls in log4j-impl or log4j-runtime or whatever?
>>>
>>> This is probably the best solution.
>>
>
Hi Ralph,
On Mon, 26 Jun 2023 at 20:33, Ralph Goers wrote:
> > On Jun 25, 2023, at 11:32 PM, Piotr P. Karwasz
> > wrote:
> >
> > Hi Tim,
> >
> > On Sat, 24 Jun 2023 at 22:00, Tim Perry wrote:
> >>
> >> Can we publish log4j-core so it
> On Jun 25, 2023, at 11:32 PM, Piotr P. Karwasz
> wrote:
>
> Hi Tim,
>
> On Sat, 24 Jun 2023 at 22:00, Tim Perry wrote:
>>
>> Can we publish log4j-core so it spits out a deprecation warning and just
>> pulls in log4j-impl or log4j-runtime or what
Hi Tim,
On Sat, 24 Jun 2023 at 22:00, Tim Perry wrote:
>
> Can we publish log4j-core so it spits out a deprecation warning and just
> pulls in log4j-impl or log4j-runtime or whatever?
This is probably the best solution.
We could also consider adding other dependencies to `log4j-core`
Perhaps we can keep the artifact id but advertise the module as something
besides “Log4j Core”? When introducing the hypothetical new name for the
module, we can include a parenthetical “AKA Log4j Core” to clarify.
—
Matt Sicker
> On Jun 22, 2023, at 10:12, Ralph Goers wrote:
>
> Pr
Hi Ralph,
On Sun, 25 Jun 2023 at 00:23, Ralph Goers wrote:
>
> The only thing I am aware of is a “relocation” -
> https://maven.apache.org/guides/mini/guide-relocation.html. This would mean
> continuing to publish log4j-core and have to reference the new artifact.
> However,
The only thing I am aware of is a “relocation” -
https://maven.apache.org/guides/mini/guide-relocation.html. This would mean
continuing to publish log4j-core and have to reference the new artifact.
However, I recall doing that was attempted to redirect log4j 1.x to reload4j
and I don’t recall
Can we publish log4j-core so it spits out a deprecation warning and just
pulls in log4j-impl or log4j-runtime or whatever? That might address
Ralph's concern. If we can't avoid the issues Ralph describes, then I'd
vote -1 too.
On Thu, Jun 22, 2023 at 8:13 AM Ralph Goers
wrote:
Pretend for a moment that you work for a company that has lots of shared
components that don’t always do everything correctly and publish artifacts that
declare a dependency on log4j-core (Note: I do). If we change the name of
log4j-core to something else then suddenly both an older version of
gt; Hi all,
>
> I think one of the main problems preventing Log4j API from being used
> more wildly are naming problems and misinformation on many sites.
>
> Personally I find the name `log4j-core` for our implementation quite
> unfortunate: this is often interpreted as "
Hi all,
I think one of the main problems preventing Log4j API from being used
more wildly are naming problems and misinformation on many sites.
Personally I find the name `log4j-core` for our implementation quite
unfortunate: this is often interpreted as "core Log4j classes", which
sug
+1 for removal of `jansi`
+1 for moving the YAML configuration support to a separate module
+1 for using `JsonReader` in API for reading the JSON configuration
+1 for `log4j-core-starter-async` (Shouldn't it rather be called
`log4j-core-async-starter` according to Spring Boot starter n
, particularly to avoid having to set a system property to enable it.
—
Matt Sicker
> On Jun 19, 2023, at 13:24, Piotr P. Karwasz wrote:
>
> Hi all,
>
> While the list of optional dependencies in `log4j-core` version 3.x is
> much shorter than the one in the 2.x series, we co
; wrote:
>>>>
>>>> I like the idea of not having any optional dependencies by using Maven
>>>> modules.
>>>
>>> I would also like to remove optional dependencies entirely from the
>>> published POM, but I think it is impossible with t
rely from the
> > published POM, but I think it is impossible with the current Maven
> > plugins.
> >
> > My proposal is less ambitious: we would still have
> > `com.lmax:disruptor` as optional dependency of `log4j-core`, but we
> > could also have a `log4j-starter-asy
ve optional dependencies entirely from the
> published POM, but I think it is impossible with the current Maven
> plugins.
>
> My proposal is less ambitious: we would still have
> `com.lmax:disruptor` as optional dependency of `log4j-core`, but we
> could also have a `log4j-starter-async`
Your proposals make sense to me.
Ralph
> On Jun 19, 2023, at 4:24 AM, Piotr P. Karwasz wrote:
>
> Hi all,
>
> While the list of optional dependencies in `log4j-core` version 3.x is
> much shorter than the one in the 2.x series, we could probably still
> improve it a
gins.
My proposal is less ambitious: we would still have
`com.lmax:disruptor` as optional dependency of `log4j-core`, but we
could also have a `log4j-starter-async` that depends (non-optionally)
on `com.lmax:disruptor` and `log4j-core`. This way users don't have to
manually manage
I like the idea of not having any optional dependencies by using Maven
modules.
Gary
On Mon, Jun 19, 2023, 07:24 Piotr P. Karwasz
wrote:
> Hi all,
>
> While the list of optional dependencies in `log4j-core` version 3.x is
> much shorter than the one in the 2.x series, we could pr
Hi all,
While the list of optional dependencies in `log4j-core` version 3.x is
much shorter than the one in the 2.x series, we could probably still
improve it a bit:
* we could remove `jansi`. Since Windows 10 the terminal supports
standard ANSI escapes[1]. On the other hand we broke JANSI
In accordance with guidance from the Apache Maven team this artifact is now.
org.apache.logging.log4j
log4j-core-test
2.20.0
Ralph
> On Apr 11, 2023, at 10:05 AM, Aschbrenner, Gerd wrote:
>
> Hello,
> I am using the org.apache.logging.log4j.test.appender.ListApp
Hello,
I am using the org.apache.logging.log4j.test.appender.ListAppender of the:
org.apache.logging.log4j
log4j-core
2.19.0
tests
in some integration tests with the invoker plugin.
I’m testing some pom files with some logging bridge libs if they work as
Hi Volkan,
On Sat, 17 Dec 2022 at 19:50, Volkan Yazıcı wrote:
> 2. Regarding removing the `log4j-core` dependency from
> `log4j-slf4j[2]-impl` artifacts in `master`... I see where you are
> coming from and I agree this is _technically_ the right approach. That
> said, comments in
Thanks for chasing this story Piotr.
Let me see if I understand it right:
* `log4j-slf4j-impl` has a `scope=runtime` dependency on `log4j-core`
* This implies that `log4j-slf4j-impl`, next to bridging
log4j-to-slf4j, uses Log4j for the backend
* This implicit _"use of Log4j"_ was
Hi,
Since there is still some activity on LOG4J2-3601[#], I would propose to:
* add `log4j-core` as runtime dependency of `log4j-slf4j2-impl` in 2.x,
* remove `log4j-core` from the runtime dependencies of `log4j-slf4j-impl` in 3.x
Do you have anything against it?
Piotr
[#] https
Darn! I have remarked this discrepancy in 2.16.0-rc1 voting!
On Mon, Dec 13, 2021 at 8:51 PM Gary Gregory wrote:
> Wouldn't this be better:
>
> diff --git
>
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
>
> b/log4j-core/src/ma
t so good.
>
> Gary
>
> On Mon, Dec 13, 2021 at 2:51 PM Gary Gregory wrote:
>
> > Wouldn't this be better:
> >
> > diff --git
> > a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
> > b/log4j-core/src/main/java/org/apache/lo
Never mind, that hard reference is from 2 days ago... BUT... if someone
decides to apply this command to a current version, not so good.
Gary
On Mon, Dec 13, 2021 at 2:51 PM Gary Gregory wrote:
> Wouldn't this be better:
>
> diff --git
> a/log4j-core/src/main/java/org/apache/l
Wouldn't this be better:
diff --git
a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/Interpolator.java
index 75c0a45..9c491ac 100644
---
a/log4j-core/src/main/java/org/apache/logging/log4j/core/l
zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class
This can't be right, can it?
We have a hard reference to that class
in org.apache.logging.log4j.core.lookup.Interpolator
Should we really recommend this?
Gary
On Wed, Apr 14, 2021 at 12:43 AM Ralph Goers
wrote:
> I started doing the work to modularize log4j-core last night. We have a
> blocker in that the disruptor has not had a release in 3 years. They
> committed the change to make it an automatic module over a year ago and
> sinc
Goers
> wrote:
> >
> > I just got an email reply to the issue I created for the Disruptor. They
> created a release this morning with the automatic module name so I should
> be able to pick that up fairly soon.
> >
> >
> /Users/rgoers/projects/apache/logging/log4j/
base.
>>
>> As for exports, that would likely depend on what’s left in core after
>> splitting out the above mentioned things.
>>
>> On Tue, Apr 13, 2021 at 10:43 Ralph Goers
>> wrote:
>>
>>> I started doing the work to modularize log4j-core
> properties files since every other format requires additional modules
> besides base.
>
> As for exports, that would likely depend on what’s left in core after
> splitting out the above mentioned things.
>
> On Tue, Apr 13, 2021 at 10:43 Ralph Goers
> wrote:
>
> &g
That is what is concerning. A lot of those items have already been moved to
their own modules in master. Yet we still have these dependencies.
Ralph
> On Apr 13, 2021, at 10:53 AM, Jochen Wiedmann
> wrote:
>
> On Tue, Apr 13, 2021 at 5:44 PM Ralph Goers
> wrote:
>
>> We also have dependenc
On Tue, Apr 13, 2021 at 5:44 PM Ralph Goers wrote:
> We also have dependencies on things like java.rmi, java.naming, java.sql. I
> am also not clear on whether they are all really optional or not. Ideally,
> the only required dependency we should have is for java.base.
Most likely, those depen
able to pick that up fairly soon.
>
>
> /Users/rgoers/projects/apache/logging/log4j/logging-log4j2/log4j-core/src/main/java/org/apache/logging/log4j/core/tools/picocli/CommandLine.java:[41,11]
> error: package java.sql is not visible
>
> This indicates java.sql is needed for Pico
I just got an email reply to the issue I created for the Disruptor. They
created a release this morning with the automatic module name so I should be
able to pick that up fairly soon.
/Users/rgoers/projects/apache/logging/log4j/logging-log4j2/log4j-core/src/main/java/org/apache/logging/log4j
:
> I started doing the work to modularize log4j-core last night. We have a
> blocker in that the disruptor has not had a release in 3 years. They
> committed the change to make it an automatic module over a year ago and
> since have fully modularized it. They simply haven’t perform
I started doing the work to modularize log4j-core last night. We have a blocker
in that the disruptor has not had a release in 3 years. They committed the
change to make it an automatic module over a year ago and since have fully
modularized it. They simply haven’t performed a release.
As I
> but got no replies so far. Any comments?
>
> [1] https://github.com/apache/logging-log4j2/pull/335/files#r372016555
>
> On Tue, Jan 28, 2020 at 9:00 PM Volkan Yazıcı
> wrote:
> >
> > I've just created a PR[1] contributing LogstashLayout to Log4j core.
>
28, 2020 at 9:00 PM Volkan Yazıcı wrote:
>
> I've just created a PR[1] contributing LogstashLayout to Log4j core.
> Please see the GitHub link for the feedback/support requests. I will
> appreciate a quick review cycle, since I will try my best to invest
> quite some time into this during FOSDEM.
>
> [1] https://github.com/apache/logging-log4j2/pull/335
8? Could be worth
>>> exploring.
>>>
>>> I also noted some clarifications on how plugin dependency injection
>>> currently works so you can simplify some of your wrappers if desired.
>>>
>>> On Tue, 28 Jan 2020 at 13:59, Volkan Yazıcı
>> wrote:
t; > On Tue, 28 Jan 2020 at 13:59, Volkan Yazıcı
> wrote:
> > >
> > > I've just created a PR[1] contributing LogstashLayout to Log4j core.
> > > Please see the GitHub link for the feedback/support requests. I will
> > > appreciate a quick review cycle, since
ome of your wrappers if desired.
>
> On Tue, 28 Jan 2020 at 13:59, Volkan Yazıcı wrote:
> >
> > I've just created a PR[1] contributing LogstashLayout to Log4j core.
> > Please see the GitHub link for the feedback/support requests. I will
> > appreciate a quick rev
t; I also noted some clarifications on how plugin dependency injection
> currently works so you can simplify some of your wrappers if desired.
>
> On Tue, 28 Jan 2020 at 13:59, Volkan Yazıcı wrote:
> >
> > I've just created a PR[1] contributing LogstashLayout to Log4j cor
.
I also noted some clarifications on how plugin dependency injection
currently works so you can simplify some of your wrappers if desired.
On Tue, 28 Jan 2020 at 13:59, Volkan Yazıcı wrote:
>
> I've just created a PR[1] contributing LogstashLayout to Log4j core.
> Please see the Gi
I've just created a PR[1] contributing LogstashLayout to Log4j core.
Please see the GitHub link for the feedback/support requests. I will
appreciate a quick review cycle, since I will try my best to invest
quite some time into this during FOSDEM.
[1] https://github.com/apache/logging-log4j2
c951f556f0709c91b15 (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
is 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
ducer 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
&
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
>&
se 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 bui
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.
Gary
On Mon, Jan 22, 2018 at 1:11 PM, Matt Sicker wrote:
> The Kafka test could probably
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.
>
For my money, using mocks here does not guarantee anything :-(
Gary
>
> On 22 January 2018 at 14:08, Gary Gr
Maybe, but is that as reliable as what is currently done.
FWIW, Kafka is another one that should be moved. The issue with a lot of these
tests is that the smallest granularity that can be counted on for a file last
modified time is 1 second. That means the unit test often has to wait for
longer
Lame formatting, I put these results here as well:
https://pastebin.com/grKtxPTq
Gary
On Mon, Jan 22, 2018 at 1:08 PM, 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 lo
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
>
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.KafkaAppenderTest
33.799
org.apache.logging.log4j.core.appender.routing.Rout
53, Mikael Ståldal wrote:
>>
>> We try to keep binary compatibility for appenders and layouts in
>>> log4j-core. Does that apply to the managers used by appenders as well?
>>>
>>
,
so implementation compatibility would make sense.
On 5 October 2017 at 11:53, Mikael Ståldal wrote:
We try to keep binary compatibility for appenders and layouts in
log4j-core. Does that apply to the managers used by appenders as well?
. For managers, users can extend the classes,
> so implementation compatibility would make sense.
>
> On 5 October 2017 at 11:53, Mikael Ståldal wrote:
>
> > We try to keep binary compatibility for appenders and layouts in
> > log4j-core. Does that apply to the managers use
for appenders and layouts in
> log4j-core. Does that apply to the managers used by appenders as well?
>
--
Matt Sicker
ility for appenders and layouts in log4j-core.
> Does that apply to the managers used by appenders as well?
>
We try to keep binary compatibility for appenders and layouts in
log4j-core. Does that apply to the managers used by appenders as well?
This seems like something that would be easier to support with a modular
log4j-core, though that's a much larger effort than fixing missing class
issues.
On 13 September 2017 at 10:37, Ralph Goers
wrote:
> Great. But how would you do it?
>
> Ralph
>
> > On Sep 13, 2017, a
Great. But how would you do it?
Ralph
> On Sep 13, 2017, at 7:11 AM, Gary Gregory wrote:
>
> I would like to see support for Android, all in our one code base, for now.
>
> Gary
>
> On Sep 13, 2017 08:02, "Ralph Goers" wrote:
>
>> We are getting Jira issues about getting log4j to work in An
Even though some people want log4j-core features on Android, I think
it's more important to at least get log4j-api to work properly on
Android. Sooner or later, some Android apps will depend on a Java
library which depends on log4j-api, and it would be good if that doesn't
break t
I would like to see support for Android, all in our one code base, for now.
Gary
On Sep 13, 2017 08:02, "Ralph Goers" wrote:
> We are getting Jira issues about getting log4j to work in Android. At
> first, all I thought was required was getting the API to function on top of
> Android’s logging
We are getting Jira issues about getting log4j to work in Android. At first,
all I thought was required was getting the API to function on top of Android’s
logging system. However, it seems that there are some who want to use the
RollingFileAppender or perhaps other appenders. The issue I have i
x27;t Fix. No reason was given. However, they
have verified that this bug does not occur in Java 9 and they verified that it
occurs in the latest releases of Java 8.
> Having log4j-core on the compile classpath somehow breaks compilation even if
> I&#
eleasing.
>>>
>>> On 30 August 2017 at 09:46, Gary Gregory wrote:
>>>
>>>> Hi All,
>>>>
>>>> My build is going fine with 2.9.0 from MC but I do not see the
>>>> log4j-core-its in MC:
>>>&g
will be corrected
for the next release.
Ralph
> On Aug 30, 2017, at 7:46 AM, Gary Gregory wrote:
>
> Hi All,
>
> My build is going fine with 2.9.0 from MC but I do not see the
> log4j-core-its in MC:
>
> https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22log4j-core-its
delete
> > that from the staging repo before releasing.
> >
> > On 30 August 2017 at 09:46, Gary Gregory wrote:
> >
> > > Hi All,
> > >
> > > My build is going fine with 2.9.0 from MC but I do not see the
> > > log4j-core-its in
Gary Gregory wrote:
>
> > Hi All,
> >
> > My build is going fine with 2.9.0 from MC but I do not see the
> > log4j-core-its in MC:
> >
> > https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22log4j-core-its%22
> >
> > Shouldn't it be there?
> >
> > Gary
> >
>
>
>
> --
> Matt Sicker
>
I was the one who published 2.8.2, and I think I simply forgot to delete
that from the staging repo before releasing.
On 30 August 2017 at 09:46, Gary Gregory wrote:
> Hi All,
>
> My build is going fine with 2.9.0 from MC but I do not see the
> log4j-core-its in MC:
>
> https:
Hi All,
My build is going fine with 2.9.0 from MC but I do not see the
log4j-core-its in MC:
https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22log4j-core-its%22
Shouldn't it be there?
Gary
8 PM:
--
I have submitted a bug report with Oracle. The bug report can be found at
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8186647.
was (Author: ralph.go...@dslextreme.com):
I have submitted a bug report with Oracle. Waiting for a response.
> Having log4j-core on the compile cl
h my Processor class it worked as well. When I
added -verbose I noticed that the annotation processor wasn't running. From
that I figured out I had forgotten to add the META-INF/services/ file to
declare the annotation processor. Maybe you did something similar.
> Having log4j-core on the compi
hich previously had worked, so
I tried it with lombok, and the same happens there.
So now I'm confused as to how it worked, but maybe I had accidentally run the
build with Java 9, which doesn't appear to exhibit the problem.
> Having log4j-core on the compile classpath somehow b
acle. Waiting for a response.
> Having log4j-core on the compile classpath somehow breaks compilation even if
> I'm not calling it
>
>
> Key: LOG4J2-1925
>
ve an interest in
seeing this be fixed.
> Having log4j-core on the compile classpath somehow breaks compilation even if
> I'm not calling it
>
>
> Key: LOG4J2
-Xdoclint:all is used and an annotation
processor, such as Log4j's, is present. So we definitely have an interest in
seeing this be fixed.
> Having log4j-core on the compile classpath somehow breaks compilation even if
> I'
sses/main:build/resources/main:$HOME/.m2/repository/org/apache/logging/log4j/log4j-core/2.9-SNAPSHOT/log4j-core-2.9-SNAPSHOT.jar:$HOME/.m2/repository/org/apache/logging/log4j/log4j-api/2.9-SNAPSHOT/log4j-api-2.9-SNAPSHOT.jar
-Xdoclint:all,-missing -verbose src/main/java/com/acme/Utils.java
[search path
ss for a better way
> of
> > comparing versions.
> >
> > On 15 July 2017 at 11:30, wrote:
> >
> >> Repository: logging-log4j2
> >> Updated Branches:
> >> refs/heads/master 8133b6a02 -> 9a08eb08f
> >>
> >>
> >> LOG4J2-
t; comparing versions.
>
> On 15 July 2017 at 11:30, wrote:
>
>> Repository: logging-log4j2
>> Updated Branches:
>> refs/heads/master 8133b6a02 -> 9a08eb08f
>>
>>
>> LOG4J2-1971 - Register Log4j-core as a service. Bypass tests that don't
>> w
If this is purely OSGi, you can use their Version class for a better way of
comparing versions.
On 15 July 2017 at 11:30, wrote:
> Repository: logging-log4j2
> Updated Branches:
> refs/heads/master 8133b6a02 -> 9a08eb08f
>
>
> LOG4J2-1971 - Register Log4j-core as a servi
[
https://issues.apache.org/jira/browse/LOG4J2-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-713:
--
Labels: Android (was: )
> Android: java.lang.VerifyError: org/apache/logging/log4j/core/u
ing log4j-core yields a compilation warning with -Xlint:all
> -
>
> Key: LOG4J2-1937
> URL: https://issues.apache.org/jira/browse/LOG4J2-1937
> Project: Log4j 2
>
ava -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
{code}
> Including log4j-core yields a compilation warning
e the issue (almost
none). Just go in the folder and do the the usual {{gradle build}}.
Thanks for looking into this issue.
> Including log4j-core yields a compilation warning with -Xlint:all
> -
>
>
Guillaume Dumont created LOG4J2-1937:
Summary: Including log4j-core yields a compilation warning with
-Xlint:all
Key: LOG4J2-1937
URL: https://issues.apache.org/jira/browse/LOG4J2-1937
Project
1 - 100 of 120 matches
Mail list logo
