Hello,
I'd like to help fix LOG4J2-2624 and LOG4J2-1606. How can I help?
To me, the challenge is to ensure log4j is initialized the very first time
the ServletContext is provided to any object during application loading and
startup and to stop log4j during the very last event or execution hook a
to mimic how Spring Framework registers itself in the
> ServletContext, though I never got around to doing that, and now I
> typically use JVM-global logging configurations instead, so I never
> revisited that.
>
> On Fri, 22 Jan 2021 at 11:53, Tim Perry wrote:
> >
> > Hell
;d be happy to merge!
>
> On Mon, 25 Jan 2021 at 11:51, Tim Perry wrote:
> >
> > Matt, et al.,
> >
> > I agree the deployment patterns you mention are more common and I
> wouldn't
> > start a new project embedding log4j in each WAR. However, I'
forked
> repo.
>
> On Mon, 25 Jan 2021 at 12:15, Tim Perry wrote:
> >
> > Matt,
> >
> > Thanks for clarifying.
> >
> > I'd be happy to write some tests and submit a PR. How should I submit a
> > pull request? I don't think I can do it fro
Is it okay to import hamcrest to use in the tests?
org.hamcrest
hamcrest
2.2
test
On Mon, Jan 25, 2021 at 10:44 AM Tim Perry wrote:
> Thank you, Matt.
>
> I'll get back to you after I've written some unit tests.
>
> Tim
>
> On Mon, Jan 25, 2021
just try to use
> the JUnit 5 API preferably as not everything has been migrated yet! :)
>
> On Mon, 25 Jan 2021 at 15:06, Tim Perry wrote:
> >
> > Is it okay to import hamcrest to use in the tests?
> >
> >
> > org.hamcrest
> > hamcrest
> >
ease-2.x branch is the current stable branch, while master is
> the 3.x branch right now. I'd suggest release-2.x since we're still
> likely to make at least one (if not more) more 2.x release before 3.0,
> though if you make a PR to both branches, that helps :)
>
> On Tue, 26
I submitted pull request 463 for this work.
https://github.com/apache/logging-log4j2/pull/463
Please let me know if there are any issues you would like me to address.
Thank you,
Tim
On Tue, Jan 26, 2021 at 3:27 PM Tim Perry wrote:
> Okay, I've fully updated the code to use JUnit 5.
Matt,
Thank you. If all is well, I’ll make the equivalent PR for the master branch.
Tim
Tim Perry
(916) 505-3634
> On Jan 28, 2021, at 6:49 PM, Matt Sicker wrote:
>
> Great, thanks for the PR! I'll make sure to review this over the weekend.
>
>> On Thu, 28 Jan 2
How do I link the commits / pull request to JIRA LOG4J2-2624 and
LOG4J2-1606?
>> On Thu, 28 Jan 2021 at 13:47, Tim Perry wrote:
> >>
> >> I submitted pull request 463 for this work.
> >> https://github.com/apache/logging-log4j2/pull/463
> >>
> >
12:59 AM Jochen Wiedmann
wrote:
> On Mon, Jan 25, 2021 at 10:06 PM Tim Perry wrote:
> >
> > Is it okay to import hamcrest to use in the tests?
> >
> >
> > org.hamcrest
> > hamcrest
> > 2.2
> > test
> >
>
> Isn'
Is it possible to merge PR 463 for LOG4J-2624 and LOG4J-1606 for 2.14.1?
On Wed, Feb 3, 2021 at 2:09 AM Volkan Yazıcı
wrote:
> The LOG4J2-2973 fix is there for both master and release-2.x branches –
> thanks to Fabio Ricchiuti!
> I will really appreciate it if somebody can get the 2.14.1 out of
Great! Thank you.
On Wed, Feb 3, 2021 at 8:44 AM Matt Sicker wrote:
> Yes, I'll make sure that it is merged in time for that.
>
> On Wed, 3 Feb 2021 at 10:43, Tim Perry wrote:
> >
> > Is it possible to merge PR 463 for LOG4J-2624 and LOG4J-1606 for 2.14.1?
> >
; > > Matt, if you approve the changes, I can also merge them in a couple of
> > > hours.
> > >
> > > On Wed, 3 Feb 2021, 17:44 Matt Sicker wrote:
> > >
> > > > Yes, I'll make sure that it is merged in time for that.
> > > >
>
Volkan,
Thank you very much!
Tim
On Wed, Feb 3, 2021 at 11:55 AM Volkan Yazıcı
wrote:
> Took some time, but managed to get it merged (with succeeding tests) into
> master.
>
> On Wed, Feb 3, 2021 at 8:39 PM Tim Perry wrote:
>
> > Ideally, yes, but I haven't done any
On master, I noticed that when I build in my IDE that lots of tests in
log4j-core fail but when I build with maven they pass. In the past, when
I've seen this on other projects it was caused by race conditions. I
wonder: are there race conditions in the tests or the code that need to be
addressed?
out the "install" target.
>
> On Wed, 17 Feb 2021 at 13:58, Ralph Goers
> wrote:
> >
> > Yeah, there is a very good chance if you are trying to run tests in core
> in parallel on multiple threads that they will fail. Most of them expect
> their own LoggerContex
iguration a bit more heavily (but also in such a way
> that it works more consistently on Windows apparently?)
>
> On Wed, 17 Feb 2021 at 15:36, Tim Perry wrote:
> >
> > I mean is that:
> >
> > * when I run "mvn install" on the command line then usually 1
e the afterAll(context) method is never called on
the LoggerContextResolver. Would that explain why the file stays locked?
Tim
On Wed, Feb 17, 2021 at 1:49 PM Tim Perry wrote:
> Yes, I am on windows 10. I'm using Zulu OpenJdk for both Java 8 and 11,
> maven 3.6.3, and a fairly new Eclipse.
ay have found the missing link as to why this
> wasn't working properly. In that particular error message, that is
> some race condition where the temporary file is attempted to be
> deleted before the configuration stops.
>
> On Wed, 17 Feb 2021 at 18:19, Tim Perry wrote:
> >
. When the status logger was implemented it
> targeted System.out, which you obviously never want to close. Shortly there
> after the ability to route it to a file instead was added. I guess we just
> never thought to add logic to close it at shutdown.
>
> Ralph
>
> > On Feb 18,
ously we need to make this conditional
based on the OS it is running under...
https://github.com/perry2of5/logging-log4j2/commit/dec236a4d358b9847ad7710f668749241a1b50e5
On Fri, Feb 19, 2021 at 10:26 AM Tim Perry wrote:
> The simplest fix is to add "StatusLogger.getLogger().reset();"
?) This will
> make it easier to review your changes and merge them.
>
> On Mon, Feb 22, 2021 at 8:19 PM Tim Perry wrote:
>
> > I have a fork of log4j2 master that builds on windows here:
> > https://github.com/perry2of5/logging-log4j2
> >
> > For log4j-core, I close t
he code".
>
> Ralph appears to be the best candidate to answer your questions. But again,
> a PR would incentivize others to chime in too.
>
> One final remark, don't forget to update changes.xml too.
>
> On Tue, Feb 23, 2021 at 10:22 PM Tim Perry wrote:
>
> &g
there and then the OutputStream be closed.
> However, I’ve not looked at the code recently so I am not sure what it
> takes to do that.
>
> Ralph
>
> > On Feb 23, 2021, at 2:22 PM, Tim Perry wrote:
> >
> > Thank you, Volkan.
> >
> > I'm not quite
was could
> be difficult.
> Add the call to prepareToStop() as a new Callback to Log4j’s shutdown
> registry. However, this callback would need to run last. The shutdown
> registry currently doesn’t support a way to specify the order of callbacks.
> Support for that would need to be
Would we also have
public String getObject(String) {...}
What will happen when someone calls get and the object that key is mapped
to is not a String? Does it return null? Throw an exception?
Instead of allowing non-string values maybe change the type of data to
Map instead of and avoid t
an get non-string objects back.
On Thu, Mar 25, 2021 at 10:51 AM Ralph Goers
wrote:
> The existing get method does a deep toString on the value object already.
> I’m not sure why we would need a new method if the return value is a String.
>
> Ralph
>
> > On Mar 25, 2021
ar 25, 2021 at 12:17 PM Ralph Goers
wrote:
> You getObject method below returns a String. That is why I said the method
> isn’t needed.
>
> Ralph
>
> > On Mar 25, 2021, at 11:31 AM, Tim Perry wrote:
> >
> > If we are only going to allow strings in the map,
Looks okay on Windows. I built on Windows 10 with Zulu Java 8 / 11 in my
toolchain and Maven 3.6.3 and it succeeded after I disabled the usual
culprits:
* log4j-core fails due to the file locking issue with the status logger
* log4j-layout-template-json failed with a port unavailable issue.
I
m, is this the intended behaviour?
On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker wrote:
> The StatusLogger has various listeners attached. I think adding and
> removing listeners on startup and shutdown of a LoggerContext might be
> a potential way to do this?
>
> On Wed, 24 Feb
reconfigure the existing
logger in StatusConfiguration.configureExistingStatusConsoleListener(),
instead I have the
I am now correctly closing the status logger when the context is stopped.
I'll push the changes to github after I do a full build
On Mon, Apr 19, 2021 at 12:17 PM Tim Perry wrote:
Can any of you recommend an idiots guide to setting up a log4j development
environment in IntelliJ? I have never used IntelliJ before. Eclipse won't
work with a maven project with multiple module-info.java files. There are
bugs into the maven-eclipse tools (m2e) for this.
I cannot see reverting to
mmand
line does.
Now I'm trying to run a unit test by clicking the arrow next to the test
and saying run. However, IntelliJ starts a maven build and runs all the
tests for log4j-core (which contains the test I am trying to run).
Ideas?
Thanks,
Tim
On Mon, Apr 19, 2021 at 3:34 PM Tim P
couple of kinks to work out on that
though. If you want, I can push my changes to GitHub and you could take a look
at those. There is some problem that’s causing some of the test to fail and I
haven’t had time to figure out what the issue is.
Tim
Tim Perry
(916) 505-3634
> On Apr 28, 2021,
ll get to it
> before you but at least that way we might be able to.
>
> Ralph
>
> > On Apr 28, 2021, at 7:55 AM, Tim Perry wrote:
> >
> > Volkan,
> >
> > I should probably withdraw that pull request.
> >
> > It assumes that the status logger
a problem. But if it is going to cause merge conflicts then I
> wouldn’t bother as you can just link to the prior PR for the history.
>
> Ralph
>
> > On Apr 28, 2021, at 7:55 AM, Tim Perry wrote:
> >
> >
> >
> > It assumes that the status logger is not a
ghts on:
1) managing the StatusLogger lifecycle
2) do I need to move my commits from pull 469 to a branch so they remain
accessible?
3) do you want a pull request for the warnings I fixed?
Thanks,
Tim
On Wed, Apr 28, 2021 at 9:06 AM Tim Perry wrote:
> I pushed 46f7b08288e1f8843d293bb75950a
d then clean up the temporary config XML file. I took
the easy way out here.
I did not update changes.xml because nothing I changed affects the end
user. Is this the correct way to do this?
Please provide feedback on this pull request when it is convenient.
Thanks,
Tim
On Mon, May 3, 2021 at 11:
Volkan,
On pull 491 you requested I make variables final. I did so in commit
d70da9e7214d7baa3643363b849e5ec124b7b748.
Does that commit show up for you? Does it resolve the issue you flagged?
Thanks,
Tim
Volkan,
Thanks for the update. I don’t mind waiting, I just didn’t know if I’d
submitted the change in a way that would work.
Tim
Tim Perry
(916) 505-3634
> On May 26, 2021, at 11:14 AM, Volkan Yazıcı wrote:
>
> Hey Tim,
>
> You did a great job there. Unfortunately my
I’m fairly certain the JIT will optimize out the locking operations on the
nested synchronized calls after a while. I’m not sure how soon into the
performance tests that would happen.
Tim
> On Aug 26, 2021, at 10:55 AM, Ralph Goers wrote:
>
> So are you continuing to look at this? Frankly
I see your point.
On Thu, Aug 26, 2021 at 11:21 AM Ralph Goers
wrote:
> While that is true it does mean that we are locking higher up in the call
> stack than we need to be.
>
> Ralph
>
> > On Aug 26, 2021, at 11:13 AM, Tim Perry wrote:
> >
> > I’m fairly cert
I like this idea, but I think it would require non-default permissions for the
account the application runs under on windows. However, it could be feature
that can be switched on.
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links
(String).
>>
>> Gary
>>
>>> The best solution, that I have found so far is letting "cmd" do the
>>> job for me. (The mklink command is not a separate executable, but
>>> build into cmd.)
>>> https://github.com/jochenw/afw/blob/master
I was able to build on Windows 10, with Zulu Java 6.
On Tue, Dec 21, 2021 at 1:29 PM Remko Popma wrote:
> +1 I am changing my vote.
> My earlier pipecleaning program failed because the config had a JmsAppender
> configured in it... My bad.
> Signatures are good.
> Pipecleaning program works on J
Is it worth marching those tests with @Ignore and filing a Jira for each
one? That does seem to set a bad precedent though.
Last time I tried I couldn't get the mainline code to load in IntelliJ or
Eclipse because of the packing changes that were in progress. Did that get
fixed? If so, I might be
issues.apache.org/jira/browse/INFRA-22641
>
> -ck
>
> On Thu, Dec 23, 2021, at 12:25, Tim Perry wrote:
> > Is it worth marching those tests with @Ignore and filing a Jira for each
> > one? That does seem to set a bad precedent though.
> >
> > Last time I tri
I propose that this vote should stay open longer than 72 hours given that we
are coming up on New Years and many people who would wish to weigh in might be
on vacation right now.
Tim
> On Dec 29, 2021, at 2:29 PM, Matt Sicker wrote:
>
> Consistent contributors are frequently invited to be c
I think Ralph is right: there should (could) be a limit on how often the
user is informed but the user does need to be informed.
On Mon, Jan 3, 2022 at 8:32 AM Ralph Goers
wrote:
> I am in favor of limiting the recursion depth to a configurable with a
> default number.
> I fully expect virtually
Maybe I'm missing something, but shouldn't it be 1.2.18? There was already
a log4j release 1.2.8 in 2005.
On Thu, Jan 6, 2022 at 2:54 PM Matt Sicker wrote:
> Plus, the branch name sounds like a tag.
>
> On Thu, Jan 6, 2022 at 3:21 PM Gary Gregory
> wrote:
> >
> > -1 This component reached End-o
Many libraries are producing one code line for the javax.* environment and
another code line for the jakarta.* environment. This is because when
Oracle gave the Eclipse Foundation the J2EE code they required name
changes. This affects code using Servlet API, JPA, Bean Validation,et
cetera.
Spring:
gree we need an equivalent for JPA, JMS, JavaMail, and the tag library.
>
> —
> Matt Sicker
>
>> On Jan 22, 2022, at 18:14, Tim Perry wrote:
>>
>> Many libraries are producing one code line for the javax.* environment and
>> another code line for the jakar
gt; user wants to stick to a Tomcat version <10, they can still do so.
> `org.apache.juli.logging.Log` looks to be intact, hence I don't foresee any
> compatibility issues."
>
> Hence I still think this is a legit upgrade. Am I missing something?
>
> On Sun, Jan 23, 20
following PR, please?
> https://github.com/apache/logging-log4j2/pull/730
> Time, what do you think?
>
> On Mon, Jan 24, 2022 at 10:21 PM Tim Perry wrote:
>
> > Sorry Volkan, I think I somehow searched the wrong pom.xml. I was
> convinced
> > appserver was bringing i
gt; environment. We still have support for Servlet 2.5, so as long as
> these modules don't see a lot of active development and continue to be
> releasable, then I don't see the problem with keeping both for a long
> time.
>
> On Thu, Jan 27, 2022 at 1:44 PM Tim Perry wrote:
&g
lph Goers wrote:
>
> Is there a reason that the javax and Jakarta components can’t both reside
> in the log4j-appserver module? The don’t share the same package space
> so that shouldn’t be a problem.
>
> Ralph
>
>> On Jan 27, 2022, at 12:44 PM, Tim Perry wrote:
&
In that case, should log4j log a warning if more than one provider is included?
Tim
> On Mar 15, 2022, at 1:44 PM, Ralph Goers wrote:
>
> I would not be in favor of this change. Providers have been designed since
> day one that highest wins and it is documented -
> https://logging.apache.or
Will including `com.sun.activation:jakarta.activation` and
`com.sun.mail:smtp` be a problem on application servers
that already include implementations of them? My
knowledge of the J2EE application servers is incomplete
for the modern (Java 11+) versions.
On Tue, Apr 19, 2022 at 5:05 PM Matt Sic
Good point. Thank you, Matt.
On Tue, Apr 19, 2022 at 10:49 PM Matt Sicker wrote:
> If they cause an issue, it's trivial to exclude those dependencies in
> Maven, Gradle, or really any other build system. I suppose we can find
> out from users. :)
>
> On Tue, Apr 19, 2022 a
Yes, you need JDK 8.
https://www.azul.com/downloads/?version=java-8-lts&package=jdk or similar.
On Thu, Apr 21, 2022 at 4:57 PM Mohammed Barayyan
wrote:
> Does that mean I have to install JDK 8? or can I modify the toolchains or
> the pom.xml to achieve that?
>
> On Thu, Apr 21, 2022 at 7:56 PM
Do you remember the last release they worked in. I could use git bisect to find
when they broke if I have a good starting point. I have some time to run it
this afternoon…,
Tim
Tim Perry
(916) 505-3634
> On May 29, 2022, at 11:44 AM, Ralph Goers wrote:
>
> So I have been trying t
They referred to the tests. Do you know a commit they worked at?
Tim
> On May 29, 2022, at 12:43 PM, Ralph Goers wrote:
>
> Who is they? You mean me? This is on the master branch. It has never been
> released.
>
> Ralph
>
>> On May 29, 2022, at 12:31 PM, Tim
I've run into an issue where javac 11+ will emit valid java 8 code for
functions that weren't added to Java until after java 8. When the code is
run on Java 8 runtime errors appear complaining about functions missing
from classes that are part of the JRE. Most recently I ran into this when I
used j
> work with the `java18` signature
> <https://mvnrepository.com/artifact/org.codehaus.mojo.signature/java18>?
>
>> On Sun, Jun 12, 2022 at 8:32 PM Tim Perry wrote:
>>
>> I've run into an issue where javac 11+ will emit valid java 8 code for
>> functions tha
Java 11 and explains what went wrong. Thanks for reminding me
what the issue was. Sorry to have brought this up, but I suppose we are
better safe than sorry.
Happy Sunday.
Tim
On Sun, Jun 12, 2022 at 8:26 PM Piotr P. Karwasz
wrote:
> Hi Tim,
>
> On Sun, 12 Jun 2022 at 20:32, Ti
3.x becomes the
> new current will be great since I assume we’d all like to continue
> maintaining bug fixes and such for 2.x for a few years at least.
>
> —
> Matt Sicker
>
> > On Jun 12, 2022, at 16:47, Tim Perry wrote:
> >
> > Piotr,
> >
> >
Karwasz
wrote:
> Hi Tim,
>
> On Tue, 19 Apr 2022 at 19:32, Tim Perry wrote:
> >
> > Will including `com.sun.activation:jakarta.activation` and
> > `com.sun.mail:smtp` be a problem on application servers
> > that already include implementations of them? My
> >
I was going to say the same thing. I'm wondering if there is ever a
situation where someone can download the javadoc jars but not source jars.
On Tue, Feb 14, 2023 at 9:58 AM Piotr P. Karwasz
wrote:
> Hi Matt,
>
> On Tue, 14 Feb 2023 at 17:58, Matt Sicker wrote:
> >
> > ... I’m not sure if IDEs
I see no purpose
> for Javadoc JARs. As a matter of fact, displaying (java)docs from sources
> also enable IDEs to allow users to jump directly to sources too, which I
> think is tremendously convenient.
>
> On Tue, Feb 14, 2023 at 7:57 PM Tim Perry wrote:
>
> > I was going to say
The warning: remote HEAD refers to nonexistent ref, unable to checkout.
means that the remote (bare) repository contains *branch reference* in the
file called HEAD with a value that does not match any published branch in
the same repository. In practice, that file defines *which branch* should
be
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 mo
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
Do dormant projects clearly indicate they can be re-animated by a sufficient
number of active committers?
Thanks,
Tim
How much code is it to support "root" fully? If this is trivial, fully
supporting "root" makes sense. If not, deprecating it makes sense. Heck, do
both! LOL.
On Tue, Nov 19, 2024 at 7:11 AM Piotr P. Karwasz
wrote:
> Hi Gary,
>
> On 19.11.2024 13:08, Gary Gregory wrote:
> > This seems like a nice
75 matches
Mail list logo
