Re: [log4cxx] Board report entry
There's nothing major going on at the moment, just some various improvements to the code to make it more efficient. I'm not sure if Stephen has anything else to add. -Robert Middleton On Tue, Apr 30, 2024 at 10:21 AM Volkan Yazıcı wrote: > > Can a Log4cxx maintainer share what is getting cooked since March 20, > please? A short summary of 3-4 sentences would suffice. See the past reports > <https://whimsy.apache.org/board/minutes/Logging_Services.html> for > inspiration.
Re: [VOTE] Release Apache Log4net 2.0.16
+1 Verified the following: * apache-log4net-source-2.0.16.zip and associated sha/signature * apache-log4net-binaries-2.0.16.zip and associated sha/signature It looks all good to me. -Robert Middleton On Tue, Mar 5, 2024 at 1:20 AM Ralph Goers wrote: > > +1 > > Verified signatures > Verified hashes > Verified License and Notice files. > > Note - the copyright year should be the first year the code was created. You > can update it to include “-(currentYear}” but that is not strictly necessary. > > Ralph > > > On Mar 4, 2024, at 10:48 AM, Jan Friedrich wrote: > > > > +1 > > > > Unit tests on my machine were successful. > > We integrated the new version into our test environment and all manual > > tests were successful. > > > > Jan > > > >> +1 > > > >> Verified signatures. > >> Verified hashes. > > > >> `NOTICE` contains 2022 as the copyright year, but I don't find it a > >> blocker. (I have fixed it in `master`.) > > > >> On Fri, Mar 1, 2024 at 2:19 PM Davyd McColl wrote: > > > >>> Hi all > >>> > >>> > >>> This is the vote to release Apache log4net version 2.0.16 > >>> > >>> > >>> Website: > >>> https://logging.staged.apache.org/log4net/release/release-notes.html > >>> > >>> GitHub: https://github.com/apache/logging-log4net > >>> > >>> GitHub release (pre-release): > >>> https://github.com/apache/logging-log4net/releases/tag/2.0.16-rc1 > >>> > >>> Distribution: I'm not sure - > >>> https://dist.apache.org/repos/dist/dev/logging/log4net should have > >>> 2.0.16 binaries and source (I've added via SVN), but I'm not seeing > >>> them. Any help appreciated. > >>> > >>> > >>> > >>> Please have a look at the staging site & artifacts and test (if you can > >>> - clone, `npm i`, `npm test`) > >>> > >>> [ ] +1, release the artifacts > >>> > >>> [ ] -1, don't release, because > >>> > >>> > >>> (thanks Piotr: I copied most of your last VOTE mail!) > >>> > >>> > >>> -d > >>> > >>> > > >
Re: Migrate *all* Issue Tracking and Discussions to GitHub
I have no strong feelings either way. Turning on github discussions is a good idea in my mind. +0 -Robert Middleton On Tue, Feb 13, 2024 at 12:45 PM Jan Friedrich wrote: > +1 from me > > Jan > > XA> +1. > XA> > XA> From: Matt Sicker > XA> Sent: Wednesday, February 14, 2024 1:22:48 AM > XA> To: Apache Logging Developers List > XA> Subject: Re: Migrate *all* Issue Tracking and Discussions to GitHub > > XA> I think it’s a good idea, especially since Jira registrations are > closed. > > >> On Feb 13, 2024, at 02:20, Volkan Yazıcı wrote: > >> > >> Log4j has deprecated JIRA in favor of GitHub Issues and enabled GitHub > >> Discussions as an alternative (not replacement!) to mailing lists. So > far > >> it has been a great success[1]. I suggest doing the same for Log4cxx and > >> Log4net too. Thoughts? Objections? > >> > >> Note that I am not talking about only enabling these features. But to > >> actively promote them on the website too. Check out the Log4j support > page > >> <https://logging.apache.org/log4j/2.x/support.html> for an example. > >> > >> [1] Code was already on GitHub. Now we can refer to PRs, issues, > commits, > >> code blocks, etc. while having conversations on any GitHub text input. I > >> find this quite convenient. IMO, as a result of this convenience, I see > way > >> more maintainer engagement in PRs and issues. Next to that, GitHub > >> Discussions clearly enabled more user interactions. It works around the > >> mailing list subscription barrier. > >
Re: [chainsaw] Status change?
+1 While I agree that it can be useful, it was never really in a state where it is. I think it has a lot of good ideas, but to make it more modern and practical it needs to have a much better workflow. I may mess around with it more at some point, but it would take a lot to be practical. If there is a concerted effort in the future to improve it by people who do find it useful, I would definitely be open to looking at it again. -Robert Middleton On Wed, Feb 7, 2024 at 2:56 AM Volkan Yazıcı wrote: > > +1 > > Allow me to make some corrections: > > `XmlLayout` is dropped in Log4j 3, not in Log4j 2. > > Logstash (the L in the ELK, Elasticsearch-Logstash-Kibana, stack) supports > reading logs from a file formatted using a particular pattern. You combine > Filebeat with grok filter > <https://www.elastic.co/guide/en/logstash/current/advanced-pipeline.html> > to achieve that. > > > On Wed, Feb 7, 2024 at 5:19 AM Scott Deboy wrote: > > > Thank you for spending time working on it Christian. > > > > I started contributing to Chainsaw in 2003. I agree. It's time. > > > > The primary benefit of Chainsaw was its built-in support for real-time > > tailing of ssh-accessible pattern-layout based logs - something > > Kibana doesn't support well, and something no-one ever really > > understood about it. > > > > It was always a dev-focused tool - it works great for local dev, and > > works in some prod envs, if you spend enough time to get the setup to > > work. > > > > There was no great reason to move off of the log41 deps really - they > > aren't used for anything other than parsing the patternlayout, but > > log4j1 is dead, so I get it. > > > > I use it for my work, and will continue to do so, but the > > chainsaw-with-log4j1-dep branch. I may revert master back to that, > > because why not. > > > > +1 > > > > Thanks again for putting up with my persistence to try and make it > > useful to folks - I appreciate it :) > > > > Scott > > > > > > On 2/6/24, Christian Grobmeier wrote: > > > Hello > > > > > > we have had Chainsaw for a long time in our product list, and I can > > totally > > > see that some - myself included - are emotionally attached to it. > > However, > > > due to my work on it, I have given it some additional thought. > > > > > > After working with the Chainsaw code base for a while, I saw that many > > > features were commented out and removed when migrating to Log4j 2. > > > > > > Some basic features, such as "Open Logfile to view it directly." were > > > removed. It is already hard to recover the functionality since > > log4j-extras > > > no longer exists. In addition, as I learned recently, Log4j 2 has removed > > > the XML Formatter. The old implementation of Chainsaw could only open > > > XML-formatted log files. > > > > > > Honestly, there is much work to make Chainsaw a working product again. I > > > mostly did refactorings and clean-ups, but I am not even through. I could > > > continue like this for two more months. > > > > > > Restoring the old functionality and making it functional again requires > > even > > > more months. > > > If we had completed it, we would have restored a Swing application, > > mostly > > > replaced by Kibana stacks. > > > > > > At this point, I don't see how we can write the tons of code necessary, > > and > > > also not how useful it would be. Either all our users are using Log4j 1, > > or > > > we don't have any users at all for Chainsaw, since it didn't work. > > > > > > For that reason, I would like to propose to move Chainsaw to dormant. If > > we > > > feel for it, we can work and fix it - we should not archive the repo. > > But I > > > would like to make clear that Chainsaw is not in good shape, and people > > > should only use it only "at their own risk." > > > > > > I would like to make clear that this proposal is not something I say > > easily, > > > but I feel it is in the best interest of our users to communicate how we > > > currently see the status of this project. > > > > > > Please note, that I don't have much time to continue to work on it in the > > > next months. > > > > > > Remembering the last discussion about this: Scott, are you OK with that > > > move? I know it's your baby, but as long as we don't have a working > > product, > > > we should move it. I am open to moving it back when we somehow get rid of > > > all the problems. > > > > > > Please let me know if one of you has an alternate proposal - we can also > > > discuss it in the next call. > > > > > > Kind regards, > > > Christian > > > > > > -- > > > The Apache Software Foundation > > > V.P., Data Privacy > > > > >
Re: Clean site repo
FWIW I believe that keeping around old sites is useful, but only if there's a banner that says "this is out of date, please use the newest version" with a link to the new version. The reason for keeping them around is that sometimes you are stuck on an older version, so you need that archived documentation(since it is possible that some behavior has changed between versions, and/or a newer API that you want to use is not available with your version). -Robert Middleton On Wed, Feb 7, 2024 at 5:29 AM Piotr P. Karwasz wrote: > > Hi Volkan, > > On Wed, 7 Feb 2024 at 11:05, Volkan Yazıcı wrote: > > I can see the use cases for wanting to keep the website+manual of every > > single release in a dedicated directory. Though my counter arguments are: > > > >1. These pages were never officially linked, hence were not exposed to > >users. What is the pressing need right now to make this happen? > >2. They get search engines confused and cause users to end up in legacy > >pages. > >3. The infrastructure to realize this (putting each release to a > >separate site branch) is cumbersome, difficult to navigate for > > developers, > >deviates from the standard the rest of our websites follow, and hence > >complicates the release process substantially. > >4. We (almost) never break backward compatibility in a major release > >line. Hence, the docs of `2.x` is a superset of the docs of, say, > > `2.22.0`. > >We also always document newly added features as "Starting from version > >`2.22.0`, ..." Given these, I don't see a compelling point of having a > >separate website for `2.22.0`. > > I might add that documentation is never bug-free and I consider the > documentation of a release as important as the release itself. > > Since the only maintained releases are 2.22.x and 3.x (and perhaps > 2.3.x and 2.12.x for security updates), I don't see a reason to > publish the documentation of anything else than those releases. > > BTW: we should add a banner to the 1.x, extras, 2.3.x and 2.12.x > websites that states that they refer to archived software that reached > EOL. > > Piotr
[log4cxx] Github discussions
Would people be in favor of enabling Github discussions for Log4cxx? We don't get many reports, but we do occasionally get support questions as issues. INFRA needs to turn this on, there's no way for us to do it manually, hence this question. -Robert Middleton
Re: [VOTE] Release log4cxx 1.2.0-RC1
The vote passes with +1 votes from Volkan, Piotr, Matt, and Stephen(in the release review kit thread). I will continue with the release. -Robert Middleton On Fri, Dec 29, 2023 at 3:08 PM Matt Sicker wrote: > > +1 > > Same checks as Volkan. Platform build info: > > cmake version 3.28.1 > GNU Make 3.81 > Apple clang version 15.0.0 (clang-1500.1.0.2.5) > Target: arm64-apple-darwin23.2.0 > Thread model: posix > pkg-config: 0.29.2 > apr-1: 1.5.2 > apr-util-1: 1.5.4 > EXPAT: 2.5.0 > > — > Matt Sicker > > > On Dec 28, 2023, at 18:00, Robert Middleton wrote: > > > > This is a vote to release log4cxx 1.2.0-RC1. > > > > Please download, test, and cast your votes on the log4j developers list. > > [] +1, release the artifacts > > [] -1, don't release because... > > > > This 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. > > > > A quick changelog is below: > > * Various build failures have been fixed > > * Added a new Hexdump utility method to dump arbitrary memory > > * Fixed a segfault when shutting down and not stopping the library > > * QStrings may now be logged directly > > * The main namespace is now configurable from log4cxx to any value > > that is desired > > > > Tag: > > For a new copy do "git clone > > https://github.com/apache/logging-log4cxx.git; and then "git checkout > > tags/v1.2.0-RC1" > > For an existing working copy, do "git pull" and then "git checkout > > tags/v1.2.0-RC1" > > > > Web site: https://logging.staged.apache.org/log4cxx/latest_stable/ > > > > Distribution archives: > > https://dist.apache.org/repos/dist/dev/logging/log4cxx/ > > > > Building directions are on the website(under 'Development'). Note > > that APR is required to build(as well as boost if your compiler does > > not support C++17). > > > > -Robert Middleton >
Re: [log4cxx] Release review kit
1. staging website was in the email 2/3: I use this script to verify things. Feel free to adapt for your own purposes: https://gist.github.com/rm5248/b2abba4bb4f1d9cf518be49d064a0be1 4. Build instructions are on the website: https://logging.staged.apache.org/log4cxx/latest_stable/build-cmake.html Let me know if you want help on doing the build/test. Linux is the easiest, OSX should be pretty easy, and Windows can be difficult. The Github actions do a build and test for all 3 of those platforms. -Robert Middleton On Fri, Dec 29, 2023 at 4:04 AM Volkan Yazıcı wrote: > > I would really appreciate a "review kit" for voting on log4cxx releases: > >1. Where is the staging website? >2. How can I verify the checksum? >3. How can I verify the signatures? >4. How can I build and test the sources? > > (For inspiration, you can check out the review kit we use for Java-based > projects > <https://github.com/apache/logging-parent/blob/main/.github/release-review-kit.txt> > .) > > Maybe there are more things I should be reviewing, but I simply don't know. > Hence, making your expectations clear from a review would not only help > reviewers, but, IMHO, improve the engagement. > > -- Forwarded message - > From: Robert Middleton > Date: Fri, Dec 29, 2023 at 1:01 AM > Subject: [VOTE] Release log4cxx 1.2.0-RC1 > To: > > > This is a vote to release log4cxx 1.2.0-RC1. > > Please download, test, and cast your votes on the log4j developers list. > [] +1, release the artifacts > [] -1, don't release because... > > This 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. > > A quick changelog is below: > * Various build failures have been fixed > * Added a new Hexdump utility method to dump arbitrary memory > * Fixed a segfault when shutting down and not stopping the library > * QStrings may now be logged directly > * The main namespace is now configurable from log4cxx to any value > that is desired > > Tag: > For a new copy do "git clone > https://github.com/apache/logging-log4cxx.git; and then "git checkout > tags/v1.2.0-RC1" > For an existing working copy, do "git pull" and then "git checkout > tags/v1.2.0-RC1" > > Web site: https://logging.staged.apache.org/log4cxx/latest_stable/ > > Distribution archives: > https://dist.apache.org/repos/dist/dev/logging/log4cxx/ > > Building directions are on the website(under 'Development'). Note > that APR is required to build(as well as boost if your compiler does > not support C++17). > > -Robert Middleton
[VOTE] Release log4cxx 1.2.0-RC1
This is a vote to release log4cxx 1.2.0-RC1. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... This 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. A quick changelog is below: * Various build failures have been fixed * Added a new Hexdump utility method to dump arbitrary memory * Fixed a segfault when shutting down and not stopping the library * QStrings may now be logged directly * The main namespace is now configurable from log4cxx to any value that is desired Tag: For a new copy do "git clone https://github.com/apache/logging-log4cxx.git; and then "git checkout tags/v1.2.0-RC1" For an existing working copy, do "git pull" and then "git checkout tags/v1.2.0-RC1" Web site: https://logging.staged.apache.org/log4cxx/latest_stable/ Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4cxx/ Building directions are on the website(under 'Development'). Note that APR is required to build(as well as boost if your compiler does not support C++17). -Robert Middleton
Re: [log4cxx] Release time?
If there aren't any objections, I will plan to do a release in a week or so. I'm not aware of any issues that need to be fixed, so having a new release for a new year seems like a good idea. -Robert Middleton On Mon, Nov 20, 2023 at 9:53 AM Robert Middleton wrote: > > It's been a bit over 6 months since the last release, is it time for a > new release? There aren't many new features that would impact a lot > of people, but a good number of maintenance fixes. > > -Robert Middleton
Re: Versioning scheme
This is going to be somewhat subjective and may be on a case-by-case basis, but here are my thoughts: On Mon, Dec 11, 2023 at 2:17 PM Volkan Yazıcı wrote: > > I think this is where we have different ideas. > Robert, could you elaborate on *"change/fix behavior without adding new > method"*, please? For instance, does this cover the following changes? > >- Upgrading a dependency whose patch version is bumped (no behavior >change on the parts we use the dependency) >- Upgrading a dependency whose minor version is bumped (no behavior >change on the parts we use the dependency) >- Upgrading a dependency whose major version is bumped (no behavior >change on the parts we use the dependency) >- Upgrading a dependency whose major version is bumped (no behavior >change on the parts we use the dependency, though the runtime requirements >of the dependency has changed, e.g., started requiring Java 17 instead of >Java 8, etc.) >- `sum(a,b)` has changed from `a+b` to `a-b` (behaviour change, no new >method) >- `sum(a,b)` has started using GPUs (no change visible to the user, >though substantial implementation change) > I think all of these would be either a patch/minor version change - semver is showing users of your library(in this case log4j) what YOU provide, not what you depend on. The more difficult/large the change is(using GPU, bumping a dependent library) I would argue is grounds for a minor version bump. Since the API that log4j provides does not change in any of these circumstances, there is no need to bump the major version(although you could if you want, I suppose). The examples I gave before are when you must increment the version number(according to my understanding) - I don't see any issue in increasing the version number when you are not in one of those scenarios. For example, the Linux kernel has a somewhat arbitrary major number, since it doesn't really tell you what API the kernel has(there is no stable interface inside of the kernel). -Robert Middleton
Re: Versioning scheme
remove method/class OR change method arguments OR class size changes(C++) = major version bump add new method/class = minor version bump change/fix behavior without adding new method = patch That should be the criteria for when to bump, at least according to semver as far as I understand. -Robert Middleton On Mon, Dec 11, 2023 at 11:15 AM Christian Grobmeier wrote: > > Hi Volkan, > > I am not sure what you are proposing. > > On Mon, Dec 11, 2023, at 10:26, Volkan Yazıcı wrote: > > I propose embracing a common versioning scheme across all Logging Services > > projects; log4j, log4cxx, etc. > > As you already mentioned, except for some parts of Log4j 1, we are following > server already, and it looks like everybody knows about it. > > > match the `[0-9]+(-(alpha|beta)[1-9]+)?` That is, only the following will > > be valid: `1.2.3`, `1.2.3-alpha4`, `1.2.3-beta4`, etc. > > We have only 3.0.0 with the alpha label. You are not against it, I guess? > > >- *MAJOR version when you make incompatible API changes* > > - *MINOR version when you add functionality in a backward compatible > > manner* > > - *PATCH version when you make backward compatible bug fixes* > > > > We mostly have a problem whether the next release needs a minor or patch > > version bump. I propose to refine the official semantics as follows: > > > > Are we making a release to *only* address a set of particular issues? That > > is, does the following hold? > > > > [next release] = [last release] + [fix1] + [fix2] + ... + [fixN] > > > > If so, this needs a patch version bump. Otherwise, this is a minor version > > bump. > > I assume with "issue" and "fix" you mean "bug fix". > > I don't understand what is the difference to what semver says. > When you add functionality, it's a minor. If you just add fixes, it's a patch. > Did I miss something that we are doing differently?
Re: Future release schedule
>From a user perspective, sometimes having releases too often leads to upgrade fatigue. Eventually it becomes easier to not upgrade, because so many things have changed in the interim that it becomes very annoying to attempt to upgrade things. For comparison, Ubuntu will do releases every 6 months, with LTS support on their releases every 2 years. This is reasonable, but may not be something enough people can commit to. If things are properly versioned(API/ABI stable), then it shouldn't be an issue to do frequent upgrades. If things are stable though, is there a need to do a new release? Since users should only be interacting with the API, perhaps it makes sense to do core releases more often than API releases, but that would mean committing to allowing mismatched log4j-api and log4j-core versions. -Robert Middleton On Mon, Dec 4, 2023 at 5:04 PM Christian Grobmeier wrote: > > Hi Piotr, > > I think scheduled releases that everybody can follow are great and your > proposal makes sense. > > Does this also mean we don't have that many "noise" emails from upgraded > dependency (releases)? > > I have come to realize in the past months that "inclusion" is most important, > and that would also mean slowing down things a bit so that everybody can > review. > > Thanks! > > Kind regards, > Christian > > > On Mon, Dec 4, 2023, at 22:15, Piotr P. Karwasz wrote: > > Hi all, > > > > Since we have a fast and easy release process now and a release does > > not require a free weekend any more, I think we should have a regular > > release schedule. > > > > Unless something exceptional happens (e.g. big bug that renders > > `log4j-jcl` unusable ;-) ), I would propose to: > > > > * have a patch release every month, > > * have a minor release every quarter. > > > > I can do a 2.22.1 release during the week of December 18th. > > > > Regarding minor releases, I am not a big fan of them. I would prefer > > to wait for more than a single small new feature to appear in the > > code, before making a minor release. > > > > I am getting (professionally) old and hopefully wiser. I think users > > eager for new features can wait, while most users want stability and > > releases that are less prone to break. We could even designate a > > popular minor release as LTS (e.g. 2.22.0) and work on three branches: > > > > * `main` for 3.x, > > * `2.x` for the next minor release, > > * `2.22.x` for the next patch release. > > > > Changes that are not invasive would be applied to all three, new > > features to the first two, while breaking changes to the first one. > > > > What do you think? > > > > Piotr
[log4cxx] Release time?
It's been a bit over 6 months since the last release, is it time for a new release? There aren't many new features that would impact a lot of people, but a good number of maintenance fixes. -Robert Middleton
Re: [log4j] Unstable tests on Windows
Are the tests run on Windows through Github workflows? It doesn't look like it to me. If you need access to a Windows machine, you can download a development VM straight from Microsoft: https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/ -Robert Middleton On Mon, Nov 20, 2023 at 7:40 AM Apache wrote: > > In my experience they never get fixed. To be honest, when I was doing the > releases I would have these failures investigated to determine if it was a > trait problem vs a problem in the code being released. If it was the latter I > would cancel the vote. The only time tests should be disabled is if we know > it is a problem in the test but can’t figure out how to fix it. > > I also don’t ever recall Gary ever having more than one or two tests fail in > a run. > > Ralph > > > On Nov 20, 2023, at 5:00 AM, Volkan Yazıcı wrote: > > > > I am not asking to disable Windows tests. I am asking to disable tests > > and only those tests that have a failure rate on Windows higher than, > > say, 30%. To be precise, I think there are 2-3 of them dealing with > > network sockets and rolling file appenders. I am not talking about > > dozens or such. > > > > After disabling them, we can create a ticket referencing them. So that > > interested parties can fix them. > > > >> On Mon, Nov 20, 2023 at 12:25 PM Piotr P. Karwasz > >> wrote: > >> > >> Hi Volkan, > >> > >>> On Mon, 20 Nov 2023 at 09:36, Volkan Yazıcı wrote: > >>> > >>> As Gary (the only Windows user among the active Log4j maintainers, > >>> AFAIK) has noticed several times, Log4j tests on Windows are pretty > >>> unstable. It not only fails on Gary's laptop, but Piotr and I need to > >>> give Windows tests in CI a kick on a regular basis. Approximately one > >>> out of three CI runs fails on Windows. Piotr already improved the > >>> situation extensively, though there are still several leftovers that > >>> need attention. > >>> > >>> Unless somebody steps up to improve the unstable Windows tests, I > >>> would like to disable those only for the WIndows platform. > >> > >> Please don't. Windows has an annoying file locking policy that > >> prevents users from deleting files with open file descriptors, but > >> that is one of the few ways to detect resource leakage we have. > >> > >> Tests running on *NIXes will ignore problems with open file > >> descriptors and delete the log files, but on a production system those > >> leaks will accumulate and cause application crashes. We had such a > >> leak, when we used `URLConnection#getLastModified` on a `jar:...` URL. > >> This call caused file descriptor exhaustion on both Windows and > >> *NIXes, but only the Windows test was able to detect it. > >> > >> Piotr, > >> who never thought would ever defend Microsoft Windows. > >> > >> PS: Gary reports the failures, but always runs the build again until > >> it succeeds, even on Friday 13th, when he had to wait until Saturday > >> 14th for the test run to succeed. >
Re: [PR] Bump org.junit:junit-bom from 5.10.0 to 5.10.1 [logging-log4j-jakarta]
I suspect the settings are on a per-repo basis. Since this is a new repo, it doesn't have the proper settings. -Robert Middleton On Wed, Nov 15, 2023 at 12:56 PM Matt Sicker wrote: > > Why do our email settings keep getting reset? Do we have some default > settings somewhere? > > > On Nov 15, 2023, at 6:19 AM, dependabot[bot] (via GitHub) > > wrote: > > > > > > dependabot[bot] opened a new pull request, #1: > > URL: https://github.com/apache/logging-log4j-jakarta/pull/1 > > > > Bumps [org.junit:junit-bom](https://github.com/junit-team/junit5) from > > 5.10.0 to 5.10.1. > > > > Release notes > > Sourced from > href="https://github.com/junit-team/junit5/releases;>org.junit:junit-bom's > > releases. > > > > JUnit 5.10.1 = Platform 1.10.1 + Jupiter 5.10.1 + Vintage 5.10.1 > > See > href="http://junit.org/junit5/docs/5.10.1/release-notes/;>Release > > Notes. > > Full Changelog: > href="https://github.com/junit-team/junit5/compare/r5.10.0...r5.10.1;>https://github.com/junit-team/junit5/compare/r5.10.0...r5.10.1 > > > > > > > > Commits > > > >> href="https://github.com/junit-team/junit5/commit/e5f50d8720741623915979ac154b65bcbcd6a577;>e5f50d8 > > Release 5.10.1 > >> href="https://github.com/junit-team/junit5/commit/ac86d18e9b15dbebe046e82743ac7f9534a17582;>ac86d18 > > Fix typo in AfterAll documentation > >> href="https://github.com/junit-team/junit5/commit/388c5beaf42944961ab5b455c900d958a6e15588;>388c5be > > Harmonize application of method and field filters in search algorithms > >> href="https://github.com/junit-team/junit5/commit/f82dd1e716f8717e012152b1d1d5cc0da10d33cd;>f82dd1e > > Apply field predicate before searching type hierarchy > >> href="https://github.com/junit-team/junit5/commit/1d1eb8571552bbf28e578241965010de6c8ee779;>1d1eb85 > > Polishing > >> href="https://github.com/junit-team/junit5/commit/5ce280eff69b43759a3cb0c176207abe0a41b579;>5ce280e > > Update picocli to 4.7.5 and enable help width computation > >> href="https://github.com/junit-team/junit5/commit/fea05c3aa80de76686f326b5ce26ddf7f153ff5a;>fea05c3 > > Fix ConsoleLauncherTests and StandaloneTests > >> href="https://github.com/junit-team/junit5/commit/c5567354c2556e772f8a0035ef7647161011d1c0;>c556735 > > Use same expected files for all JDK versions > >> href="https://github.com/junit-team/junit5/commit/808493ab09b30970b506a48fda3d616ac1ba4fff;>808493a > > Run StandaloneTests for Java 8 under Java 8 > >> href="https://github.com/junit-team/junit5/commit/9ec57661c78c3889db004ab6a89416e56a2fb2e0;>9ec5766 > > Unify messages about exit codes in StandaloneTests > > Additional commits viewable in > href="https://github.com/junit-team/junit5/compare/r5.10.0...r5.10.1;>compare > > view > > > > > > > > > > > > [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) > > > > Dependabot will resolve any conflicts with this PR as long as you don't > > alter it yourself. You can also trigger a rebase manually by commenting > > `@dependabot rebase`. > > > > [//]: # (dependabot-automerge-start) > > [//]: # (dependabot-automerge-end) > > > > --- > > > > > > Dependabot commands and options > > > > > > You can trigger Dependabot actions by commenting on this PR: > > - `@dependabot rebase` will rebase this PR > > - `@dependabot recreate` will recreate this PR, overwriting any edits > > that have been made to it > > - `@dependabot merge` will merge this PR after your CI passes on it > > - `@dependabot squash and merge` will squash and merge this PR after your > > CI passes on it > > - `@dependabot cancel merge` will cancel a previously requested merge and > > block automerging > > - `@dependabot reopen` will reopen this PR if it is closed > > - `@dependabot close` will close this PR and stop Dependabot recreating > > it. You can achieve the same result by closing it manually > > - `@dependabot show ignore conditions` will show all of > > the ignore conditions of the specified dependency > > - `@dependabot ignore this major version`
Re: [chainsaw] DB package?
Those classes are to receive log events from a database table. Log4j1 and log4cxx can write log messages directly to a database; I'm not sure about log4j2. I'm not sure exactly what it does/how it does it, but it's going to effectively do something like "SELECT * FROM Logs" and then pass those log messages up to other parts of chainsaw. -Robert Middleton On Tue, Oct 24, 2023 at 4:20 PM Matt Sicker wrote: > > If you use Log4j in Chainsaw, you could set up a JDBC appender or similar to > forward things along. The Flume appender could be useful there, too, but that > sort of moves the database configuration into your Flume config. > > > On Oct 24, 2023, at 3:14 PM, Christian Grobmeier > > wrote: > > > > Hi, > > > > in this package: > > org.apache.log4j.db > > > > all classes are commented. I am tempted to just remove it in full, but I am > > not sure what i was supposed to do. > > > > Docs read: > > > > "Provides means to append logging events into various databases." > > > > Does that mean, Chainsaw would collect logs and then send it to databases? > > Isn't it what Flume (et al) is expected to do? > > > > Kind regards, > > Christian >
Re: Staging sites and repo convention
I'm not quite sure what problems this solves. Are you trying to put the site HTML code and the normal code in the same repository? Are they just different branches in the same repository? What about the currently existing URLs? Would it now be logging-log4j2.logging.a.o instead of logging.a.o/log4j2? I ask because we would want to make sure that redirects are added to try and avoid link rot. -Robert Middleton On Thu, Oct 19, 2023 at 6:05 AM Volkan Yazıcı wrote: > > > Every Git code repository uses a different staging domain name > > +1 > > > The `asf-staging` should not be protected [so that CI/RM can force push] > > +1 > > > For the staging Nexus repo I would propose using a comment to close > > +1 > > > Maybe we could drop the `*-site` Git repositories except `logging-site` > > +999 > > Currently `logging-log4j-site` repository hosts the website for Log4j, > Log4j Tools, Log4j Transformation, Log4j Scala, and Log4j Kotlin, even > though these projects are all located in individual repositories. I > cannot express how awesome it would be to move their website content > to their own repositories, next to their code, where they belong. In > combination with git worktrees, it will be a breeze to work in such a > structure: > > git clone --bare g...@github.com:apache/logging-log4j2.git > cd logging-log4j2.git > git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*" > git worktree add ../logging-log4j2-2.x 2.x > git worktree add ../logging-log4j2-main main > git worktree add ../logging-log4j2-web-stg asf-staging > git worktree add ../logging-log4j2-web-pro asf-site > > Plain beauty! > > On Thu, Oct 19, 2023 at 10:03 AM Piotr P. Karwasz > wrote: > > > > Hi, > > > > Since now we have a fast release process It might happen (and it > > already did) that the voting periods for releases will not be > > disjoint. > > > > That is why I would like to introduce a convention on the procedure to > > stage websites and Nexus repositories. > > > > For websites I would propose: > > > > 1. Every Git code repository uses a different staging domain name. > > E.g. `logging-log4j2` would set: > > > > staging: > > profile: log4j2 > > > > which will result in a https://logging-log4j2.staged.apache.org URI. > > For the `logging-log4j-site` website repo this will also entail that > > it will have multiple staging branches. > > 2. The `asf-staging` should not be protected. Before staging a website > > the Release Manager would perform: > > > > git reset --hard origin/asf-site > > git push -f > > > > hence ensuring that moving changes from the staging branch to > > `asf-site` will be usually a fast-forward and a simple cherry-pick > > `origin/asf-site..asf-staging` at worst. > > > > For the staging Nexus repo I would propose using a comment to close > > the repo in the format: > > > > `` version `` RC1 > > > > For example Volkan used "`logging-parent` version `10.2.0` RC`" on the > > 1204 repo and we can easily guess what that repo contains. ;-) > > > > Piotr > > > > PS: Maybe we could drop the `*-site` Git repositories except > > `logging-site` and move their content to an `asf-site/asf-staging` > > branch of the corresponding code repo.
Re: [chainsaw] What is necessary for a 2.2 release?
For those of you who didn't see on slack: I did update Chainsaw last night so you can load/save receivers. That brings Chainsaw back into a usable state(in my mind at least). I need to check to ensure that everything gets saved properly, but that shouldn't be too hard. Scott, would you mind making some issues on github for features that are needed/were removed? I think one of the biggest problems that I have seen with Chainsaw before is that there isn't a manual(at least now somewhat mitigated) and/or a list of features and how to use them, so I've just been going with what I feel makes the most sense to me. The one thing that Scott pointed out was the ability to route messages to tabs; all the plumbing for that should exist for the most part(each ChainsawReceiver can have 0...N ChainsawEventBatchListener objects). I'm not sure how best to let the user hook things up - some sort of visual programming/flow-based view would be very cool but also very complicated. -Robert Middleton On Mon, Oct 9, 2023 at 3:24 PM Christian Grobmeier wrote: > > On Sun, Oct 8, 2023, at 23:19, Scott Deboy wrote: > > I started but haven't had much time this week. The UI updates driven by > > settings changes are most of what I have left. > > OK great to hear, in that case I hold myself back a little longer :) > > Thanks! > > > > > On Sun, Oct 8, 2023, 2:17 PM Christian Grobmeier > > wrote: > > > >> geson seems to do a good job, like Jackson (same JSR). > >> I'd like to move forward with JSON format for storing properties. > >> > >> I am not sure what the status currently is, if Scott is still working on > >> it :) I could also make some kind of proposal or so for storing properties > >> > >> On Tue, Oct 3, 2023, at 01:20, Scott Deboy wrote: > >> > I think persisting to json format makes sense/would be easy to consume > >> > with tools if needed. > >> > > >> > On 10/2/23, Robert Middleton wrote: > >> >>> OK. Do you think something based on Jackson would be good? It's JSON > >> >>> though. > >> >> > >> >> We already have a dependency on genson for JSON parsing, so if we > >> >> really want to use JSON that would make the most sense. Commons > >> >> config can read/write XML; currently I just have it configured to do > >> >> properties files. I think we can write our own reader/writer as well, > >> >> but ultimately I don't think that there is anything special that we > >> >> need that commons config doesn't provide us out of the box. > >> >> > >> >> -Robert Middleton > >> >> > >> >> On Mon, Oct 2, 2023 at 5:14 PM Matt Sicker wrote: > >> >>> > >> >>> Jackson makes for a good library here because it also supports several > >> >>> data formats (YAML, XML, HOCON, and all sorts of others, both textual > >> and > >> >>> binary) and is fairly extensible for hooking any custom serialization > >> or > >> >>> deserialization logic you need. Given the desire to avoid Java > >> >>> serialization, it is perfectly reasonable to avoid XStream as that’s > >> >>> basically Java serialization using XML with all the pitfalls that > >> entails > >> >>> (I dealt with this fairly extensively back in the Jenkins project which > >> >>> used an old fork of XStream for managing config files and state). > >> >>> > >> >>> I haven’t used Commons Configuration before, but it seems fairly > >> >>> appropriate for this sort of thing as well. > >> >>> > >> >>> > On Oct 2, 2023, at 1:43 PM, Christian Grobmeier < > >> grobme...@apache.org> > >> >>> > wrote: > >> >>> > > >> >>> > On Mon, Oct 2, 2023, at 16:15, Robert Middleton wrote: > >> >>> >> At least two reasons I can think of: > >> >>> >> 1. Xstream doesn’t work on all java versions as you saw > >> >>> >> 2. Simplify by using the commons config instead of rolling our own. > >> >>> >> > >> >>> >> Each tab should now have just one config file, the idea being that > >> you > >> >>> >> can > >> >>> >> now share config files between people. Before each tab had at least > >> >>> >> two(maybe three) files. One was the xml config, one was a java > >> >>
Re: [chainsaw] What is necessary for a 2.2 release?
> OK. Do you think something based on Jackson would be good? It's JSON though.
We already have a dependency on genson for JSON parsing, so if we
really want to use JSON that would make the most sense. Commons
config can read/write XML; currently I just have it configured to do
properties files. I think we can write our own reader/writer as well,
but ultimately I don't think that there is anything special that we
need that commons config doesn't provide us out of the box.
-Robert Middleton
On Mon, Oct 2, 2023 at 5:14 PM Matt Sicker wrote:
>
> Jackson makes for a good library here because it also supports several data
> formats (YAML, XML, HOCON, and all sorts of others, both textual and binary)
> and is fairly extensible for hooking any custom serialization or
> deserialization logic you need. Given the desire to avoid Java serialization,
> it is perfectly reasonable to avoid XStream as that’s basically Java
> serialization using XML with all the pitfalls that entails (I dealt with this
> fairly extensively back in the Jenkins project which used an old fork of
> XStream for managing config files and state).
>
> I haven’t used Commons Configuration before, but it seems fairly appropriate
> for this sort of thing as well.
>
> > On Oct 2, 2023, at 1:43 PM, Christian Grobmeier
> > wrote:
> >
> > On Mon, Oct 2, 2023, at 16:15, Robert Middleton wrote:
> >> At least two reasons I can think of:
> >> 1. Xstream doesn’t work on all java versions as you saw
> >> 2. Simplify by using the commons config instead of rolling our own.
> >>
> >> Each tab should now have just one config file, the idea being that you can
> >> now share config files between people. Before each tab had at least
> >> two(maybe three) files. One was the xml config, one was a java serialized
> >> map. Removing the java serialization is important.
> >
> > OK. Do you think something based on Jackson would be good? It's JSON though.
> >
> > From an example:
> >
> > ObjectMapper objectMapper = new ObjectMapper();
> > Car car = new Car("yellow", "renault");
> > objectMapper.writeValue(new File("target/car.json"), car);
> >
> > We could wrap this in some kind of class and make it accessible per "tab"
> > (or whatever).
> >
> >
> >>
> >> -Robert Middleton
> >>
> >> On Mon, Oct 2, 2023 at 6:12 AM Christian Grobmeier
> >> wrote:
> >>
> >>>
> >>> On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote:
> >>>> Some(most?) of the settings should be saved:
> >>>>
> >>> https://github.com/apache/logging-chainsaw/blob/5ccb3c8e55dffd4361c549c3bcdac3f3675f79e5/src/main/java/org/apache/log4j/chainsaw/prefs/SettingsManager.java#L191
> >>>>
> >>>> The stuff that is commented out should just be the old saving code that
> >>>> used XStream to save the data out.
> >>>
> >>> You made it using this commit (thank you, its easy to track):
> >>>
> >>> https://github.com/apache/logging-chainsaw/commit/75bedf98665188eef4d13e4bfbb4b0dae456f65e
> >>>
> >>> One question: why did we remove Xstream? it seem there was an update late
> >>> 2022 to address some security.
> >>> Should we just re-enable it or was there other reasons too?
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> -Robert Middleton
> >>>>
> >>>> On Sun, Oct 1, 2023 at 3:39 PM Christian Grobmeier >>>>
> >>>> wrote:
> >>>>
> >>>>>
> >>>>> On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote:
> >>>>>> The ability to route events to tabs is a core feature in the code -
> >>>>>> that's how Chainsaw log messages end up in a Chainsaw-specific tab -
> >>>>>> but the ability to control that routing via a 'routing expression' was
> >>>>>> nuked from app-wide preferences - another thing we should bring back.
> >>>>>>
> >>>>>> It looks like we lost a lot of prefs, both panel-level and app-wide
> >>>>> prefs.
> >>>>>
> >>>>> Yes, I think all prefs are somehow gone. At least everything that is
> >>>>> writes to a file seems to be commented.
> >>>>> I didn't remove those things yet, as they seemed to big and I didn't
> >>>>> understand well how they'd work or how I would test (I lack the
> >>>
Re: [chainsaw] What is necessary for a 2.2 release?
At least two reasons I can think of: 1. Xstream doesn’t work on all java versions as you saw 2. Simplify by using the commons config instead of rolling our own. Each tab should now have just one config file, the idea being that you can now share config files between people. Before each tab had at least two(maybe three) files. One was the xml config, one was a java serialized map. Removing the java serialization is important. -Robert Middleton On Mon, Oct 2, 2023 at 6:12 AM Christian Grobmeier wrote: > > On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote: > > Some(most?) of the settings should be saved: > > > https://github.com/apache/logging-chainsaw/blob/5ccb3c8e55dffd4361c549c3bcdac3f3675f79e5/src/main/java/org/apache/log4j/chainsaw/prefs/SettingsManager.java#L191 > > > > The stuff that is commented out should just be the old saving code that > > used XStream to save the data out. > > You made it using this commit (thank you, its easy to track): > > https://github.com/apache/logging-chainsaw/commit/75bedf98665188eef4d13e4bfbb4b0dae456f65e > > One question: why did we remove Xstream? it seem there was an update late > 2022 to address some security. > Should we just re-enable it or was there other reasons too? > > > > > > > > -Robert Middleton > > > > On Sun, Oct 1, 2023 at 3:39 PM Christian Grobmeier > > > wrote: > > > >> > >> On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote: > >> > The ability to route events to tabs is a core feature in the code - > >> > that's how Chainsaw log messages end up in a Chainsaw-specific tab - > >> > but the ability to control that routing via a 'routing expression' was > >> > nuked from app-wide preferences - another thing we should bring back. > >> > > >> > It looks like we lost a lot of prefs, both panel-level and app-wide > >> prefs. > >> > >> Yes, I think all prefs are somehow gone. At least everything that is > >> writes to a file seems to be commented. > >> I didn't remove those things yet, as they seemed to big and I didn't > >> understand well how they'd work or how I would test (I lack the > knowledge > >> of how the UI should operate but only see what is there now) > >> > >> > >> > > >> > Scott > >> > > >> > On 10/1/23, Robert Middleton wrote: > >> >> I would say the saving/loading of settings is probably the main > thing to > >> >> fix - if I remember correctly, it kinda works at the moment. Part of > >> the > >> >> issue with what it did before was that the settings were scattered > among > >> >> several different files with no apparent rhyme or reason, and > converting > >> >> them to one file I'm not sure if everything works. > >> >> > >> >> The one feature that I'm pretty sure doesn't exist is the ability to > >> have > >> >> multiple log messages go to one tab, but I don't think that is > critical > >> for > >> >> release. In order to properly support that I think requires a bit > more > >> >> planning on both the UI side(so you can know how things are routed) > and > >> on > >> >> the back-end side(to do the actual routing). > >> >> > >> >> -Robert Middleton > >> >> > >> >> On Sun, Oct 1, 2023 at 3:14 PM Christian Grobmeier < > >> grobme...@apache.org> > >> >> wrote: > >> >> > >> >>> On Sun, Oct 1, 2023, at 20:59, Scott Deboy wrote: > >> >>> > It's great to see the contribution, thanks Christian! > >> >>> > > >> >>> > I pulled down latest master and it looks like there are some UI > >> >>> > glitches we should fix - for example, resizing the logger tree > pane > >> >>> > doesn't render correctly. > >> >>> > > >> >>> > As I mentioned before, I assume there are a bunch of features we > lost > >> >>> > when we moved from log4j1 - some may not be critical, but I think > >> >>> > persisting 'default' tab settings is pretty important if it's not > >> >>> > > >> >>> > I'd like us to at least support the log4j2 zeroconf functionality > as > >> >>> > well as VFSLogFilePatternReceiver. > >> >>> > > >> >>> > I'm happy to dig in - will look at latest master and contribute. > >> &
Re: [chainsaw] What is necessary for a 2.2 release?
Some(most?) of the settings should be saved: https://github.com/apache/logging-chainsaw/blob/5ccb3c8e55dffd4361c549c3bcdac3f3675f79e5/src/main/java/org/apache/log4j/chainsaw/prefs/SettingsManager.java#L191 The stuff that is commented out should just be the old saving code that used XStream to save the data out. -Robert Middleton On Sun, Oct 1, 2023 at 3:39 PM Christian Grobmeier wrote: > > On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote: > > The ability to route events to tabs is a core feature in the code - > > that's how Chainsaw log messages end up in a Chainsaw-specific tab - > > but the ability to control that routing via a 'routing expression' was > > nuked from app-wide preferences - another thing we should bring back. > > > > It looks like we lost a lot of prefs, both panel-level and app-wide > prefs. > > Yes, I think all prefs are somehow gone. At least everything that is > writes to a file seems to be commented. > I didn't remove those things yet, as they seemed to big and I didn't > understand well how they'd work or how I would test (I lack the knowledge > of how the UI should operate but only see what is there now) > > > > > > Scott > > > > On 10/1/23, Robert Middleton wrote: > >> I would say the saving/loading of settings is probably the main thing to > >> fix - if I remember correctly, it kinda works at the moment. Part of > the > >> issue with what it did before was that the settings were scattered among > >> several different files with no apparent rhyme or reason, and converting > >> them to one file I'm not sure if everything works. > >> > >> The one feature that I'm pretty sure doesn't exist is the ability to > have > >> multiple log messages go to one tab, but I don't think that is critical > for > >> release. In order to properly support that I think requires a bit more > >> planning on both the UI side(so you can know how things are routed) and > on > >> the back-end side(to do the actual routing). > >> > >> -Robert Middleton > >> > >> On Sun, Oct 1, 2023 at 3:14 PM Christian Grobmeier < > grobme...@apache.org> > >> wrote: > >> > >>> On Sun, Oct 1, 2023, at 20:59, Scott Deboy wrote: > >>> > It's great to see the contribution, thanks Christian! > >>> > > >>> > I pulled down latest master and it looks like there are some UI > >>> > glitches we should fix - for example, resizing the logger tree pane > >>> > doesn't render correctly. > >>> > > >>> > As I mentioned before, I assume there are a bunch of features we lost > >>> > when we moved from log4j1 - some may not be critical, but I think > >>> > persisting 'default' tab settings is pretty important if it's not > >>> > > >>> > I'd like us to at least support the log4j2 zeroconf functionality as > >>> > well as VFSLogFilePatternReceiver. > >>> > > >>> > I'm happy to dig in - will look at latest master and contribute. > >>> > >>> I would be more than glad if you could take some kind of a lead here. > My > >>> Swing-foo is long time gone and so far I just tried to clean a few > things > >>> or make the code more comprehensible. > >>> > >>> I will keep trying to extracting things, making classes a bit smaller > if > >>> possible. I will closely follow what you are doing and try to learn > from > >>> it. > >>> > >>> Maybe, once we can persist tab settings and then release it, no matter > >>> how > >>> the rest of the cleanup is. > >>> > >>> > >>> > > >>> > Scott > >>> > > >>> > On 10/1/23, Christian Grobmeier wrote: > >>> >> Hello, > >>> >> > >>> >> I am moving things around a lot. There is much refactoring that is > >>> necessary > >>> >> alone LogPanel had ~4500 lines of code. I believe this lot of LOCs > is > >>> >> so > >>> >> complicated to understand that it prevents people from contributing > - > >>> let > >>> >> alone Swing, but we can't change that. > >>> >> > >>> >> Apart from usual refactorings, I wonder what should be the goal of > >>> >> 2.2? > >>> >> > >>> >> I have already upgraded some dependencies that have security flaws. > 2 > >>> more > >>> >> are in the pom, but they have no patched versions so far. > >>> >> > >>> >> Should we add at least one feature? Is there maybe one already in > that > >>> >> I > >>> >> missed? > >>> >> > >>> >> I would appreciate it if one of the more experienced Swing-devs here > >>> could > >>> >> advise or maybe contribute some code so we can justify a release. > >>> >> > >>> >> The next question would be: > >>> >> How is chainsaw released at all? > >>> >> > >>> >> Kind regards, > >>> >> Christian > >>> >> > >>> > >> >
Re: [chainsaw] What is necessary for a 2.2 release?
I would say the saving/loading of settings is probably the main thing to fix - if I remember correctly, it kinda works at the moment. Part of the issue with what it did before was that the settings were scattered among several different files with no apparent rhyme or reason, and converting them to one file I'm not sure if everything works. The one feature that I'm pretty sure doesn't exist is the ability to have multiple log messages go to one tab, but I don't think that is critical for release. In order to properly support that I think requires a bit more planning on both the UI side(so you can know how things are routed) and on the back-end side(to do the actual routing). -Robert Middleton On Sun, Oct 1, 2023 at 3:14 PM Christian Grobmeier wrote: > On Sun, Oct 1, 2023, at 20:59, Scott Deboy wrote: > > It's great to see the contribution, thanks Christian! > > > > I pulled down latest master and it looks like there are some UI > > glitches we should fix - for example, resizing the logger tree pane > > doesn't render correctly. > > > > As I mentioned before, I assume there are a bunch of features we lost > > when we moved from log4j1 - some may not be critical, but I think > > persisting 'default' tab settings is pretty important if it's not > > > > I'd like us to at least support the log4j2 zeroconf functionality as > > well as VFSLogFilePatternReceiver. > > > > I'm happy to dig in - will look at latest master and contribute. > > I would be more than glad if you could take some kind of a lead here. My > Swing-foo is long time gone and so far I just tried to clean a few things > or make the code more comprehensible. > > I will keep trying to extracting things, making classes a bit smaller if > possible. I will closely follow what you are doing and try to learn from it. > > Maybe, once we can persist tab settings and then release it, no matter how > the rest of the cleanup is. > > > > > > Scott > > > > On 10/1/23, Christian Grobmeier wrote: > >> Hello, > >> > >> I am moving things around a lot. There is much refactoring that is > necessary > >> alone LogPanel had ~4500 lines of code. I believe this lot of LOCs is so > >> complicated to understand that it prevents people from contributing - > let > >> alone Swing, but we can't change that. > >> > >> Apart from usual refactorings, I wonder what should be the goal of 2.2? > >> > >> I have already upgraded some dependencies that have security flaws. 2 > more > >> are in the pom, but they have no patched versions so far. > >> > >> Should we add at least one feature? Is there maybe one already in that I > >> missed? > >> > >> I would appreciate it if one of the more experienced Swing-devs here > could > >> advise or maybe contribute some code so we can justify a release. > >> > >> The next question would be: > >> How is chainsaw released at all? > >> > >> Kind regards, > >> Christian > >> >
Re: [chainsaw] Lots of commented code // Backwards compatibility?
Yes, it was mostly to get rid of the log4j1 dependency and to get rid of/update other dependencies. There are a number of parts of chainsaw that depend on log4j1 features which may or may not be relevant. Most of the UI functionality should still exist, as far as I am aware. I think some of the receivers are commented out because they depend on very old versions of libraries, so it was easier to comment them out for the time being rather than try to update them to newer dependencies. -Robert Middleton On Fri, Sep 29, 2023 at 6:14 PM Scott Deboy wrote: > I think Robert commented out most of that to get rid of the log4j1 > dependency. I'm slightly concerned we'll lose a ton of UI > functionality in that process, but it's in history if it's still > needed, so delete away if you'd like. > > For comparison, you can look at the 'chainsaw-with-log4j1-dep' branch. > > Scott > > On 9/29/23, Christian Grobmeier wrote: > > Hi, > > > > Looking through the code base, I saw lots of code that is commented. Some > > classes (maybe because of this) are not even used anymore. I only saw one > > class (ChainsawViewer), which might make sense to keep. > > > > Is it OK to remove this all? Or is there a specific reason for this? > > > > Some methods are no longer used or empty despite not being commented. I > > would also like to remove them when they don't have any purpose. Since > they > > are public, BC is no longer guaranteed. For a Standalone app like this, I > > don't consider this a problem, but I would like to know if there are any > > objections. > > > > Kind regards, > > Christian > > > > >
Re: [chainsaw] Trouble starting it at all
It starts up for me with Netbeans and OpenJDK 11. I would expect an exception/stack trace to be printed to stderr if an exception was thrown that caused it to fail to load. -Robert Middleton On Fri, Sep 29, 2023 at 9:17 AM Christian Grobmeier wrote: > Hi, > > I have found out Chainsaw requires Java 11. I used this from IntelliJ and > run LogUI. > However, even when there is no error message, the Splash Screen never > disappears. > Is there any specific verion of Java I need? > > These are he last lines i see: > > 15:15:29.580 [AWT-EventQueue-0] DEBUG > org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map > org.apache.log4j.chainsaw.LogUI > 15:15:29.580 [AWT-EventQueue-0] DEBUG > org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map > org.apache.log4j.chainsaw.LogPanelLoggerTreeModel > 15:15:29.581 [AWT-EventQueue-0] DEBUG > org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map > org.apache.log4j.chainsaw.LoggerNameTreePanel > > Then no further actitivty, > > Any ideas? > > -- > The Apache Software Foundation > V.P., Data Privacy >
Re: `chainsaw` vs `logging-chainsaw`
logging-chainsaw is not archived and contains the most up-to-date code. The old 'chainsaw' repository has been archived. -Robert Middleton On Tue, Sep 26, 2023 at 5:57 PM Rob Tompkins wrote: > Maybe we should un-archive it and run with it in a new direction? > > -Rob > > > On Sep 26, 2023, at 4:43 PM, Christian Grobmeier > wrote: > > > > Hi, > > > > Infra archived this repo for us: > > https://github.com/apache/chainsaw > > > > Kind regards, > > Christian > > > > On Fri, Sep 22, 2023, at 22:33, Gary Gregory wrote: > >> On Fri, Sep 22, 2023 at 2:28 PM Christian Grobmeier > >> wrote: > >>> > >>> > >>> > >>> On Fri, Sep 22, 2023, at 20:16, Gary Gregory wrote: > >>>> An svn mirror should be useless. Would you please do a sanity check? > Is the > >>>> last commit from repo in our git repo? > >>> > >>> Yes, the Git repo: Updated on Jul 19, 2023 1,134 commits > >>> SVN: Updated on Jul 8, 2022, 934 commits > >> > >> TY for checking Christian. > >> > >> Gary > >> > >>> > >>>> > >>>> TY, > >>>> Gary > >>>> > >>>> On Fri, Sep 22, 2023, 1:50 PM Christian Grobmeier > wrote: > >>>> > >>>>> > >>>>> On Thu, Sep 21, 2023, at 21:53, Robert Middleton wrote: > >>>>>> I think #1 is a mirror of SVN( > >>>>>> https://svn.apache.org/repos/asf/logging/chainsaw/trunk/), while > #2 is a > >>>>>> mirror of the gitbox repository. > >>>>> > >>>>> Looks like the SVN mirror is outdated. Can we safely remove it? > >>>>> If there are no objections, I will create a ticket with infra > >>>>> > >>>>> Christian > >>>>> > >>>>>> -Robert > >>>>>> > >>>>>> On Thu, Sep 21, 2023 at 1:59 PM Volkan Yazıcı > wrote: > >>>>>> > >>>>>>> Does anybody know the difference between these two > repositories[1][2] > >>>>>>> and why the mirroring does not work? [1] hasn't been updated since > >>>>>>> 2014. > >>>>>>> > >>>>>>> [1] https://github.com/apache/chainsaw > >>>>>>> [2] https://github.com/apache/logging-chainsaw > >>>>>>> > >>>>> > >
Re: [Chainsaw] Thoughts on moving forward
I do know that there are a bunch of settings to hide things that aren't useful, I'm just saying that even hiding things I still don't find it super useful. The table view that exists is theoretically useful, but I find that it likes to cut off information because it is, well, a table. The VfsLogFilePatternReceiver I have never gotten to work properly. I think it's good and needed, but it definitely needs a user-friendly way of selecting a log file and viewing a live example of how it will parse the log file. Although for my purposes, we don't actually write to a log file, so it's a bit of a moot point. The next question of course is what do I feel would be better? I spent some time working on that tonight as a proof of concept, and here's what I came up with(with chainsaw in the background for reference): [image: Screenshot from 2023-09-25 22-12-07.png] Note: this picture is from my VM, so it's definitely squashed since it was running at a weird resolution so I could take the screenshot. But this shows a good point: in this screenshot, only about 60% of the UI is actually used to view logs. From the top there's the GNOME title bar, title bar, file menu bar, toolbar, tabs, search bar, column headers, and then we finally get to what chainsaw is supposed to do - display logs. What I've done is intentionally a proof of concept at the moment, but it provides a much simpler view. Think of it like viewing logs on the terminal, but adding in the capability to do more advanced operations(e.g. what chainsaw does with the right-click context menu). The GUI is at the moment just a JTextPane instead of a table, so that fields do not get cut off(like they currently do in the table) and it can better scroll like a real terminal when new messages come in. Right-clicking will open up a pop-up menu contextually depending on what it is you have clicked on(the time, logger name, level, or the message). Anyway, that's what I personally feel would be more useful, but I would love to hear some other ideas. -Robert Middleton On Sat, Sep 23, 2023 at 11:35 PM Scott Deboy wrote: > Please review the various display setting controls. Most of what you > mention can be toggled from visible to hidden. > > VfsLogFilePatternReceiver does exactly what you're describing. Allowing > live remote tailing of logs over an ssh accessible path. > > You control if these logs end up in separate tabs or the same tab via the > routing expression in preferences. > > We should slack sometime so I can go over the main features and what was > nuked in the log4j1 removal path and what of those are worth restoring. > > Scott > > On Sat, Sep 23, 2023, 6:08 PM Robert Middleton > wrote: > > > Since Scott has said that he would help with maintenance and Rob T has > also > > indicated that he would perhaps help, this is my view of the current > status > > of Chainsaw and what I feel its current deficiencies are. > > > > Current status: Master builds and mostly works. The last thing that I > had > > been working on was updating the config files in order to remove xstream > > and better standardize on using commons configuration. I think some of > the > > configuration settings don't save/load correctly, but some do. All of > > log4j1 has been removed. Certain features have been removed too that > were > > largely dependent on log4j1. > > > > What I feel would be useful for Chainsaw: For me, I do a lot of embedded > > work. Most of the log files that we have at my current job just go to > > syslog on our device(syslog is provided by busybox). So viewing logs is > a > > matter of SSHing into the system and just reading from the buffer. > Having > > a utility running on a separate computer that lets me see the > > logs(especially if it can connect automatically to a device) could be > very > > useful. Specific potential use-case: at my last job, I wrote a quick log > > viewing utility that would correlate log messages between two separate > > devices. This was needed because one device was embedded that logged out > > the serial port, the other was Linux and would log over the network, but > > neither had reliable time. > > > > Current limitations that I find with Chainsaw: The current GUI is not > very > > useful. A large portion of the screen is taken up by toolbars/context > > information that I generally don't find useful. I think most of the > > features that are in the GUI are very useful(for example, being able to > > trace messages and add matches) but is limited by the fact that I only > see > > a small portion of the context at a time. In my mind, an ideal solution > > would be to get rid of the toolbars as much as possible and to focus more > > on the log message
[Chainsaw] Thoughts on moving forward
Since Scott has said that he would help with maintenance and Rob T has also indicated that he would perhaps help, this is my view of the current status of Chainsaw and what I feel its current deficiencies are. Current status: Master builds and mostly works. The last thing that I had been working on was updating the config files in order to remove xstream and better standardize on using commons configuration. I think some of the configuration settings don't save/load correctly, but some do. All of log4j1 has been removed. Certain features have been removed too that were largely dependent on log4j1. What I feel would be useful for Chainsaw: For me, I do a lot of embedded work. Most of the log files that we have at my current job just go to syslog on our device(syslog is provided by busybox). So viewing logs is a matter of SSHing into the system and just reading from the buffer. Having a utility running on a separate computer that lets me see the logs(especially if it can connect automatically to a device) could be very useful. Specific potential use-case: at my last job, I wrote a quick log viewing utility that would correlate log messages between two separate devices. This was needed because one device was embedded that logged out the serial port, the other was Linux and would log over the network, but neither had reliable time. Current limitations that I find with Chainsaw: The current GUI is not very useful. A large portion of the screen is taken up by toolbars/context information that I generally don't find useful. I think most of the features that are in the GUI are very useful(for example, being able to trace messages and add matches) but is limited by the fact that I only see a small portion of the context at a time. In my mind, an ideal solution would be to get rid of the toolbars as much as possible and to focus more on the log messages like you would see in a terminal, but still having the capability to right-click on a message/message components and investigate individual messages or flag them appropriately. Perhaps the best way to organize this would be to have a logical split in the code: the backend(which receives and routes log messages) and the front-end portion. The front-end could be something like Swing for a GUI, or some sort of command-line interface like ncurses. Thoughts? What is something that people want to see/think could be useful/would want to try and code up? -Robert Middleton
Re: [VOTE] Move Chainsaw to dormant status
I think Chainsaw /can/ be useful, but it currently is not. If people are willing to work on it a bit more, I can help out a bit. I can see it potentially being useful for the type of work that I do(embedded work) but it needs a fair amount of attention in order to get to the useful level IMO. I have spent a fair amount of time getting it into a state where it will run with newer JVMs and removing the old dependencies and re-architecting the backend to be more generic and allow for inputs from all types of sources. I think the basic architecture is sound at this point, but I think the GUI is much too busy to make it useful. I have been thinking about how it could be re-done though, I do have some ideas that I can put in a new thread. Latest staging site for reference: https://logging.staged.apache.org/chainsaw/2.2.0/ -Robert Middleton On Fri, Sep 22, 2023 at 10:30 AM Scott Deboy wrote: > -1 > > While changes may be infrequent, the project is still useful and works > well. I'll continue to contribute to maintenance. > > Scott > > On Thu, Sep 21, 2023, 10:00 AM Volkan Yazıcı wrote: > > > As earlier discussions[1] indicate, Chainsaw has been lacking on > > maintenance and no PMC member stepped up to perform necessary chores. > > This is a vote to retire the Chainsaw by means of > > > > - Move it to the list of dormant projects[2] > > - Making it clear in its README and website that the project is not > > maintained anymore > > - Archive its repository[3] > > > > Please cast your votes on this mailing list. > > > > [ ] +1, retire the project > > [ ] -1, don't retire, because... > > > > This vote is open for 72 hours and will pass unless getting a net > > negative vote count. All votes are welcome and we encourage everyone, > > but only the Logging Services PMC votes are officially counted. At > > least 3 +1 votes and more positive than negative votes are required. > > > > [1] https://lists.apache.org/thread/fsykp5hxr9z0c2h85snnhnj2pq553t6q > > [2] https://logging.apache.org/dormant.html > > [3] https://github.com/apache/chainsaw > > >
Re: `chainsaw` vs `logging-chainsaw`
I think #1 is a mirror of SVN( https://svn.apache.org/repos/asf/logging/chainsaw/trunk/), while #2 is a mirror of the gitbox repository. -Robert On Thu, Sep 21, 2023 at 1:59 PM Volkan Yazıcı wrote: > Does anybody know the difference between these two repositories[1][2] > and why the mirroring does not work? [1] hasn't been updated since > 2014. > > [1] https://github.com/apache/chainsaw > [2] https://github.com/apache/logging-chainsaw >
Re: Retire Chainsaw
The website should simply be moved to the 'dormant projects' section of the logging website: https://logging.apache.org/dormant.html I am +1 on archiving. The current state of master is 'mostly working' at this point, I have spent some time in the past few years trying to get it to be in a reasonable state but I haven't yet found a need where chainsaw is a good fit. I think there are some good ideas in there that can be fleshed out more, but it has been largely dormant for several years at this point. -Robert Middleton On Tue, Sep 19, 2023 at 2:52 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > > Scott, could you (or anybody else) spare time to perform the following > > maintenance tasks? > > I don't use chainsaw personally, however, I am afraid I might run into > a project that does, so I would prefer to keep docs afloat. > > Volkan, > Does the deal qualify for log4j 1.x? > I would love to resolve issues like 1..6 for log4j 1.x: adding GitHub > Actions CI, fixing stale pom references, documenting release steps, > and so on. > > Vladimir >
Re: Remove Noise: using commits@?
They already go to the notifications list, is that not sufficient? I’m pretty sure that’s how all of the jira notifications are setup. -Robert Middleton On Wed, Aug 23, 2023 at 4:15 PM Christian Grobmeier wrote: > Should Github notifications go to a separate list? I know there will be > changes regarding threading for these kind of notifications, but maybe we > should just use comm...@logging.apache.org for Github stuff? > >
Re: What do we want to accomplish over the next couple years?
I haven't done Java much lately, but one thing that would be nice would be some good documentation/examples on how and when to use the different artifacts/dependencies for Log4j. I have never used a BOM with Maven before, so I'm not sure how I would use it or why I would. I suspect that people who are coming into this for the first time have similar problems getting started, since there are a large number of ways to set it up. -Robert Middleton On Fri, Jul 7, 2023 at 4:05 PM Ralph Goers wrote: > > Funny you should ask. > > At the moment I am working on a more generalized version of > MutableThreadContextMapFilter. I envision a Filter that will be able to > reconfigure itself dynamically by querying a service. We have implemented > such as service at my employer but I would like to include it with the > component. Thus I plan on creating a separate logging-log4j-debug repo for > this. My hope is that this will also be able to dynamically update Logger > levels, so this should provide a universal way to update sets of servers. So > I am not sure if the repo name is accurate for what I actually want to > accomplish. > > Piotr seems to have being able to move log4j-async to its own module in his > focus. That is something I would definitely like to see as hopefully it can > simplify core. I would target this at 3.x only though. > > I also think adding better monitoring support would be useful. Any > integration that we can do with open-tracing/open-telemetry would be very > important as well as making sure we integrate well with Datadog/New > Relic/Dynatrace, etc. > > We really need to do something with the Jira backlog. I would bet at least > 50% should be closed but it takes time to look at each one to determine if it > is still valid or not. Anything that is valid should actually get worked on > or closed as won’t do if we never plan to work on it. > > Separating the API into its own web site should be a high priority IMO. In > fact, I am wondering if we really needed a 3.0 for the API. > > I definitely want to improve Log4j-Audit to make it more usable. It is a bit > complicated and the UI needs to be completely redone. > > Personally, I want to spend more time on my blog. I haven’t written anything > in a few years. I really want to push the work Piotr did on the transformer. > I have started integrating that into a few of my services at work and so far > it is completely transparent. I haven’t done any real world benchmarks with > it though and I’d like to do that. > > This list is just my immediate reaction to your question. I am quite sure > there are just as many things I have forgotten about as what is listed above. > > Ralph > > > > > On Jul 7, 2023, at 11:07 AM, Matt Sicker wrote: > > > > Now that we have Log4j 3’s first alpha release out along with some nifty > > release tooling, I’d like to discuss the near future of the project. I’ll > > have time to work on some of this at my day job, but that requires some > > future planning first. Besides the DI system changes that I’m still working > > on, what else did we want to finish up in the alpha releases? I know > > there’s still more module splitting that could possibly be done. > > > > What are some things that you’d like to do? And things you’d like to see > > get done but can’t necessarily do yourself? Or things you’d like to > > collaborate on? >
CVE-2023-31038: Apache Log4cxx: SQL injection when using ODBC appender
Severity: 6.8 Affected versions: - Apache Log4cxx 0.9.0 before 1.1.0 Description: SQL injection in Log4cxx when using the ODBC appender to send log messages to a database. No fields sent to the database were properly escaped for SQL injection. This has been the case since at least version 0.9.0(released 2003-08-06) Note that Log4cxx is a C++ framework, so only C++ applications are affected. Before version 1.1.0, the ODBC appender was automatically part of Log4cxx if the library was found when compiling the library. As of version 1.1.0, this must be both explicitly enabled in order to be compiled in. Three preconditions must be met for this vulnerability to be possible: 1. Log4cxx compiled with ODBC support(before version 1.1.0, this was auto-detected at compile time) 2. ODBCAppender enabled for logging messages to, generally done via a config file 3. User input is logged at some point. If your application does not have user input, it is unlikely to be affected. Users are recommended to upgrade to version 1.1.0 which properly binds the parameters to the SQL statement, or migrate to the new DBAppender class which supports an ODBC connection in addition to other databases. Note that this fix does require a configuration file update, as the old configuration files will not configure properly. An example is shown below, and more information may be found in the Log4cxx documentation on the ODBCAppender. Example of old configuration snippet: ... other params here ... The migrated configuration snippet with new ColumnMapping parameters: ... other params here ... Required Configurations: Log4cxx must be built with ODBC support, and configured to log messages to a database for this to occur References: https://logging.apache.org/ https://www.cve.org/CVERecord?id=CVE-2023-31038
Re: [VOTE] Release log4cxx 1.1.0-RC2
Adding my +1. With that, the vote officially passes with the +3 votes from me, Piotr, and Volkan, with Thorsten and Steven adding their +1 as well. I will proceed with the release. -Robert Middleton On Fri, May 5, 2023 at 2:04 PM Piotr P. Karwasz wrote: > > Hi Robert, > > On Thu, 4 May 2023 at 15:57, Thorsten Schöning wrote: > > > > Guten Tag Robert Middleton, > > am Mittwoch, 3. Mai 2023 um 12:38 schrieben Sie: > > > > > Please download, test, and cast your votes on the log4j developers list. > > > [] +1, release the artifacts > > > [] -1, don't release because... > > I successfully compiled and ran tests with GCC 10.2.1 on Debian. > Hashes and signatures also match. > > +1 > > Piotr
[VOTE] Release log4cxx 1.1.0-RC2
This is a vote to release log4cxx 1.1.0-RC2. The old vote is canceled. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... This 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. A quick changelog is below: * Fix to build on Windows Server 2016 * Fix compiling errors with older compilers * Make ODBC and SMTP opt-in instead of automatic * Parameterize statements for ODBC inserts. Add new generic DBAppender class that uses APR for database support * Fix Qt support Tag: For a new copy do "git clone https://github.com/apache/logging-log4cxx.git; and then "git checkout tags/v1.1.0-RC2" For an existing working copy, do "git pull" and then "git checkout tags/v1.1.0-RC2" Web site: https://logging.staged.apache.org/log4cxx/next_stable/ Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4cxx/ Building directions are on the website(under 'Development'). Note that APR is required to build(as well as boost if your compiler does not support C++17). -Robert Middleton
[VOTE] Release log4cxx 1.1.0
This is a vote to release log4cxx 1.1.0 Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... This 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. A quick changelog is below: * Fix to build on Windows Server 2016 * Fix compiling errors with older compilers * Make ODBC and SMTP opt-in instead of automatic * Parameterize statements for ODBC inserts. Add new generic DBAppender class that uses APR for database support * Fix Qt support Tag: For a new copy do "git clone https://github.com/apache/logging-log4cxx.git; and then "git checkout tags/v1.1.0-RC1" For an existing working copy, do "git pull" and then "git checkout tags/v1.1.0-RC1" Web site: https://logging.staged.apache.org/log4cxx/next_stable/ Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4cxx/ Building directions are on the website(under 'Development'). Note that APR is required to build(as well as boost if your compiler does not support C++17). -Robert Middleton
Re: [log4cxx] Next steps / release?
The release has been formally completed at this point; mirrors have their copy of the official tar.gz file. -Robert Middleton On Fri, Jan 6, 2023 at 7:36 AM Tobias Frost wrote: > > On Mon, Jan 02, 2023 at 10:45:37PM -0500, Robert Middleton wrote: > > Awesome! Thanks for the packaging work that you do. Once we get it > > voted on you should have a proper release. > > FYI, release-team acked the transistion and we've got the go to do the > transition. So once the proper release is available, I now could upload > it to unstable for the final steps needed to complete the transition, > but I prefer to do this with the final release. > > Do you have an ETA when the release will become available? (It's still > a bit time critical…) > > -- > Cheers, > tobi > > -- > tobi > > > -Robert Middleton > > > > On Mon, Jan 2, 2023 at 2:52 PM Tobias Frost wrote: > > > > > > Update: > > > > > > FTP masters have been very quick and approved the package, so the > > > snapshot is > > > already in experimental. [1] > > > > > > I've also rebuilt all reverse depdencies successfully and asked the > > > release team > > > to approve the transition. [2] > > > > > > [1] https://packages.debian.org/source/experimental/log4cxx > > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027746 > > > > > > Cheers, > > > -- > > > tobi > > > > > > On Sat, Dec 31, 2022 at 10:52:43AM +0100, Tobias Frost wrote: > > > > On Thu, Dec 29, 2022 at 05:21:34PM -0500, Robert Middleton wrote: > > > > > > > > > The last time we talked about this Tobias Frost said that the > > > > > soft-freeze for Debian is the 12th of January[1], so after that point > > > > > an updated library wouldn't make it into Debian. I would like to get > > > > > this version into Debian if possible(as that is the distribution I > > > > > use), but that depends on Tobias' availability. > > > > > > > > To have a chance to make that happen, I've started the transistion > > > > workflow [1]. > > > > TBH, due to the soft freeze is in less than two weeks, changes are high > > > > that > > > > we won't make it, but at least I want to have tried it. > > > > > > > > The first step is "Upload your new version to experimental (and have it > > > > clear > > > > NEW)", which is what I've just have done: I've uploaded a snapshot > > > > (commit > > > > cbd23ff1) to debian experimental. This needs now to be approved by the > > > > (Debian) > > > > ftp masters, which is (usually) for such a change quick, but if they > > > > aren't or > > > > not happy for any reason, this can spoil the game. [2] > > > > > > > > Only after that, I can ask for a transition slot from the release team. > > > > If they are > > > > not happy with a transition that late (IOW that short before the > > > > freeze), well > > > > that will be something I have to accept and that will mean 1.0.0 not in > > > > bookworm. > > > > > > > > In parallel I'll see if the reverse dependencies are still building > > > > with the > > > > new version, as for any breakage I will need to have patches available… > > > > > > > > So, let's see how it works out. > > > > > > > > [1] if you want to know the details: > > > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > > > [2] It needs to go through NEW due to the binary package rename, due to > > > > the SONAME bump. > > > > > > > > -- > > > > tobi
Re: [VOTE] Release log4cxx 1.0.0
Adding my +1. With that, the release passes with 3 binding votes from me, Volkan, Remko, and two votes from Stephen and Thorsten. Thanks to all for your work; I will send out the release notification shortly. -Robert Middleton On Fri, Jan 6, 2023 at 9:07 AM Volkan Yazıcı wrote: > > +1 > > Shared website link contains a typo, correct one: > https://logging.staged.apache.org/log4cxx/next_stable/ > > On Sun, Jan 1, 2023 at 7:06 PM Robert Middleton > wrote: > > > This is a vote to release log4cxx 1.0.0 > > > > Please download, test, and cast your votes on the log4j developers list. > > [] +1, release the artifacts > > [] -1, don't release because... > > > > This 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. > > > > Changes can be found on JIRA: > > https://issues.apache.org/jira/projects/LOGCXX/versions/12351043 > > > > Tag: > > For a new copy do "git clone > > https://github.com/apache/logging-log4cxx.git; and then "git checkout > > tags/v1.0.0-RC1" > > For an existing working copy, do "git pull" and then "git checkout > > tags/v1.0.0-RC1" > > > > Web site: https://logging.staged.apache.org/log4cxx/next_stable/ > > > > Distribution archives: > > https://dist.apache.org/repos/dist/dev/logging/log4cxx/ > > > > Building directions are on the website(under 'Development'). Note > > that APR is required to build(as well as boost if your compiler does > > not support C++17). > > > > -Robert Middleton > >
Re: [log4cxx] Next steps / release?
Awesome! Thanks for the packaging work that you do. Once we get it voted on you should have a proper release. -Robert Middleton On Mon, Jan 2, 2023 at 2:52 PM Tobias Frost wrote: > > Update: > > FTP masters have been very quick and approved the package, so the snapshot is > already in experimental. [1] > > I've also rebuilt all reverse depdencies successfully and asked the release > team > to approve the transition. [2] > > [1] https://packages.debian.org/source/experimental/log4cxx > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027746 > > Cheers, > -- > tobi > > On Sat, Dec 31, 2022 at 10:52:43AM +0100, Tobias Frost wrote: > > On Thu, Dec 29, 2022 at 05:21:34PM -0500, Robert Middleton wrote: > > > > > The last time we talked about this Tobias Frost said that the > > > soft-freeze for Debian is the 12th of January[1], so after that point > > > an updated library wouldn't make it into Debian. I would like to get > > > this version into Debian if possible(as that is the distribution I > > > use), but that depends on Tobias' availability. > > > > To have a chance to make that happen, I've started the transistion workflow > > [1]. > > TBH, due to the soft freeze is in less than two weeks, changes are high that > > we won't make it, but at least I want to have tried it. > > > > The first step is "Upload your new version to experimental (and have it > > clear > > NEW)", which is what I've just have done: I've uploaded a snapshot (commit > > cbd23ff1) to debian experimental. This needs now to be approved by the > > (Debian) > > ftp masters, which is (usually) for such a change quick, but if they aren't > > or > > not happy for any reason, this can spoil the game. [2] > > > > Only after that, I can ask for a transition slot from the release team. If > > they are > > not happy with a transition that late (IOW that short before the freeze), > > well > > that will be something I have to accept and that will mean 1.0.0 not in > > bookworm. > > > > In parallel I'll see if the reverse dependencies are still building with the > > new version, as for any breakage I will need to have patches available… > > > > So, let's see how it works out. > > > > [1] if you want to know the details: > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > > [2] It needs to go through NEW due to the binary package rename, due to the > > SONAME bump. > > > > -- > > tobi
[VOTE] Release log4cxx 1.0.0
This is a vote to release log4cxx 1.0.0 Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... This 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. Changes can be found on JIRA: https://issues.apache.org/jira/projects/LOGCXX/versions/12351043 Tag: For a new copy do "git clone https://github.com/apache/logging-log4cxx.git; and then "git checkout tags/v1.0.0-RC1" For an existing working copy, do "git pull" and then "git checkout tags/v1.0.0-RC1" Web site: https://logging.staged.apache.org/log4cxx/next_stable/ Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4cxx/ Building directions are on the website(under 'Development'). Note that APR is required to build(as well as boost if your compiler does not support C++17). -Robert Middleton
Re: [log4cxx] Next steps / release?
On Sat, Dec 31, 2022 at 1:57 PM Tobias Frost wrote: > (sorry for being short worded, not having much time right now) > Please note that library versioning has nothing do do with project versioning, > don't conflate them… It is a sign of improper library versioning if the > project has the same version as the library. IOW, so name versioning do > not follow semantic versioning. > So it seems that there are like three versions to take into account here(using liblog4cxx11): 1. The user-visible version(e.g. 0.11.0) 2. The version that the SO file has(e.g. liblog4cxx.so.11.0.0) 3. The ABI version of the library(e.g. 11) As for the project version being the same version as the library, that is the case with certain libraries: robert@debian:/usr/lib/x86_64-linux-gnu$ apt-cache policy libqt5core5a libqt5core5a: Installed: 5.11.3+dfsg1-1+deb10u5 Candidate: 5.11.3+dfsg1-1+deb10u5 Version table: *** 5.11.3+dfsg1-1+deb10u5 500 500 http://deb.debian.org/debian buster/main amd64 Packages 100 /var/lib/dpkg/status 5.11.3+dfsg1-1+deb10u3 500 500 http://security.debian.org/debian-security buster/updates/main amd64 Packages robert@debian:/usr/lib/x86_64-linux-gnu$ ls -l libQt5Core* -rw-r--r-- 1 root root1256 Mar 26 2022 libQt5Core.prl lrwxrwxrwx 1 root root 20 Mar 26 2022 libQt5Core.so -> libQt5Core.so.5.11.3 lrwxrwxrwx 1 root root 20 Mar 26 2022 libQt5Core.so.5 -> libQt5Core.so.5.11.3 lrwxrwxrwx 1 root root 20 Mar 26 2022 libQt5Core.so.5.11 -> libQt5Core.so.5.11.3 -rw-r--r-- 1 root root 5208360 Mar 26 2022 libQt5Core.so.5.11.3 If I'm understanding all of this correctly, using Qt as an example there the user-visible version is 5.11.3, the SO version is 5.11.3, and the ABI version is 5(since all Qt versions are ABI stable for every minor release in their major). > I still believe that the real name needs to be liblog4cxx.15.0.0, and this > also matches my experience how it is done generally. I pretty please ask not > to deviate from that, libraries are very easily made so that they are subtly > break, and my experience shows that your are always best of by following > established > practices. > > BTW, I'm getting a (new) lintian warning [0] > W: liblog4cxx15: package-name-doesnt-match-sonames liblog4cxx15.0.0 > > readelf -a liblog4cxx.so.1.0.0.0 | grep SONAME > 0x000e (SONAME) Library soname: > [liblog4cxx.so.15.0.0] > > compare that to eg. of libpng: > readelf -a /usr/lib/x86_64-linux-gnu/libpng16.so.16.39.0 | grep SONAME > 0x000e (SONAME) Library soname: [libpng16.so.16] > > I think there is something broken, ENOTIME to investiate right now, probably > SO version* is set to 15.0.0 instead of only 15. > > * sorry for the non-exact wording… > > [0] https://lintian.debian.org/tags/package-name-doesnt-match-sonames > > > Anyway, I'm going to do the following: > > * Update the changelog for this new release > > * Make sure the ABI dump is up to date(only needed for builds on > > github, this is not in the release tarball) > > * Merge next_stable into master and delete next_stable, so that master > > becomes the new master > > * Call a release vote > > Please lets first fix the SONAME issue… This is something which has a huge > impact and having the need to have a Debian specific patch here would be > really bad. I'll make everything with the SONAME 15.0.0, since that follows what we have been doing before. That lintian error is useful; now that I know that you're getting that error, it makes sense to fix it on the upstream end instead of having you fix that on yours. -Robert Middleton
Re: [log4cxx] Next steps / release?
On Sat, Dec 31, 2022 at 4:22 AM Tobias Frost wrote: > The generated file names look strange: > > Now: > tobi@isildor:~/workspace/deb/packages/log4cxx/upstream/log4cxx/debian/tmp/usr/lib/x86_64-linux-gnu$ > ls -la liblog4cxx* > lrwxrwxrwx 1 tobi tobi 20 Dec 31 08:51 liblog4cxx.so -> > liblog4cxx.so.15.0.0 > -rw-r--r-- 1 tobi tobi 22632496 Dec 31 08:50 liblog4cxx.so.1.0.0.0 > lrwxrwxrwx 1 tobi tobi 21 Dec 31 08:51 liblog4cxx.so.15.0.0 -> > liblog4cxx.so.1.0.0.0 > > I'd expect the (actually) library be liblog4cxx.so.15.0.0 and symlinks > pointing to it: > liblog4cxx.so --> liblog4cxx.so.15 --> liblog4cxx.so.15.0.0 > (linker name) --> (soname)--> (real name) > > (References: > https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html, > https://man7.org/conf/lca2006/shared_libraries/slide5b.html and following > slides) > > before it was like this, which matches what I see on other libraries and what > I would expect: > tobi@isildor:~/workspace/deb/packages/log4cxx/log4cxx/debian/tmp/usr/lib/x86_64-linux-gnu$ > ls -la liblog4cxx* > total 22780 > lrwxrwxrwx 1 tobi tobi 16 Dec 31 08:55 liblog4cxx.so -> liblog4cxx.so.13 > lrwxrwxrwx 1 tobi tobi 20 Dec 31 08:55 liblog4cxx.so.13 -> > liblog4cxx.so.13.0.0 > -rw-r--r-- 1 tobi tobi 23308784 Dec 31 08:54 liblog4cxx.so.13.0.0 > ) > > (If you want to encode the project version into the name, it would be more > liblog4cxx-1.0.0.so, liblog4cxx-1.0.0.so.15 and sliblog4cxx-1.0.0.so.15.0.0 , > but that's breaking > the concept of soanmes alltogether, as for the linker/loader > liblog4cxx-1.0.0.so.15 and liblog4cxx-1.0.1.so.15 would > be different, unrelated libraries) FWIW my reference is mostly from this (old) thread on the KDE mailing list: https://mail.kde.org/pipermail/kde-buildsystem/2008-April/004543.html This would seem to agree with the TLDP documentation, which states: "Every shared library has a special name called the ``soname''. The soname has the prefix ``lib'', the name of the library, the phrase ``.so'', followed by a period and a version number that is incremented whenever the interface changes (as a special exception, the lowest-level C libraries don't start with ``lib''). A fully-qualified soname includes as a prefix the directory it's in; on a working system a fully-qualified soname is simply a symbolic link to the shared library's ``real name''. Every shared library also has a ``real name'', which is the filename containing the actual library code. The real name adds to the soname a period, a minor number, another period, and the release number. The last period and release number are optional. The minor number and release number support configuration control by letting you know exactly what version(s) of the library are installed. Note that these numbers might not be the same as the numbers used to describe the library in documentation, although that does make things easier." So setting the SONAME to 15.0.0 results in the liblog4cxx.so.15, with a version of 1.0.0.0(liblog4cxx.so.1.0.0.0) which would correspond to the correct log4cxx version in this case(CMake allows for major.minor.patch.tweak, but for the human-readable release I do just major.minor.patch). As far as I can tell, the important thing is that the SONAME does not always equal the version name(if we were following semantic versioning earlier it probably would be the same), but that's part of this release to get it into a state where the versions and SONAME should increment independently of each other. Anyway, I'm going to do the following: * Update the changelog for this new release * Make sure the ABI dump is up to date(only needed for builds on github, this is not in the release tarball) * Merge next_stable into master and delete next_stable, so that master becomes the new master * Call a release vote -Robert Middleton
Re: Log4Net 2.014
Kevin, I don't work on Log4net, but looking through the recent commits it looks like this may have been fixed: https://github.com/apache/logging-log4net/pull/92 I don't know if there is currently a timeline as to when this might be officially released. -Robert Middleton On Thu, Dec 29, 2022 at 5:17 PM Ralph Goers wrote: > > Rupak and Kevin, > > Please note that your emails contain a classification that these are internal > Schwab emails but that you have sent them to a public mailing list. We > obviously ignore such classifications since there is no way to make them > private once you have done that. > > I can’t comment on your specific issue as I don’t work on Log4Net so I will > leave that to those that do. > > Ralph > > > On Dec 29, 2022, at 1:24 PM, Seal, Rupak > > wrote: > > > > HI @Tools Support<mailto:toolssupp...@schwab.com> is there any ways to have > > this work being escalated as this impacted production stability and > > damaging the logging server in Production SNE environment > > > > From: Gardenhire, Kevin > > Date: Thursday, December 29, 2022 at 2:12 PM > > To: dev@logging.apache.org > > Cc: Joshi, Hemant , Vishwakarma, Amit > > , Seal, Rupak , > > Shambhumane, Meenakshi > > Subject: Log4Net 2.014 > > Hi, > > > > We recently upgraded our Log4Net package from 1.2.13 to 2.0.14 to remediate > > a security flaw found in the old package. After upgrading we have found an > > issue that is not allowing 2 instances of an application to write to the > > same file location. We have a blue/green pool deployment strategy where > > each server has an active and inactive application instance and on the > > first deployment we see that the active version logs as expected, but after > > swapping the pools the new active application is unable to log as the now > > inactive application seems to have a lock on the file. > > > > We were able to make it work with 2.0.3, but 2.0.10 is the oldest version > > that does not have the flaw. Any versions of the library without the flaw > > has this locking issue. > > > > Can you help us to raise an issue to be taken up for development in future > > releases? > > > > Thanks, > > Kevin Gardenhire > > Charles Schwab & Co. | Enterprise Middleware and Online Security > > Technology (EMOST) > > > > > > > > Classification: Schwab Internal > > > > > > Classification: Schwab Internal >
Re: [log4cxx] Next steps / release?
On Fri, Dec 30, 2022 at 11:43 AM Tobias Frost wrote: > When doing the same against the branch "next_stable", currently at [2] > the result is much much worse: > https://people.debian.org/~tobi/log4cxx/1_to_next/compat_report.html > > /me confused… (I've read your text as it should be the opposite…) > The new version should be ABI stable moving forward, but it needs to be released first. > If it is only API compatible, but not ABI compable, we'll need a SONAME bump. > I bumped the SONAME a little bit ago; you probably grabbed the code shortly before I bumped it. I think I've done it correctly, but it would be nice to have somebody double-check it. I arbitrarily bumped it to version 15, skipping 14. The version of the SO file should also now match the version of log4cxx, but that version is not the same as the SONAME. -Robert Middleton
Re: [log4cxx] Next steps / release?
On Fri, Dec 30, 2022 at 10:17 AM Tobias Frost wrote: > > On Fri, Dec 30, 2022 at 07:18:46AM +0100, Tobias Frost wrote: > > IF an SONAME bump is required, it will become more challenging, as other > > Debian teams are involved (and other maintainers if it casues breakages in > > reverse dependencies) > > I would basically needs something (it does not need to be the final > > release, just something with the target SONAME) now to kick of the process. > > Fixes > > (without SONAME bump) can still then be provided until February. > > Ok, I've compiled the new version and the version currently in Debian and > threw it at abi-compliance-checker [1]. Unfortunatly it is not happy with > 8 errors. > > I've put the report here: > https://people.debian.org/~tobi/log4cxx/1_to_2/compat_report.html > > 1 = old version, currently in debian > 2 = new version "head" of current git, master-branch. > > Level::initializeLevels ( ) should not be deleted… > > On the other erros, where registers have changed, I have no idea what's going > on… > The registers changing sounds like something in the compiler changed. But it looks like that's on master, where what we're talking about here is currently in the next_stable branch(which should have a ridiculous number of ABI failures, but it should still be source-compatible). -Robert Middleton
[log4cxx] Next steps / release?
With some fixes that have been accomplished over the past few weeks, we now have only 1-2 issues in JIRA that would need to be finished for a release, and I think both of those are effectively done at this point. I'm pretty happy with where things are at the moment - there's always more tweaking that can be done, but I can't think of anything major that needs to be done that could be done within a reasonable timeframe. The major thing that was done for the next release was to make things ABI stable, so as long as we commit to that going forward(and only breaking it with proper versioning) we should be good. The last time we talked about this Tobias Frost said that the soft-freeze for Debian is the 12th of January[1], so after that point an updated library wouldn't make it into Debian. I would like to get this version into Debian if possible(as that is the distribution I use), but that depends on Tobias' availability. With that in mind, should we do a release in the immediate future(within the next ~7 days), or should we wait a bit for some more tweaking and/or features? -Robert Middleton [1]: https://lists.apache.org/thread/zg150rbkdkzgog1bnd403052818nncs7
[log4cxx] Stacktrace support
I've been working on adding in stacktrace support to Log4cxx using
Boost stacktrace. One of my objectives with this is to make this
entirely optional, such that both Log4cxx needs to have support for
Boost stacktrace and the client code needs to enable it, so by default
a stacktrace is not collected.
In order to do this, I've somewhat simplified the logger methods, so
where it was two methods:
void forcedLog(const LevelPtr& level,
const std::string& message,
const log4cxx::spi::LocationInfo& location);
void forcedLog(const LevelPtr& level,
const std::string& message);
I've converted it into one method:
void forcedLog(const LevelPtr& level,
const std::string& message,
const log4cxx::spi::LocationInfo& location =
log4cxx::spi::LocationInfo::getLocationUnavailable(),
const log4cxx::OptionalLogParams& optionalParams =
log4cxx::OptionalLogParams()) const;
The 'optional params' here being effectively just a map that we can
throw more pointers into if we need to add more information at a later
point.
This seems like the most reasonable way to prevent a method
explosion(adding more method overloads).
I'm not sure if this is the best way to go though and was wondering if
anybody had any better ideas. There are a few options that I was
thinking of:
1. Throw the stacktrace string into the (already-existing) MDC and
letting users do something like %X{stacktrace} to print the value
2. Add more method overloads to the Logger class to take in the
stacktrace(when available) so the logging event has a copy of the
stacktrace
3. Use a map to pass optional void* pointers to the Logger, so that we
avoid an explosion of overridden methods while still keeping a copy of
the stacktrace
I'm wondering if I'm overthinking this - my original concern was to
have a copy of the stacktrace so that you could eventually do some
kind of filtering with the stacktrace data, but upon thinking about it
more I don't know when you would ever have to do that, especially
since the stacktrace is really only useful if you have a debug build.
Am I right in overthinking this? Is there something much simpler that
I'm missing?
-Robert Middleton
Re: [log4cxx] fmt compiling/linking issue
It looks like I was overcomplicating this. The constructor for a
std::chrono::time_point does take in a duration from the clock's
epoch, which is ultimately what we want to do.
PR up on github for review.
-Robert Middleton
On Sat, Nov 26, 2022 at 11:10 PM Stephen Webb wrote:
>
> Fmt seems to have a formatter for std::chrono::time_point templated by
> std::chrono::system_clock and (optionally) std::chrono::utc_clock if my
> interpretation of the fmt/chrono.h code in the https://github.com/fmtlib
> master branch is correct.
>
> Quoting from https://en.cppreference.com/w/cpp/chrono/high_resolution_clock
> >
> > It may be an alias of std::chrono::system_clock
> > <https://en.cppreference.com/w/cpp/chrono/system_clock> or
> > std::chrono::steady_clock
> > <https://en.cppreference.com/w/cpp/chrono/steady_clock>, or a third,
> > independent clock.
>
>
> On Sun, Nov 27, 2022 at 2:14 AM Robert Middleton
> wrote:
>
> > Odd. How would we format the timestamp in that case? According to
> > the documentation, fmt has formatters for std::chrono::time_point
> > already.
> >
> > Is this some sort of difference between MSVC and gcc? It should be
> > trying to format
> > std::chrono::time_point, which I
> > thought was std::chrono::system_clock instead of steady_clock.
> >
> > -Robert Middleton
> >
> >
> > On Fri, Nov 25, 2022 at 11:03 PM Stephen Webb wrote:
> > >
> > > In Visual studio 2019 the line
> > >
> > > fmt::arg("d", event->getChronoTimeStamp()),
> > >
> > >
> > > causes the compile time error:
> > >
> > > error C2338: Cannot format an argument. To make type T formattable
> > provide
> > > a formatter specialization: https://fmt.dev/latest/api.html#udt
> > >
> > >
> > > It seems to need a formatter specialization for
> > > std::chrono::steady_clock::time_point.
> > >
> > > The branch build OK with the above line commented out.
> > >
> > > On Sat, Nov 26, 2022 at 2:13 AM Robert Middleton
> > > wrote:
> > >
> > > > I've been working on LOGCXX-514(using fmt as an alternative layout to
> > > > the PatternLayout) and I've got a working implementation on Linux.
> > > > However, the Windows build currently fails with some sort of symbol or
> > > > linking error. Since I'm not all that familiar with Windows, would
> > > > somebody with more experience on the Windows side be able to take a
> > > > look at it?
> > > >
> > > > I suspect that this could also be something to do with the wchar on
> > > > Windows, but it is not clear to me if that is the case or not.
> > > >
> > > > -Robert Middleton
> > > >
> >
Re: Non-Root Logger Logging Problems
Hi Nathan,
My guess would be that additivity.sender=false should actually be
sender.additivity=false.
As to why the log messages are not going to the second FileAppender,
I'm not sure why that would be happening. I would recommend running
with internal debugging enabled. You can do this by setting
log4j.debug=true in your config file.
-Robert Middleton
On Wed, Nov 30, 2022 at 11:41 PM Eisenberg, Nathan
wrote:
>
> I have configured 2 loggers inside my java config file: 1 is the rootLogger
> and it has 2 appenders, and the other is called sender and it has 1 appender.
>
>
> My java config file looks something like this:
> rootLogger= [level], consoleAppender, fileAppender1
>
> sender=[level], fileAppender2
> additivity.sender=false
>
> consoleAppender=log4j.consoleAppender
> layout stuff...
>
> fileAppender1=log4j.RollingFileAppender
> file and layout details...
>
> fileAppender2=log4j.RollingFileAppender
> file and layout details...
>
>
> And in my c++ code I'm using it like this:
> Logger rootLogger = getLogger("root");
> LOG4CXX_INFO(rootLogger, "message");
>
> Logger senderLogger = getLogger("sender");
> LOG4CXX_INFO(senderLogger, "otherMessage");
>
>
> Although the rootAppender works perfectly fine, my problem is that the
> sender's message (otherMessage) is only showing up in the rootLogger's
> appenders (consoleAppender, fileAppender1) but NOT it's own appender
> (fileAppender2). Does anyone have any idea what I'm doing wrong?
>
>
> Nathan Eisenberg
>
Re: [log4cxx] fmt compiling/linking issue
Odd. How would we format the timestamp in that case? According to
the documentation, fmt has formatters for std::chrono::time_point
already.
Is this some sort of difference between MSVC and gcc? It should be
trying to format
std::chrono::time_point, which I
thought was std::chrono::system_clock instead of steady_clock.
-Robert Middleton
On Fri, Nov 25, 2022 at 11:03 PM Stephen Webb wrote:
>
> In Visual studio 2019 the line
>
> fmt::arg("d", event->getChronoTimeStamp()),
>
>
> causes the compile time error:
>
> error C2338: Cannot format an argument. To make type T formattable provide
> a formatter specialization: https://fmt.dev/latest/api.html#udt
>
>
> It seems to need a formatter specialization for
> std::chrono::steady_clock::time_point.
>
> The branch build OK with the above line commented out.
>
> On Sat, Nov 26, 2022 at 2:13 AM Robert Middleton
> wrote:
>
> > I've been working on LOGCXX-514(using fmt as an alternative layout to
> > the PatternLayout) and I've got a working implementation on Linux.
> > However, the Windows build currently fails with some sort of symbol or
> > linking error. Since I'm not all that familiar with Windows, would
> > somebody with more experience on the Windows side be able to take a
> > look at it?
> >
> > I suspect that this could also be something to do with the wchar on
> > Windows, but it is not clear to me if that is the case or not.
> >
> > -Robert Middleton
> >
[log4cxx] fmt compiling/linking issue
I've been working on LOGCXX-514(using fmt as an alternative layout to the PatternLayout) and I've got a working implementation on Linux. However, the Windows build currently fails with some sort of symbol or linking error. Since I'm not all that familiar with Windows, would somebody with more experience on the Windows side be able to take a look at it? I suspect that this could also be something to do with the wchar on Windows, but it is not clear to me if that is the case or not. -Robert Middleton
[log4cxx] C++ Version
The current version of next_stable fails when compiled in C++11 mode due to std::make_unique not being in that version. This is pretty easy to fix(Herb Sutter has an implementation of this for C++11 which seems to be the same as GCC's: https://herbsutter.com/gotw/_102/) I see three options here: 1. Continue to use C++11 for next_stable, reverting any make_unique calls 2. Use a custom log4cxx::make_unique function for C++11 compilers 3. Use C++14(or later) Does anybody have any thoughts on this? At this point I feel it is perfectly reasonable to do any of these options, as my general rule of thumb is to support whatever compiler the 'oldstable' version of Debian uses(so anything released in the past ~5 years). RHEL has a much longer release cycle; I believe RHEL 7(which is still supported for at least 1.5 years) would only be able to be compiled with a C++11 compiler. -Robert Middleton
Re: [log4cxx] Github windows builds
I don't think any of those are too common, so it probably doesn't make sense to do all of those combinations. The prefer_boost should be effectively covered by the new build that compiles it in C++11 mode. -Robert Middleton On Thu, Oct 27, 2022 at 10:43 PM Stephen Webb wrote: > > There are 3(logchar type) x 4(charset type) x 2(unichar?) x 2(wchar_t?) x > 2(prefer_boost?) x 2(qt_support?) =192 combinations of build options > log4cxx provides of which only one is being tested. > > What should we do with those? > > > On Fri, Oct 28, 2022 at 12:23 PM Robert Middleton > wrote: > > > Upon further investigation, it appears as though it was the cache > > functionality that broke. Updating from v2 to v3 seems to have fixed > > the problem. It looks like when you updated vcpkg to the latest > > version that fixed it for one build, probably because the yml file > > changed or something? > > > > Anyway, it's fixed now. Are there any other configurations that we > > should test for while I'm making updates? > > > > -Robert Middleton > > > > On Thu, Oct 27, 2022 at 1:37 AM Stephen Webb wrote: > > > > > > It works using a more recent version of vcpkg - not sure what the issue > > > with the old version is. > > > > > > On Thu, Oct 27, 2022 at 1:41 PM Robert Middleton > > > wrote: > > > > > > > I've been adding some more builds for log4cxx(to test more > > > > combinations of features and stuff) but I seem to have broken the > > > > windows build - cmake can't find APR with the .pc file. It seems that > > > > whatever we had before cached had the .pc files in it, but trying to > > > > rebuild clean(no cache) does not have .pc files in it to find the > > > > library. > > > > > > > > I'm thinking that this may have had something to do with the recent > > > > changes to how we find APR, but I'm not much of a Windows guy so it > > > > could take me a while to figure out what exactly is broken. I know > > > > that Steven Webb uses vcpkg, would you be able to take a look at it > > > > and figure out why it might be failing? > > > > > > > > The branch in question: > > > > https://github.com/apache/logging-log4cxx/tree/LOGCXX-562 > > > > > > > > -Robert Middleton > > > > > >
Re: [log4cxx] Github windows builds
Upon further investigation, it appears as though it was the cache functionality that broke. Updating from v2 to v3 seems to have fixed the problem. It looks like when you updated vcpkg to the latest version that fixed it for one build, probably because the yml file changed or something? Anyway, it's fixed now. Are there any other configurations that we should test for while I'm making updates? -Robert Middleton On Thu, Oct 27, 2022 at 1:37 AM Stephen Webb wrote: > > It works using a more recent version of vcpkg - not sure what the issue > with the old version is. > > On Thu, Oct 27, 2022 at 1:41 PM Robert Middleton > wrote: > > > I've been adding some more builds for log4cxx(to test more > > combinations of features and stuff) but I seem to have broken the > > windows build - cmake can't find APR with the .pc file. It seems that > > whatever we had before cached had the .pc files in it, but trying to > > rebuild clean(no cache) does not have .pc files in it to find the > > library. > > > > I'm thinking that this may have had something to do with the recent > > changes to how we find APR, but I'm not much of a Windows guy so it > > could take me a while to figure out what exactly is broken. I know > > that Steven Webb uses vcpkg, would you be able to take a look at it > > and figure out why it might be failing? > > > > The branch in question: > > https://github.com/apache/logging-log4cxx/tree/LOGCXX-562 > > > > -Robert Middleton > >
[log4cxx] Github windows builds
I've been adding some more builds for log4cxx(to test more combinations of features and stuff) but I seem to have broken the windows build - cmake can't find APR with the .pc file. It seems that whatever we had before cached had the .pc files in it, but trying to rebuild clean(no cache) does not have .pc files in it to find the library. I'm thinking that this may have had something to do with the recent changes to how we find APR, but I'm not much of a Windows guy so it could take me a while to figure out what exactly is broken. I know that Steven Webb uses vcpkg, would you be able to take a look at it and figure out why it might be failing? The branch in question: https://github.com/apache/logging-log4cxx/tree/LOGCXX-562 -Robert Middleton
Re: [ANNOUNCE] Changes to Jira Account Creation (issues.a.o/jira)
I'm somewhat annoyed that the spam in jira is not able to be automatically filtered out. The mailing lists don't seem to have an issue with spam. Jira is definitely more powerful(and better in some regards) but the github issues and projects do seem to have more of a feature parity with Jira now. I will plan on enabling the Github issues for Log4cxx sometime in the next few days unless somebody strongly disagrees. -Robert Middleton On Sun, Oct 23, 2022 at 7:30 PM Matt Sicker wrote: > > Jira support is left in place for anyone who heavily relies on it already. > I’d prefer not to maintain two issue repositories, so I’d lean toward > switching to GH Issues. Would be nice if we could copy existing issues over > or have some sort of redirect URLs. > > A nice advantage to uses GHI would be using other actions to help maintain a > changelog file based on issues and PRs. That sort of thing integrates nicely > with Dependabot, too! > > — > Matt Sicker > > > On Oct 23, 2022, at 15:40, Gary Gregory wrote: > > > > Using 2 issue tracking system sounds like a pain... :-( > > > > Gary > > > >> On Sun, Oct 23, 2022, 16:34 Ralph Goers wrote: > >> > >> Yup, I somehow missed that sentence. > >> > >> So they are suggesting that development continue to use Jira but users > >> report issues via GitHub. I would expect if we do that then we would also > >> create corresponding Jira issues for any of the GitHub issues we choose to > >> work on. > >> > >> Ralph > >> > >>>> On Oct 23, 2022, at 12:57 PM, Volkan Yazıcı wrote: > >>> > >>> Users will need to create a JIRA account, which needs to be supervised by > >>> the PMC, so that they can submit a bug report or ask a question. I cannot > >>> think of a more cumbersome method for a F/OSS project to accept issues. > >> Put > >>> another way, practically no public users will go this route. > >>> > >>> Please search for "GitHub Issues" in the original email, in particular, > >>> this statement: *"We suggest projects consider using GitHub Issues for > >>> customer-facing questions/bug reports/etc."* > >>> > >>> > >>> On Sun, Oct 23, 2022 at 9:48 PM Ralph Goers > >>> wrote: > >>> > >>>> I actually don’t know where this idea of switching to GitHub issues is > >>>> coming from. > >>>> The email from infra talks about how Jira will no longer allow random > >>>> users to sign > >>>> up and the tool they provided to allow the PMC to register users. I > >> would > >>>> guess the > >>>> expectation would be that we would provide some process for our users to > >>>> requests > >>>> ids from the PMC. > >>>> > >>>> What does any of this have to do with GitHub issues. I see no mention of > >>>> that in > >>>> the email from infra. > >>>> > >>>> Ralph > >>>> > >>>>> On Oct 23, 2022, at 12:10 PM, Volkan Yazıcı wrote: > >>>>> > >>>>> I personally think this is great news in the long run. I already had > >>>>> pitched the idea of moving to GitHub Issues earlier, but it was back > >> then > >>>>> rejected due to various reasons; GitHub is proprietary, JIRA also plays > >>>> an > >>>>> archive role due to its age, `changes.xml` sort-of requires JIRA > >> tickets, > >>>>> etc. World spam organizations solved the discussion for everyone. > >>>>> > >>>>> We were already receiving bug reports via Issues, nothing has changed > >> in > >>>>> this regard. Yet we need to reflect the official switch to Issues in > >> our > >>>>> documentation, which right now points users to JIRA > >>>>> <https://logging.apache.org/log4j/2.x/support.html>, too. I also > >> expect > >>>>> more questions funneled via StackOverflow, since several people were > >>>> using > >>>>> JIRA for asking questions too. Last but not least, maybe this would > >>>> create > >>>>> sufficient leverage to replace `changes.xml` with something else. > >>>>> > >>>>> On Sat, Oct 22, 2022 at 4:53 AM Matt Sicker wrote: > >>>>> > >>>>>> This is relevant to potentially swit
Re: [log4cxx] JIRA Updates and next release?
There are not many important changes. It looks like really only the following has changed: * LOGCXX-556 - issue with the syslog appender * Multiple process support for the BufferedWriter * Fix the build with Qt * Mocking the clock(really only relevant for unit tests) * Static initialization updates The good news is that making the release is very easy at this point. All you have to do is to define APACHE_MAINTAINER and do 'make dist' to generate the tar.gz/zip files and the checksums, build and upload the site to staging, and upload the binaries to the SVN repo for voting on. -Robert Middleton On Mon, Sep 26, 2022 at 9:13 PM Stephen Webb wrote: > > I just went through the differences between master and rel/v0.13.0 and the > only significant fix I saw in master was the crash in a statically linked > log4cxx library. > > While I am not familiar with the amount of work required to create a > release (it looks like a lot), I wonder if there are enough changes in > master to justify the work of creating a release. > > On Tue, Sep 27, 2022 at 11:02 AM Robert Middleton > wrote: > > > On Mon, Sep 26, 2022 at 5:09 AM Thorsten Schöning > > wrote: > > > > * Having better error reporting - many exceptions that are thrown are > > > > basically swallowed and just print out to stderr at the moment. Come > > > > to think of it, do we even want exceptions? It seems like a bad idea > > > > for the logging framework to throw exceptions > > > > > > What else do you have in mind, some error handlers and callbacks? > > > Throwing and swallowing at some point doesn't sound that bad, as long > > > as the problem is visible somewhere. Logback pretty mich logs on > > > STDERR or STDOUT only as well. > > > > > > > Yes, error handling and/or callbacks to notify the user. There are > > certain situations where there isn't much useful information available > > unless you're looking at STDERR, and even sometimes that information > > is pretty useless. For example, if you try to use the DOMConfigurator > > and the file isn't found, the only way for you to tell that something > > went wrong is to view the output of the process; this should probably > > return a bool or something to indicate that the configuration was > > successful or not. > > > > And then there's the incredibly unhelpful error message of "please > > initialize the log4cxx system properly" which should probably print > > out a bit more as to what it tried to do and why it failed. > > > > -Robert Middleton > >
Re: [log4cxx] JIRA Updates and next release?
On Mon, Sep 26, 2022 at 5:09 AM Thorsten Schöning wrote: > > * Having better error reporting - many exceptions that are thrown are > > basically swallowed and just print out to stderr at the moment. Come > > to think of it, do we even want exceptions? It seems like a bad idea > > for the logging framework to throw exceptions > > What else do you have in mind, some error handlers and callbacks? > Throwing and swallowing at some point doesn't sound that bad, as long > as the problem is visible somewhere. Logback pretty mich logs on > STDERR or STDOUT only as well. > Yes, error handling and/or callbacks to notify the user. There are certain situations where there isn't much useful information available unless you're looking at STDERR, and even sometimes that information is pretty useless. For example, if you try to use the DOMConfigurator and the file isn't found, the only way for you to tell that something went wrong is to view the output of the process; this should probably return a bool or something to indicate that the configuration was successful or not. And then there's the incredibly unhelpful error message of "please initialize the log4cxx system properly" which should probably print out a bit more as to what it tried to do and why it failed. -Robert Middleton
Re: [log4cxx] JIRA Updates and next release?
> Just a datapoint: Debian 11 ("bookworm") will got to the first stage of freeze
> [1] on January 12th, 2023. I guess 0.13.1 will be ABI compatible, so a release
> end of this year should work. (As such changes would be allowed until February
> 12th, aka Soft-Freeze.)
> If SONAME needs to be bumped, it could get though to get it into bookworm, as
> then the January 12th deadline becomes effective for log4cxx.
Just to note: the ABI check on gitlab currently fails, but that's
because of a removal of a private static member. According to the KDE
documentation[1], that's fine to do so it would not require an SONAME
bump.
[1]: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
-Robert Middleton
[log4cxx] JIRA Updates and next release?
Thanks to Steven Webb's efforts, a number of long-standing JIRA issues have now been fixed - thank you very much! I've gone through JIRA and marked those issues as resolved at this point. This means that there are only ~9 issues left in JIRA(LOGCXX-532 can probably be closed at this point - I'm fairly certain this is invoking undefined behavior that we just can't fix while still keeping the same features). The remaining issues shouldn't involve heavy refactoring at all. This brings up the question as to what/when should the next release be? We can do an 0.13.1 to fix a handful of issues in master that have been reported, or we could do the next release as a major release(I've been calling it 1.0.0). I think there's still work that needs to be done before we do a 1.0.0, including(but not limited to): * Making sure the API is clear and stable * Making sure the ABI is stable(this should be accomplished at this point, but I want to add some reserved fields to LocationInfo incase we ever need to expand it * Any other performance improvements that we can make. If we can automate some of these performance tests, that would be great as well. * Having better error reporting - many exceptions that are thrown are basically swallowed and just print out to stderr at the moment. Come to think of it, do we even want exceptions? It seems like a bad idea for the logging framework to throw exceptions Because of the above, I'm inclined to do an 0.13.1 release before the end of the year and wait a bit on the next major version before we're comfortable with it. Does anybody have any thoughts? -Robert Middleton
Re: Dependabot emails are filling my mailbox
I haven't tried it, but if you go to your settings for Github you can set dependabot to not notify you. That doesn't affect the notifications@ list of course. -Robert Middleton On Fri, Sep 23, 2022 at 7:47 PM Matt Sicker wrote: > > After secretary emails, emails related to Dependabot are the next most common > message in my mailbox. I’ve already had to clear out several gigs of emails, > and these Dependabot rebases and relentless updates are making it impossible > to follow anything on the mailing lists anymore. > > Proposal: all Dependabot messages should be batched into a digest email or > similar. I don’t need multiple notifications per PR, and I don’t need dozens > of Jira issues commented on for no good reason. Alternative: disable > Dependabot as a failed experiment. > > — > Matt Sicker
[Log4cxx] Install optional headers or not?
I'm working on making network support in Log4cxx optional so that if you don't need it, you don't need to build a binary with those classes in it. This reorganization also means that the network backend is not limited to just APR, but it can be Boost instead. I'm now coming up with the question of what should we do with these classes if support is disabled? Currently things like the NTEventLogAppender are just #defined out, but the header is still installed even on Linux and OSX. The class can't be initialized from the config file as it is not registered. The options are: 1. Install the headers regardless, but the code in the .cpp file is #defined out(what the NTEventLogAppender does) 2. Only install the needed headers The disadvantage to #1 is if you are configuring Log4cxx manually for some reason, the headers will still be available and you won't get a compiler error when you build, but a linker error. Option #2 would cause a compiler error, but is not what we have been doing before. -Robert Middleton
Re: [VOTE] Release log4net 2.0.15
+1 from me - signatures and checksums look good. I didn't validate anything else as I don't use .NET. Note: You may want to not zip up the target/ directory, since that is only for maven. -Robert Middleton On Fri, Jul 29, 2022 at 6:26 PM Ralph Goers wrote: > > But I just looked at dist/release/log4net and the artifacts are there. This > means you have already released the artifacts publicly despite the vote > having not completed. You cannot really remove them as they propagate to > mirrors fairly quickly. > > You need to create a confluence page with the release process so you can > follow it step by step. This allows anyone to perform the release and helps > you to remember how to do it since it isn’t something that is done all that > frequently. > > Ralph > > > > > On Jul 29, 2022, at 3:22 PM, Ralph Goers wrote: > > > > But never mind. Now that I look I see that dist/dev/log4net has a binaries > > and sources directory. I am used to the way log4j does it where they are > > together. So they are there. > > > > Ralph > > > >> On Jul 29, 2022, at 3:20 PM, Ralph Goers > >> wrote: > >> > >> You publish to dist/dev for the vote. We review it there. You then move it > >> to dist/release after the vote passes. You obviously will not see them > >> there - or publicly in the downloads until they are moved to the release > >> directory when the vote passes. > >> > >> The ASF requires the source zip be in the downloads directory - which > >> means they have to also be in the dist directory adjacent to the binaries. > >> See https://www.apache.org/legal/release-policy.html#source-packages > >> > >> Ralph > >> > >>> On Jul 29, 2022, at 2:04 PM, Davyd McColl wrote: > >>> > >>> It is on GitHub (both in git and zip at the release), but having checked > >>> out the svn repo at https://dist.apache.org/repos/dist/release/logging/ > >>> on this machine, I don't see the 2.0.15 artifacts that I added the other > >>> day, and that comes back to my question about them not showing up in the > >>> d/l locations :/ obviously, I'm doing Something Wrong. > >>> > >>> I've re-committed from my linux machine - perhaps with better effect? > >>> -d > >>> On Jul 29 2022, at 10:37 pm, Ralph Goers > >>> wrote: > >>>> Also, is the web site being updated for the release. While not required > >>>> for a release we usually have a web site to review with a release. > >>>> > >>>> Ralph > >>>>> On Jul 29, 2022, at 1:36 PM, Ralph Goers > >>>>> wrote: > >>>>> > >>>>> Where is the zip of the source? The ASF releases source code. Binaries > >>>>> are for the user’s convenience. > >>>>> > >>>>> Ralph > >>>>> > >>>>>> On Jul 26, 2022, at 6:25 PM, Robert Middleton > >>>>>> wrote: > >>>>>> > >>>>>> The binaries won't show up under downloads.apache.org until actually > >>>>>> released(e.g. under repos/dist/release/logging/log4net). That can of > >>>>>> course only happen after the release is done via this vote. > >>>>>> > >>>>>> I'll take a look at it in a bit just to validate that the signatures > >>>>>> are good, as I know nothing about .net development. > >>>>>> > >>>>>> -Robert Middleton > >>>>>> > >>>>>> On Mon, Jul 25, 2022 at 5:45 AM Davyd McColl > >>>>>> wrote: > >>>>>>> > >>>>>>> Hi all > >>>>>>> > >>>>>>> It's been a while, but I've finally tied together some work in a > >>>>>>> 2.0.15 release for log4net. An rc tag is up at GitHub with details: > >>>>>>> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.15-rc1 > >>>>>>> I've pushed docs to staging as well as binaries to > >>>>>>> https://dist.apache.org/repos/dist/dev/logging/log4net, however > >>>>>>> I don't see the 2.0.15 artifacts up at > >>>>>>> https://downloads.apache.org/logging/log4net > >>>>>>> > >>>>>>> This is probably why download links from > >>>>>>> https://logging.staged.apache.org/log4net/download_log4net.html > >>>>>>> aren't working? > >>>>>>> > >>>>>>> @Ralph, I'd appreciate any assistance here - I'm probably missing > >>>>>>> something obvious ): > >>>>>>> > >>>>>>> Thanks > >>>>>>> -d > >>>>> > >>>> > >>> > >> > > >
Re: [VOTE] Release log4net 2.0.15
The binaries won't show up under downloads.apache.org until actually released(e.g. under repos/dist/release/logging/log4net). That can of course only happen after the release is done via this vote. I'll take a look at it in a bit just to validate that the signatures are good, as I know nothing about .net development. -Robert Middleton On Mon, Jul 25, 2022 at 5:45 AM Davyd McColl wrote: > > Hi all > > It's been a while, but I've finally tied together some work in a 2.0.15 > release for log4net. An rc tag is up at GitHub with details: > https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.15-rc1 > I've pushed docs to staging as well as binaries to > https://dist.apache.org/repos/dist/dev/logging/log4net, however > I don't see the 2.0.15 artifacts up at > https://downloads.apache.org/logging/log4net > > This is probably why download links from > https://logging.staged.apache.org/log4net/download_log4net.html aren't > working? > > @Ralph, I'd appreciate any assistance here - I'm probably missing something > obvious ): > > Thanks > -d
Re: [VOTE] Release Log4j Kotlin API 1.2.0-rc4
+1 Notes: * Copyright needs updating * I did not check maven artifacts, only distribution archives. * I did not test any code, I validated that signatures and checksums are good. -Robert Middleton On Fri, Jun 24, 2022 at 8:39 PM Matt Sicker wrote: > > Bump again. > — > Matt Sicker > > > On Jun 21, 2022, at 14:04, Remko Popma wrote: > > > > +1 > > > > > > > >> On Jun 22, 2022, at 2:09, Matt Sicker wrote: > >> > >> Bump. > >> > >>> On Sat, Jun 18, 2022 at 12:07 PM Matt Sicker wrote: > >>> > >>> Hi all, this is a vote to release Log4j Kotlin API 1.2.0 rc4. This vote > >>> will be open for at least 72 hours, requires at least 3 +1 votes and more > >>> +1 votes than -1 votes. Details on the release candidate are below. If > >>> you are not a Kotlin user, you can validate this release just like any > >>> other Apache release and defer to the Kotlin users here on more complex > >>> usage. > >>> > >>> Please download, test, and cast your votes on the log4j developers list. > >>> [] +1, release the artifacts > >>> [] -1, don't release because… > >>> > >>> Changes in this release include: > >>> > >>> * LOG4J2-3218: Update Log4j dependency to 2.17.2. > >>> > >>> Tag: > >>> a) for a new copy do "git clone > >>> https://github.com/apache/logging-log4j-kotlin.git” and then "git > >>> checkout tags/log4j-api-kotlin-1.2.0-rc4” or just "git clone -b > >>> log4j-api-kotlin-1.2.0-rc4 > >>> https://github.com/apache/logging-log4j-kotlin.git; > >>> b) for an existing working copy to “git pull” and then “git checkout > >>> tags/log4j-api-kotlin-1.2.0-rc4” > >>> > >>> Web Site: https://logging.staged.apache.org/log4j/kotlin/index.html > >>> > >>> Maven Artifacts: > >>> https://repository.apache.org/content/repositories/orgapachelogging-1085/ > >>> > >>> Distribution archives: > >>> https://dist.apache.org/repos/dist/dev/logging/log4j/kotlin/ > >>> > >>> You may download all the Maven artifacts by executing: > >>> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate > >>> https://repository.apache.org/content/repositories/orgapachelogging-1085/org/apache/logging/log4j/ > >>> > >>> — > >>> Matt Sicker > >>> >
[General] What is logging?
Since I have encountered a few people people before who have asked questions along the lines of "why do we need good logging? and what is logging?" I figured it would be good to make a general overview guide that is not specific to log4j/log4cxx/log4net, but may still touch on concepts of these libraries that make them good. Some of the terminology here could probably be better standardized, so any suggestions are welcome! I may turn this into a presentation to break it up as well, I haven't decided yet. Github PR: https://github.com/apache/logging-site/pull/1 -Robert Middleton
Re: [log4j] The great plugin migration - can we donate some plugins to more appropriate maintainers?
It seems to me that this would only work if a) there exists a stable API/ABI for log4j and b) sufficient demand for the appenders exists. If a stable API/ABI doesn't exist, then the new maintainers would be on the hook for any changes that log4j made, which seems unreasonable to me. -Robert Middleton On Tue, Jun 7, 2022 at 2:40 PM Piotr P. Karwasz wrote: > > Hi, > > On Tue, 7 Jun 2022 at 20:17, Matt Sicker wrote: > > * JDBC/JPA appenders -> ? (Eclipse Jakarta perhaps?) > > I would try EclipseLink, since Hibernate made their choice a long time ago. > > > * JMS appender (could go to ActiveMQ or Jakarta) > > An in-house collaboration with ActiveMQ seems more realistic. > > > * SMTP appender -> makybe Jakarta? > > Jakarta Mail has a stable API, we can keep this one. > > > For any plugins we're trying to move, if the upstream projects don't > > want them, then those modules get EOL'd and removed for 3.x. > > I would settle for a list of maintainers from those projects that are > willing to help, whenever they decide on breaking an API or to advise > which version should be supported and which one can be dropped. > > Regarding `log4j-appserver`, the Jetty part is obsolete (does not work > with Jetty 10) and the Tomcat part could be migrated to Tomcat. It's > only one class, but there is also an old PR of mine that I closed in > order not to pollu^wenrich Log4j2 with new external dependencies. > > Piotr
[log4cxx] Historical websites
I was going to go modify our changelog page earlier today to allow for permalinks to the websites for specific versions, but I discovered that this is not possible due to the rewrite rules in place. For example, https://logging.apache.org/log4cxx/0.12.0 goes to https://logging.apache.org/log4cxx/latest_stable/0.12.0/, which of course leads to a 404 error. Is it useful to have the historical websites available? Or should we keep the current behavior and always point to the newest website? -Robert Middleton
Re: [VOTE] Release log4cxx 0.13.0
Adding my +1 With that the release passes with binding +1 votes from Remko, Matt, and me, and +1 votes from Stephen and Thorsten. -Robert Middleton On Sun, Apr 24, 2022 at 5:50 PM Matt Sicker wrote: > > +1 > > Notes: > > * NOTICE file needs an updated copyright > — > Matt Sicker > > > On Apr 17, 2022, at 02:21, Stephen Webb wrote: > > > > +1 > > > > I tested 0.13.0 on Ubuntu and Windows - all OK > > > > On Sat, Apr 16, 2022 at 7:47 PM Thorsten Schöning > > wrote: > > > >> Guten Tag Robert Middleton, > >> am Samstag, 16. April 2022 um 03:00 schrieben Sie: > >> > >>> This is a vote to release log4cxx 0.13.0. > >> > >> +1 > >> > >> Mit freundlichen Grüßen > >> > >> Thorsten Schöning > >> > >> -- > >> AM-SoFT IT-Service - Bitstore Hameln GmbH > >> Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK > >> > >> E-Mail: thorsten.schoen...@am-soft.de > >> Web:http://www.AM-SoFT.de/ > >> > >> Tel: 05151- 9468- 0 > >> Tel: 05151- 9468-55 > >> Fax: 05151- 9468-88 > >> Mobil: 0178-8 9468-04 > >> > >> AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 > >> Hameln > >> AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska > >> > >> > >> Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. > >> > >> Mit freundlichen Grüßen, > >> > >> Thorsten Schöning > >> > >> > >> Telefon: +49 (0)515 94 68 - 0 > >> Fax: > >> E-Mail: tschoen...@am-soft.de > >> > >> AM-Soft IT-Service - Bitstore Hameln GmbH > >> Brandenburger Straße 7c > >> 31789 Hameln > >> > >> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte > >> Informationen und ist ausschliesslich für den Adressaten bestimmt. > >> Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten > >> ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail > >> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und > >> vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail > >> bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung > >> oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im > >> Vertrauen auf erlangte Information untersagt. > >> > >> This e-mail may contain confidential and/or privileged information and is > >> intended solely for the addressee. Access to this email by anyone else is > >> unauthorized. If you are not the intended recipient (or have received this > >> e-mail in error) please notify the sender immediately and destroy this > >> e-mail. If you are not the intended recipient, any disclosure, copying, > >> distribution or any action taken or omitted to be taken in reliance on it, > >> is prohibited and may be unlawful. > >> > >> Hinweise zum Datenschutz: bitstore.group/datenschutz > >> > >> > >> > >> >
[VOTE] Release log4cxx 0.13.0
This is a vote to release log4cxx 0.13.0. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... This 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. Changes can be found on JIRA: https://issues.apache.org/jira/projects/LOGCXX/versions/12351040 Tag: For a new copy do "git clone https://github.com/apache/logging-log4cxx.git; and then "git checkout tags/v0.13.0-RC1" For an existing working copy, do "git pull" and then "git checkout tags/v0.13.0-RC1" Web site: https://logging.staged.apache.org/log4cxx/next_stable/ Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4cxx/ Building directions are on the website(under 'Development'). Note that APR is required to build(as well as boost if your compiler does not support C++17). -Robert Middleton
Re: Dynamically updating filters across many instances
So if I'm understanding you correctly, you want to do live debugging of one
user's information, but you can't do that because that information is not
going to the logs. In order to get that information, some part of log4j
would need to be reconfigured in order to send that information out to the
logs.
I haven't done much with Spring before, so I can't really speak to that
part of it much. If only one person is attempting to view the logs, then
something like the following would be my idea:
1. Connect to the service using a log viewing application of some kind
2. Using this log viewing application, send a special command that
reconfigures a filter on whatever appender the log viewing application is
using. Presumably this is some sort of user input box.
This probably wouldn't scale all that well to the hundreds of instances
that you have, as I'm assuming that the reason you would commit a config
file in git is so that all the services can pull the new file at (more or
less) the same time and all reconfigure appropriately. The advantage
however is that it wouldn't require any config file changes, and you don't
spam the log viewing application with useless log messages(e.g. filter on
the log4j side instead of sending all messages to the log viewer and
filtering there).
-Robert Middleton
On Wed, Apr 6, 2022 at 3:14 AM Ralph Goers
wrote:
> I’m looking for some inspiration.
>
> At work we use Spring Cloud Config and host our logging configuration
> there. It is shared by something like 150 services, which comes out to
> hundreds of service instances. We have a standard of including the user’s
> id and the customer’s account number in the ThreadContext and passing those
> automatically from one service to another. Operationally, went to normally
> log at WARN or INFO. But when a customer calls with a problem we want to be
> able to enable debug logging for that user or account. I know I could use
> either the DynamicThresholdFilter or the ContextMapFilter to do this.
>
> So here are the issues.
> 1. We don’t really want operations folks editing the log4j configuration
> file directly.
> 2. Our SCC uses a Git repo hosted by a third party. We don’t really want
> to open access to allow Git to call SCCs endpoint to notify it of changes.
> 3. Without the Git notification we will have to poll for changes in SCC.
> This means it could be a few minutes before SCC notices changes and then
> another few minutes before Log4j notices changes.
>
>
> I’m considering doing something like:
>
> onMatch="ACCEPT" onMismatch="NEUTRAL">
>
>
>
> Where scc represents a new SpringCloudConfigLookup. This would have to
> represent a file in SCC that contains a mapping for accountNumber to
> something.
>
> There are a number of issues with this.
> 1. This still requires editing and committing a file.
> 2. It has the polling delay.
> 3. Log4j-Spring-Cloud-Config would have to cause the file to be monitored
> just as the config file is.
> 4. The syntax of the existing Filters requires that when looking for
> multiple users each must be specified in its own key. That would mean the
> filter would have to be preconfigured with the maximum number of accounts
> it can look for. It would also mean the syntax for specifying the account
> numbers could get messy. However, it could register a Watcher for the
> external file and force a reconfiguration when it does.
>
> An alternative to reconfiguring could be to specify the variable as
> $${src:accountNumber) and resolve the lookup for every log event.
> Presumably it would use a cached value and cause the value to change when
> the file is changed.
>
> These are just the first few things I thought of to do this. Does anyone
> else have any ideas?
>
> Ralph
[log4cxx] Release time?
I'm thinking it may be about time for a release in order to fix a number of the issues that have been fixed since 0.12.0. The only thing left to do at this point is a relatively minor issue with documentation, and to update the ABI checks so that it doesn't fail anymore via github actions. The current issues fixed can be found here: https://issues.apache.org/jira/projects/LOGCXX/versions/12351040 Is there anything else that would be good for this version? Most of the other issues currently in JIRA are a bit more complicated to fix, so this seems like a pretty good stopping point. -Robert Middleton
Re: [Chainsaw] Removal of Log4j1
I just merged it in a few hours ago, but if you are able to check it out that would be nice too! It is still a little buggy at the moment, so some changes still need to be done. I've started updating at least some of the documentation here: https://github.com/apache/logging-chainsaw/tree/documentation-updates The newest documentation is up on the staging site too: https://logging.staged.apache.org/chainsaw/2.2.0/quicktour.html -Robert Middleton On Fri, Mar 4, 2022 at 6:30 PM Scott Deboy wrote: > I'll check out your branch - there are a ton of features, I'll put > some documentation together on what exists. > > Advertiser support is already there now btw. > > Scott > > On 2/21/22, Robert Middleton wrote: > > I've finished removing log4j1 from Chainsaw. If anybody would like to > take > > a look, it is in a PR here: > > https://github.com/apache/logging-chainsaw/pull/11 > > > > The next steps probably are: > > * Make sure dependencies are up to date > > * Create a better way of documenting how receivers work other than just > > throwing javadoc at the user > > * Create a full tutorial and documentation for chainsaw, since the > > documentation is pretty non-existent now > > * Integrate with the Advertisers that log4j2 has so you can easily > connect > > to an application using log4j2 > > * Look at JDeploy that Matt linked to and determine if that would be a > good > > way to distribute chainsaw > > > > -Robert Middleton > > > > On Mon, Jan 17, 2022 at 2:02 PM Robert Middleton > > wrote: > > > >> Thanks for the input. In that case I will certainly make sure that we > >> do keep the VFSLogFilePatternReceiver. > >> > >> One thing that would be helpful if you have time Scott would be a > >> manual on how to use Chainsaw and the features that it has. I > >> understand it enough now, but for people first trying to use it there > >> isn't really any good documentation. > >> > >> -Robert Middleton > >> > >> On Mon, Jan 17, 2022 at 1:17 AM Scott Deboy > >> wrote: > >> > > >> > Looks great! > >> > > >> > It's a lot of work for sure - lots more to do to fully remove log4j1 - > >> > custom level support (java.util.logging and Android for example), > >> > support for UI-based interactions for some receivers(activateOptions), > >> > and the loggerRepository extension pieces. > >> > > >> > I definitely want to see VFSLogFilePatternReceiver preserved of course > >> > - it's turned out to be a very useful Receiver (parse mostly-arbitrary > >> > log formats, even remote/ssh). > >> > > >> > Happy to help I just never have much time. > >> > > >> > Scott > >> > > >> > > >> > > >> > On 1/16/22, Robert Middleton wrote: > >> > > I've been working on this for a little bit now, and I do have > >> > > something that mostly seems to work. This has been made somewhat > >> > > more > >> > > difficult by the very tight coupling that Chainsaw has with log4j1 > >> > > and > >> > > its plugin framework. At this point, I've done the following: > >> > > > >> > > * Remove dependency on log4j1-extras > >> > > * Add in log4j2 dependencies for logging > >> > > * Create a generic Chainsaw log event that is used to pass log > events > >> > > around internally > >> > > * Rework the receivers framework to use ServiceLoader instead of > some > >> > > home-grown system > >> > > > >> > > If people are willing to take a look at what I've done so far, the > >> > > (very rough still) branch is here: > >> > > https://github.com/rm5248/logging-chainsaw/tree/remove-log4j1 > >> > > > >> > > There are still a number of bugs in it still, since there's a fair > >> > > amount of invasive surgery. If you want to test, you'll need to do > >> > > the following: > >> > > 1. Remove your ~/.chainsaw directory(this may or may not be needed; > >> > > it > >> > > doesn't seem to like to load old settings at the moment) > >> > > 2. Start chainsaw > >> > > 3. Open the 'receivers' panel(icon that looks like a satellite dish) > >> > > 4. Create a new JSON receiver. There's only one option, so you can > >> click > >> > >
Re: [Chainsaw] Removal of Log4j1
I've finished removing log4j1 from Chainsaw. If anybody would like to take a look, it is in a PR here: https://github.com/apache/logging-chainsaw/pull/11 The next steps probably are: * Make sure dependencies are up to date * Create a better way of documenting how receivers work other than just throwing javadoc at the user * Create a full tutorial and documentation for chainsaw, since the documentation is pretty non-existent now * Integrate with the Advertisers that log4j2 has so you can easily connect to an application using log4j2 * Look at JDeploy that Matt linked to and determine if that would be a good way to distribute chainsaw -Robert Middleton On Mon, Jan 17, 2022 at 2:02 PM Robert Middleton wrote: > Thanks for the input. In that case I will certainly make sure that we > do keep the VFSLogFilePatternReceiver. > > One thing that would be helpful if you have time Scott would be a > manual on how to use Chainsaw and the features that it has. I > understand it enough now, but for people first trying to use it there > isn't really any good documentation. > > -Robert Middleton > > On Mon, Jan 17, 2022 at 1:17 AM Scott Deboy wrote: > > > > Looks great! > > > > It's a lot of work for sure - lots more to do to fully remove log4j1 - > > custom level support (java.util.logging and Android for example), > > support for UI-based interactions for some receivers(activateOptions), > > and the loggerRepository extension pieces. > > > > I definitely want to see VFSLogFilePatternReceiver preserved of course > > - it's turned out to be a very useful Receiver (parse mostly-arbitrary > > log formats, even remote/ssh). > > > > Happy to help I just never have much time. > > > > Scott > > > > > > > > On 1/16/22, Robert Middleton wrote: > > > I've been working on this for a little bit now, and I do have > > > something that mostly seems to work. This has been made somewhat more > > > difficult by the very tight coupling that Chainsaw has with log4j1 and > > > its plugin framework. At this point, I've done the following: > > > > > > * Remove dependency on log4j1-extras > > > * Add in log4j2 dependencies for logging > > > * Create a generic Chainsaw log event that is used to pass log events > > > around internally > > > * Rework the receivers framework to use ServiceLoader instead of some > > > home-grown system > > > > > > If people are willing to take a look at what I've done so far, the > > > (very rough still) branch is here: > > > https://github.com/rm5248/logging-chainsaw/tree/remove-log4j1 > > > > > > There are still a number of bugs in it still, since there's a fair > > > amount of invasive surgery. If you want to test, you'll need to do > > > the following: > > > 1. Remove your ~/.chainsaw directory(this may or may not be needed; it > > > doesn't seem to like to load old settings at the moment) > > > 2. Start chainsaw > > > 3. Open the 'receivers' panel(icon that looks like a satellite dish) > > > 4. Create a new JSON receiver. There's only one option, so you can > click > > > 'ok' > > > 5. Run log4j2 with a configuration file similar to the following: > > > > > > ?xml version="1.0" encoding="UTF-8"?> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You should then see log messages showing up in a new tab. > > > > > > -Robert Middleton > > > > > > On Tue, Dec 28, 2021 at 6:32 AM Volkan Yazıcı wrote: > > >> > > >> +1 for implementation-agnostic custom DTO tailored for Chainsaw. > > >> > > >> On Mon, Dec 27, 2021 at 9:31 PM Matt Sicker wrote: > > >> > > >> > I agree on the generic approach. While there’s a LogEvent interface > in > > >> > log4j2, it would probably make sense for Chainsaw to define its own > > >> > DTOs > > >> > and such. > > >> > -- > > >> > Matt Sicker > > >> > > > >> > > On Dec 26, 2021, at 15:50, Ralph Goers < > ralph.go...@dslextreme.com> > > >> > wrote: > > >> > > > > >> > > Scott has been sort of maintaining Chainsaw on his own for years. > I > > >> >
Re: [Chainsaw] Removal of Log4j1
Thanks for the input. In that case I will certainly make sure that we do keep the VFSLogFilePatternReceiver. One thing that would be helpful if you have time Scott would be a manual on how to use Chainsaw and the features that it has. I understand it enough now, but for people first trying to use it there isn't really any good documentation. -Robert Middleton On Mon, Jan 17, 2022 at 1:17 AM Scott Deboy wrote: > > Looks great! > > It's a lot of work for sure - lots more to do to fully remove log4j1 - > custom level support (java.util.logging and Android for example), > support for UI-based interactions for some receivers(activateOptions), > and the loggerRepository extension pieces. > > I definitely want to see VFSLogFilePatternReceiver preserved of course > - it's turned out to be a very useful Receiver (parse mostly-arbitrary > log formats, even remote/ssh). > > Happy to help I just never have much time. > > Scott > > > > On 1/16/22, Robert Middleton wrote: > > I've been working on this for a little bit now, and I do have > > something that mostly seems to work. This has been made somewhat more > > difficult by the very tight coupling that Chainsaw has with log4j1 and > > its plugin framework. At this point, I've done the following: > > > > * Remove dependency on log4j1-extras > > * Add in log4j2 dependencies for logging > > * Create a generic Chainsaw log event that is used to pass log events > > around internally > > * Rework the receivers framework to use ServiceLoader instead of some > > home-grown system > > > > If people are willing to take a look at what I've done so far, the > > (very rough still) branch is here: > > https://github.com/rm5248/logging-chainsaw/tree/remove-log4j1 > > > > There are still a number of bugs in it still, since there's a fair > > amount of invasive surgery. If you want to test, you'll need to do > > the following: > > 1. Remove your ~/.chainsaw directory(this may or may not be needed; it > > doesn't seem to like to load old settings at the moment) > > 2. Start chainsaw > > 3. Open the 'receivers' panel(icon that looks like a satellite dish) > > 4. Create a new JSON receiver. There's only one option, so you can click > > 'ok' > > 5. Run log4j2 with a configuration file similar to the following: > > > > ?xml version="1.0" encoding="UTF-8"?> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You should then see log messages showing up in a new tab. > > > > -Robert Middleton > > > > On Tue, Dec 28, 2021 at 6:32 AM Volkan Yazıcı wrote: > >> > >> +1 for implementation-agnostic custom DTO tailored for Chainsaw. > >> > >> On Mon, Dec 27, 2021 at 9:31 PM Matt Sicker wrote: > >> > >> > I agree on the generic approach. While there’s a LogEvent interface in > >> > log4j2, it would probably make sense for Chainsaw to define its own > >> > DTOs > >> > and such. > >> > -- > >> > Matt Sicker > >> > > >> > > On Dec 26, 2021, at 15:50, Ralph Goers > >> > wrote: > >> > > > >> > > Scott has been sort of maintaining Chainsaw on his own for years. I > >> > > am > >> > sure he would love new energy in the project. > >> > > > >> > > I think isolating it from any logging framework implementation would > >> > > be > >> > a good thing. > >> > > > >> > > Ralph > >> > > > >> > >> On Dec 26, 2021, at 2:13 PM, Robert Middleton > >> > >> > >> > wrote: > >> > >> > >> > >> I've been looking into Chainsaw to remove Log4j1, since that is > >> > >> rather > >> > >> obsolete at this point. Unfortunately, Chainsaw is closely tied to > >> > >> Log4j1, as it seems that what happens is when it receives events > >> > >> from > >> > >> a source, it sends the messages to a custom LoggerRepository with a > >> > >> custom appender that will then show the log messages. > >> > >> > >> > >> There are also a handful of classes from the log4j1 extras package > >> > >> that are used as well, such as Rule. > >> > >> > >> > >> It seems to me that the proper way to do this then is to: > >> > >> * Copy any of the log4j1 extras classes we need into Chainsaw > >> > >> * Define an internal representation of log messages so that we don't > >> > >> depend on the log4j1 LoggingEvent class(perhaps a modified version > >> > >> of > >> > >> the log4j1 LoggingEvent) > >> > >> * Refactor the code so that when a log event comes in, we simply > >> > >> push > >> > >> it to whatever tab we want to see it on, instead of indirectly via > >> > >> log4j1. > >> > >> * Create a custom Appender for log4j2 so that we can still see > >> > >> internal Chainsaw messages within Chainsaw, and convert internal log > >> > >> messages to log4j2. > >> > >> > >> > >> Thoughts? > >> > >> > >> > >> -Robert Middleton > >> > >> > >> > > > >> > > >> > > >
Re: [Chainsaw] Removal of Log4j1
I've been working on this for a little bit now, and I do have something that mostly seems to work. This has been made somewhat more difficult by the very tight coupling that Chainsaw has with log4j1 and its plugin framework. At this point, I've done the following: * Remove dependency on log4j1-extras * Add in log4j2 dependencies for logging * Create a generic Chainsaw log event that is used to pass log events around internally * Rework the receivers framework to use ServiceLoader instead of some home-grown system If people are willing to take a look at what I've done so far, the (very rough still) branch is here: https://github.com/rm5248/logging-chainsaw/tree/remove-log4j1 There are still a number of bugs in it still, since there's a fair amount of invasive surgery. If you want to test, you'll need to do the following: 1. Remove your ~/.chainsaw directory(this may or may not be needed; it doesn't seem to like to load old settings at the moment) 2. Start chainsaw 3. Open the 'receivers' panel(icon that looks like a satellite dish) 4. Create a new JSON receiver. There's only one option, so you can click 'ok' 5. Run log4j2 with a configuration file similar to the following: ?xml version="1.0" encoding="UTF-8"?> You should then see log messages showing up in a new tab. -Robert Middleton On Tue, Dec 28, 2021 at 6:32 AM Volkan Yazıcı wrote: > > +1 for implementation-agnostic custom DTO tailored for Chainsaw. > > On Mon, Dec 27, 2021 at 9:31 PM Matt Sicker wrote: > > > I agree on the generic approach. While there’s a LogEvent interface in > > log4j2, it would probably make sense for Chainsaw to define its own DTOs > > and such. > > -- > > Matt Sicker > > > > > On Dec 26, 2021, at 15:50, Ralph Goers > > wrote: > > > > > > Scott has been sort of maintaining Chainsaw on his own for years. I am > > sure he would love new energy in the project. > > > > > > I think isolating it from any logging framework implementation would be > > a good thing. > > > > > > Ralph > > > > > >> On Dec 26, 2021, at 2:13 PM, Robert Middleton > > wrote: > > >> > > >> I've been looking into Chainsaw to remove Log4j1, since that is rather > > >> obsolete at this point. Unfortunately, Chainsaw is closely tied to > > >> Log4j1, as it seems that what happens is when it receives events from > > >> a source, it sends the messages to a custom LoggerRepository with a > > >> custom appender that will then show the log messages. > > >> > > >> There are also a handful of classes from the log4j1 extras package > > >> that are used as well, such as Rule. > > >> > > >> It seems to me that the proper way to do this then is to: > > >> * Copy any of the log4j1 extras classes we need into Chainsaw > > >> * Define an internal representation of log messages so that we don't > > >> depend on the log4j1 LoggingEvent class(perhaps a modified version of > > >> the log4j1 LoggingEvent) > > >> * Refactor the code so that when a log event comes in, we simply push > > >> it to whatever tab we want to see it on, instead of indirectly via > > >> log4j1. > > >> * Create a custom Appender for log4j2 so that we can still see > > >> internal Chainsaw messages within Chainsaw, and convert internal log > > >> messages to log4j2. > > >> > > >> Thoughts? > > >> > > >> -Robert Middleton > > >> > > > > > > >
Re: Google OSS-Fuzz
> I am tinkering with the idea of a Kickstarter-like initiative to sign up > for this. Maybe as a 2-months-long gig? > That sounds like it could be a GSoC thing(if nobody else is interested). The ASF has participated a number of times before. -Robert Middleton
Re: Jira review
The Log4cxx JIRA is pretty clean at the moment - Thorsten went through it a few months ago so there's not much (if anything) to do there. -Robert Middetlon On Fri, Jan 7, 2022 at 11:47 AM Matt Sicker wrote: > > I think this is a great idea. I'm sure we can find some dupes and link > some other issues into existing epics along with other housekeeping. > > On Fri, Jan 7, 2022 at 8:26 AM Ralph Goers wrote: > > > > You mean Log4j 2 Jira issues. Yes, please. At least once a month. Possibly > > twice so > > we can get through the backlog. If Log4cxx and Log4Net want to do something > > similar > > I’m sure a few of us would be happy to help even though we may not know the > > code. > > > > Ralph > > > > > On Jan 7, 2022, at 5:48 AM, Gary Gregory wrote: > > > > > > We have mentioned in the past going through Jiras in a meeting once in a > > > while. Does anyone still have to appetite for this review? Should we > > > schedule it? > > > > > > Gary > >
[log4cxx] next_stable and other fixes
Just as a note to all, what I've been doing with next_stable is to periodically merge master back in once I make fixes on master(assuming that those fixes are common to both). Unfortunately with the multithreaded speed fix this has resulted in a moderately sized merge conflict. I think I've fixed everything to work properly at this point. What should our workflow be? Is there a better way? Obviously there are certain things that would only target next_stable and not master, so I'm not thinking about those cases for this. -Robert Middleton
Re: [log4cxx] Short filename options
Thinking about this a bit more still, I think we can do this in two ways to make everything work properly. We can check for the __cpp_lib_string_view macro and/or _MSVC_LANG(because windows always needs to be different), and if the compiler supports std::string view we use that at compile-time to pass in the const char* to the LocationInfo class. If we can't do it at compile time, we will figure it out at runtime inside of the LocationInfo. Either way this adds one const char* to the LocationInfo class. Regardless, the full path to the file is still embedded in the binaries of users of the library unless you explicitly turn that off. I'll add some documentation related to that. -Robert Middleton On Sun, Jan 2, 2022 at 8:07 AM Thorsten Schöning wrote: > > Guten Tag Robert Middleton, > am Sonntag, 2. Januar 2022 um 02:38 schrieben Sie: > > > 2. Create a constexpr function that we control[...] > > 3. Use std::string_view(for C++17) or > > boost::string_view(pre-c++17).[...] > > Just to make sure I understand correctly: The difference between 2 and > 3 is using a custom implementation vs. an already available one? > > As we rely on boost for whatever is not supported by the compiler > anyway already, I prefer yur option 3 then. Looking at the PR, we had > already three different implementations proposed in the end and I > don't see any benefit to discuss those further when "string_view" > handles all of this already. > > > [...]I can see certain > > circumstances where it is useful to have the full path, for example > > when you have two files named the same(please don't do this). > > I'm doing this sometimes and in theory it shouldn't be a problem if > placed into different namespaces. Shouldn't it? Of course some broken > IDEs/compilers like Embarcadero C++-Builder don't work properly with > that in case of incremental builds, but that's not too much of a > problem for me. > > Regarding absolute paths, one might want to keep in mind that not > everyone ships results from automatic builds like Jenkins only and/or > uses multiple different branches for different customers with slightly > modified codebase at the same time. So keeping absolute paths if > available before makes sense to me. > > Mit freundlichen Grüßen > > Thorsten Schöning > > -- > AM-SoFT IT-Service - Bitstore Hameln GmbH > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK > > E-Mail: thorsten.schoen...@am-soft.de > Web:http://www.AM-SoFT.de/ > > Tel: 05151- 9468- 0 > Tel: 05151- 9468-55 > Fax: 05151- 9468-88 > Mobil: 0178-8 9468-04 > > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska > > > >
Re: [log4cxx] Short filename options
The full path is already in the compiled code anyway, this would
simply add the ability to get the filename from the full path(so
another member to the LocationInfo class). I can see certain
circumstances where it is useful to have the full path, for example
when you have two files named the same(please don't do this).
That does bring up a good point though, is that if you don't want
location info compiled in, we should have a preprocessor macro that
will compile out all of the location info data. We can already
compile out log messages of certain levels, so hiding the location is
just a natural extension of that.
-Robert Middleton
On Sat, Jan 1, 2022 at 7:50 PM Stephen Webb wrote:
>
> I prefer option 2 if it is possible.
>
> I do not think it is useful to have the full path name (of the build
> directory) in shipped binaries.
>
> On Sun, Jan 2, 2022 at 7:11 AM Robert Middleton
> wrote:
>
> > PR #75 adds a new option for displaying the short filename of the log
> > location, which is probably a good idea to have, as in my experience,
> > the whole path of the file is not that useful, especially when the
> > binary is from a build server where the path is something like
> > /var/lib/jenkins/project-name/src/main/directory/foo.cpp.
> >
> > The current PR does this with some string manipulation at runtime, and
> > is different from the const char* that is currently used, so it
> > doesn't fit that well with the rest of the class. Since C++11 we can
> > now do constexpr functions, so we should be able to do this at compile
> > time(assuming you have optimizations turned on of course).
> >
> > We can do this one of several ways:
> > 1. Take the PR as is(use strings and calculate at runtime)
> > 2. Create a constexpr function that we control to calculate the
> > filename at compile time as either an offset into the filename or a
> > separate const char*. The advantage to this is that it doesn't
> > require any other libraries for pre-C++17 compilers.
> > 3. Use std::string_view(for C++17) or boost::string_view(pre-c++17).
> > The following would work for this solution:
> > std::string_view str{"/foo/bar/what.cpp"};
> > const int location = str.find_last_of( '/' ) + 1;
> > printf( "fullPath: %s\n", str.data() );
> > printf( "fileName: %s\n", [location] );
> >
> > Does anybody have a preference or a better way to do it? I'm inclined
> > to go with (3), since that does provide a good fallback for compilers
> > that don't support C++17, and only requires boost for older compilers.
> >
> > -Robert Middleton
> >
[log4cxx] Short filename options
PR #75 adds a new option for displaying the short filename of the log
location, which is probably a good idea to have, as in my experience,
the whole path of the file is not that useful, especially when the
binary is from a build server where the path is something like
/var/lib/jenkins/project-name/src/main/directory/foo.cpp.
The current PR does this with some string manipulation at runtime, and
is different from the const char* that is currently used, so it
doesn't fit that well with the rest of the class. Since C++11 we can
now do constexpr functions, so we should be able to do this at compile
time(assuming you have optimizations turned on of course).
We can do this one of several ways:
1. Take the PR as is(use strings and calculate at runtime)
2. Create a constexpr function that we control to calculate the
filename at compile time as either an offset into the filename or a
separate const char*. The advantage to this is that it doesn't
require any other libraries for pre-C++17 compilers.
3. Use std::string_view(for C++17) or boost::string_view(pre-c++17).
The following would work for this solution:
std::string_view str{"/foo/bar/what.cpp"};
const int location = str.find_last_of( '/' ) + 1;
printf( "fullPath: %s\n", str.data() );
printf( "fileName: %s\n", [location] );
Does anybody have a preference or a better way to do it? I'm inclined
to go with (3), since that does provide a good fallback for compilers
that don't support C++17, and only requires boost for older compilers.
-Robert Middleton
Re: [VOTE] Future of Log4j 1.x
+1 to option 1 -Robert Middleton On Wed, Dec 29, 2021 at 2:33 PM Christian Grobmeier wrote: > > Hello, > > as discussed in another thread, this is a vote about the future of log4j 1. > This vote stays open for the usual 72h. > Options are explained below. > > You can vote for: > > [ ] +1, Option 1 > [ ] +1, Option 2 > [ ] +/- 0, abstain > [ ] -1 object against those options > > Option 1: Create a README.md that publishes the projects EOL status and do > nothing else. > Option 2: Create a README which says the project is EOL but allow the > following work for 1.2.18 AND create a full release: > a. Make the build work with a modern version of Maven. > b. Fix the Java version bug. > c. Fix CVE-2021-4104 (expanded to address all JNDI components) > d. Fix CVE-2019-17571 > > Regards, > Christian > -- > The Apache Software Foundation > V.P., Data Privacy
Re: [log4cxx] How to run the throughput test?
After taking a look at this, maybe the best option is to add the throughput as a unit test so that we can set the path the same as the other unit tests? If it is not added as a unit test it won't be run(which is good), but if we enable the option it will run. You can also run individual tests through visual studio, so that might solve the problem. Looking at the CMakeLists.txt, it doesn't actually do anything with the path that it calculates, it's only building the exe. I did try to add a custom target, but that does not let you set the environment(which needs to be set for us to load the required DLLs from the PATH). -Robert Middleton On Wed, Dec 29, 2021 at 5:27 PM Stephen Webb wrote: > > That looks like a cmake issue - could you try cmake version 3.22? > > I am still using Visual Studio 2019 Community Edition. > > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> > Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > On Thu, Dec 30, 2021 at 4:30 AM Robert Middleton > wrote: > > > Perhaps we need to add a custom target to CMake to make it runnable? > > I think that would then hook into visual studio to make it easy to > > run; I'll try to take a look at it tonight. > > > > The part of the CMakeLists.txt file that does that was copy > > from one directory up, so it could be a directory level issue that I > > missed. > > > > -Robert Middleton > > > > On Wed, Dec 29, 2021 at 7:15 AM Thorsten Schöning > > wrote: > > > > > > Hi everyone, > > > > > > I just tried to run the throughput test: Installed FMT using VCPKG, > > > changed CMAKE to option that test ON and things built successfully. > > > Though, running fails because log4cxx.dll can't be found. In theory > > > CMAKE should already handle that using the following line: > > > > > > > set(LOG4CXX_DLL_DIR "$>;") > > > > > > Though, doesn't seem to work for my Windows and Visual Studio 2022. > > > The actual path of that DLL is the following: > > > > > > > [...]\master\src\out\build\x64-Debug\src\main\cpp\log4cxx.dll > > > > > > Using PROCMON I can see that the test tries to load the file from the > > > following LOG4CXX-specific directories instead: > > > > > > > > > [...]\master\src\out\build\x64-Debug\src\test\cpp\throughput\log4cxx.dll > > > > [...]\master\src\out\build\x64-Debug\src\test\cpp\helpers\log4cxx.dll > > > > > > Looking at the CMAKE file this somewhat makes sense, because at least > > > the first line is the target directory of the throughput test. > > > > > > How is your setup? Do you manually copy the DLL or are executing the > > > throughput test differently and Visual Studio makes a difference here? > > > > > > Mit freundlichen Grüßen > > > > > > Thorsten Schöning > > > > > > -- > > > AM-SoFT IT-Service - Bitstore Hameln GmbH > > > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und > > TK > > > > > > E-Mail: thorsten.schoen...@am-soft.de > > > Web:http://www.AM-SoFT.de/ > > > > > > Tel: 05151- 9468- 0 > > > Tel: 05151- 9468-55 > > > Fax: 05151- 9468-88 > > > Mobil: 0178-8 9468-04 > > > > > > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 > > Hameln > > > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska > > > > > > > > > > > > > >
Re: [log4cxx] How to run the throughput test?
Perhaps we need to add a custom target to CMake to make it runnable? I think that would then hook into visual studio to make it easy to run; I'll try to take a look at it tonight. The part of the CMakeLists.txt file that does that was copy from one directory up, so it could be a directory level issue that I missed. -Robert Middleton On Wed, Dec 29, 2021 at 7:15 AM Thorsten Schöning wrote: > > Hi everyone, > > I just tried to run the throughput test: Installed FMT using VCPKG, > changed CMAKE to option that test ON and things built successfully. > Though, running fails because log4cxx.dll can't be found. In theory > CMAKE should already handle that using the following line: > > > set(LOG4CXX_DLL_DIR "$>;") > > Though, doesn't seem to work for my Windows and Visual Studio 2022. > The actual path of that DLL is the following: > > > [...]\master\src\out\build\x64-Debug\src\main\cpp\log4cxx.dll > > Using PROCMON I can see that the test tries to load the file from the > following LOG4CXX-specific directories instead: > > > [...]\master\src\out\build\x64-Debug\src\test\cpp\throughput\log4cxx.dll > > [...]\master\src\out\build\x64-Debug\src\test\cpp\helpers\log4cxx.dll > > Looking at the CMAKE file this somewhat makes sense, because at least > the first line is the target directory of the throughput test. > > How is your setup? Do you manually copy the DLL or are executing the > throughput test differently and Visual Studio makes a difference here? > > Mit freundlichen Grüßen > > Thorsten Schöning > > -- > AM-SoFT IT-Service - Bitstore Hameln GmbH > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK > > E-Mail: thorsten.schoen...@am-soft.de > Web:http://www.AM-SoFT.de/ > > Tel: 05151- 9468- 0 > Tel: 05151- 9468-55 > Fax: 05151- 9468-88 > Mobil: 0178-8 9468-04 > > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska > > > >
Re: [log4cxx] CI Benchmarking
I think adding it to github actions(while certainly not ideal) is at least a step in the right direction. If/when we have dedicated hardware to test it properly, we can then migrate it over. At least having it setup to start with should make migration easier, plus even if it's not super consistent we should at least be able to get a rough order of magnitude over dozens of builds. -Robert Middleton On Tue, Dec 28, 2021 at 7:30 AM Volkan Yazıcı wrote: > > Agreed with your remarks regarding the unreliability of benchmark results > in the cloud. See my proposal in private@ to get some machines for > continuous benchmarks. > > On Tue, Dec 28, 2021 at 10:17 AM Dominik Psenner wrote: > > > Hi Stephen, > > > > The trouble with benchmarks in CI is that the numbers may be largely > > unreliable, depending mostly on the hardware where it runs and in general > > the surrounding environment. Chances are high that the benchmarks will not > > produce comparable results. > > > > It would however be good to provide some tools to run the (same) benchmarks > > manually. > > > > When run on the same hardware with different codebases or on different > > hardware with the same codebase, the outcome may provide interesting and > > comparable insights. > > > > Warm regards > > -- > > Sent from my phone. Typos are a kind gift to anyone who happens to find > > them. > > > > On Tue, Dec 28, 2021, 07:46 Stephen Webb wrote: > > > > > Hi, > > > > > > Robert has created a benchmark that I thought would be nice to integrate > > > into CI. > > > > > > I see the Log4J has some benchmarks actions which are currently run > > > manually with results posted to github pages. > > > > > > Do you consider this a useful/optimal approach? > > > > > > Would an threshold which an action could check for each PR be useful? > > > > > > Regards > > > Stephen Webb > > > > > > < > > > > > https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail > > > > > > > Virus-free. > > > www.avast.com > > > < > > > > > https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail > > > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > > >
[Chainsaw] Removal of Log4j1
I've been looking into Chainsaw to remove Log4j1, since that is rather obsolete at this point. Unfortunately, Chainsaw is closely tied to Log4j1, as it seems that what happens is when it receives events from a source, it sends the messages to a custom LoggerRepository with a custom appender that will then show the log messages. There are also a handful of classes from the log4j1 extras package that are used as well, such as Rule. It seems to me that the proper way to do this then is to: * Copy any of the log4j1 extras classes we need into Chainsaw * Define an internal representation of log messages so that we don't depend on the log4j1 LoggingEvent class(perhaps a modified version of the log4j1 LoggingEvent) * Refactor the code so that when a log event comes in, we simply push it to whatever tab we want to see it on, instead of indirectly via log4j1. * Create a custom Appender for log4j2 so that we can still see internal Chainsaw messages within Chainsaw, and convert internal log messages to log4j2. Thoughts? -Robert Middleton
Re: [GitHub] [logging-log4j2] carterkozak commented on a change in pull request #657: Api separation documentation
There are some .md.vm files in that same directory, but I'm not sure
exactly how that works - it looks like it will do variable
replacement, but there are also some $h2 thingies there, so I didn't
want to mess with figuring out how it all goes together.
-Robert Middleton
On Fri, Dec 24, 2021 at 4:37 PM Gary Gregory wrote:
>
> I versions need to be variables somehow, it's going to be forgotten for
> each new release...
>
> Gary
>
> On Fri, Dec 24, 2021 at 4:27 PM GitBox wrote:
>
> >
> > carterkozak commented on a change in pull request #657:
> > URL:
> > https://github.com/apache/logging-log4j2/pull/657#discussion_r775080805
> >
> >
> >
> > ##
> > File path: src/site/markdown/api-separation.md
> > ##
> > @@ -0,0 +1,241 @@
> > +
> > +
> > +
> > +# API Separation
> > +
> > +When selecting a logging library, some care must be taken in order to
> > ensure
> > +that multiple different logging libraries are properly accounted for. For
> > +example, library code that you depend on may use slf4j, while other
> > libraries
> > +may simply use java.util.logging. All of these can be routed to the log4j
> > +core in order to be logged.
> > +
> > +If however you want to use a different logging implementation(such as
> > logback),
> > +it is possible to route messages from the Log4j API to logback, ensuring
> > that
> > +your application is not tied to a specific logging framework.
> > +
> > +A typical class using the Log4j2 API looks like the following:
> > +
> > +```java
> > +import org.apache.logging.log4j.LogManager;
> > +import org.apache.logging.log4j.Logger;
> > +
> > +public class Log4j2Test {
> > +private static final Logger logger = LogManager.getLogger();
> > +
> > +public Log4j2Test(){
> > +logger.info( "Hello World!" );
> > +}
> > +}
> > +```
> > +
> > +In order to use the API portion of Log4j2, we only need to provide a
> > single
> > +dependency, log4j-api. Using Maven, you would add the following to your
> > +dependencies:
> > +
> > +```
> > +
> > +org.apache.logging.log4j
> > +log4j-api
> > +2.17.0
> > +
> > +```
> > +
> > +## Using Log4j2 API and Core
> > +
> > +Using the Log4j2 API and Core together means that log messages will be
> > routed
> > +through the Log4j2 Core. The Log4j2 core is responsible for the
> > +following(note: this is not an exhaustive list):
> > +
> > +* Configuration of the system(via an XML file for example)
> > +* Routing messages to appenders
> > +* Opening files and other resources for logs(e.g. network sockets)
> > +
> > +When using the Log4j2 core, this means that your config file must match
> > the
> > +[configuration](manual/configuration.html) used by Log4j2.
> > +
> > +To use both the API and the core, you would add the following to your
> > +dependencies(assuming that you are using Maven):
> > +
> > +```
> > +
> > +org.apache.logging.log4j
> > +log4j-api
> > +2.17.0
> > +
> > +
> > +org.apache.logging.log4j
> > +log4j-core
> > +2.17.0
> > +
> > +```
> > +
> > +Note that having two different versions of log4j-api and log4j-core on
> > your
> > +classpath is not guaranteed to work correctly(e.g. 2.15 of log4j-api and
> > +2.17 of log4j-core).
> > +
> > +## Using Log4j2 API with Logback
> > +
> > +Since the Log4j2 API is generic, we can use it to send messages via SLF4J
> > +and then have Logback do the actual logging of the messages. This means
> > +that you can write your code tied to the Log4j2 API, but users of your
> > +code do not need to use the Log4j2 core if they are already using Logback.
> > +
> > +To switch to using Logback, you will need to add the following to your
> > +dependencies(assumging that you are using Maven):
> > +
> > +```
> > +
> > +org.apache.logging.log4j
> > +log4j-api
> > +2.17.0
> > +
> > +
> > +org.apache.logging.log4j
> > +log4j-to-slf4j
> > +2.17.0
> > +
> > +
> > + ch.qos.logback
> > + logback-classic
> > + 1.2.10
> > +
> > +```
> > +
> > +## Using Log4j2 as an SLF4J Implementation
> > +
> > +If you don't want to depend on the Log4j2 API and instead want to use
> > SLF4J,
> > +that is possible as well. Assuming that our code looks like t
Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo
+1 On Thu, Dec 23, 2021 at 4:55 PM Vladimir Sitnikov wrote: > > +1 > > Please use the existing apache/log4j repository, and rename it accordingly > > Vladimir
Re: [VOTE] Move log4j 1.x from SVN to Git, use the current apache/log4j mirror
So it is possible, that's good to know. I was assuming that since it is currently a mirror of SVN, it couldn't be easily migrated. -Robert Middleton On Sun, Dec 19, 2021 at 2:27 AM Vladimir Sitnikov wrote: > > >I think we would > have to create a new repo and make the PR against the new repo > instead. > > Why create a new repo? The current is just fine. > > For instance, I migrated Apache JMeter from SVN to Git, and extra git > repositories were not needed. > > See > https://issues.apache.org/jira/browse/INFRA-18499?focusedCommentId=16855765=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16855765 > > Vladimir
Re: [VOTE] Move log4j 1.x from SVN to Git, use the current apache/log4j mirror
I think the current git repo is an SVN mirror, so there's no way to merge from github into SVN(as far as I can tell). I think we would have to create a new repo and make the PR against the new repo instead. Making a new git repo is now self-serve: https://infra.apache.org/svn-to-git-migration.html The PMC chair needs to be the one to create the repo though. -Robert Middleton On Sat, Dec 18, 2021 at 11:38 AM Leo Simons wrote: > > +1 from me. > > I imagine it should make it easier to make the security release when setup > for 1.2 is more similar to 2.x. > That should mean people who are good at releasing 2.x have an easy time > releasing 1.2.18. > > I think we can (and should) do this in such a way that 1.2 EOL status > becomes *more* clear to git people. > > To that end, in the case where SVN stays as the source, I think we should > still add a README.md to the trunk, so that https://github.com/apache/log4j > makes it very clear the package is EOL. > > > Cheers, > > > Leo > > On Thu, Dec 16, 2021 at 5:50 AM Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > > > Hi, > > > > I suggest log4j 1.x moves from SVN to Git. > > I do not expect to have great development, however, moving to Git would > > make > > it easier to contribute and review changes. > > > > [ ] +1 let's move to Git and make SVN read-only > > [ ] -1 don't do that because ... > > > > Here's my vote: +1 > > > > Vladimir > >
Re: Log4J 1.x progress, pull request(s), plans
I can do the security release if something exists in a good state. The reasoning for me is that there are still many applications that exist that have not upgraded, even though it's been 6+ years. If it is binary compatible as well, that makes upgrades easy(I'm thinking of a case where you have an application from a 3rd party that you need to use but the vendor won't update because it's EOL or something like that). Dropping the new JAR in should be good enough to mitigate security vulnerabilities for those applications. -Robert Middleton On Sat, Dec 18, 2021 at 7:52 AM Vladimir Sitnikov wrote: > > >From my side what I volunteered for is to propose changes that should go in > >that fix for review. > > Thank you. > > >Similarly to set up git(hub) requires a PMC member. > >Hopefully the [VOTE] on that is revisited and then someone sets it up. > > Would you please express your opinion on "[VOTE] Move log4j 1.x from SVN to > Git..." thread? > Non-committers can vote. > > Frankly speaking, it is really sad that committers and PMCs are silent > regarding 1.x security. > The Git mirror already exists, making SVN read-only is trivial. > I do not believe it takes that much effort to vote for the migration. > I do not really understand the reasons behind vetoing the move to Git. > Why veto the security fix for log4j 1.x in case you are not interested in > 1.x development? > > If all the current members for PMC logging are indifferent regarding 1.x, > can there be a new PMC for log4j 1.x? > > >In that case we can put an unofficial release somewhere on github. > > I think there are many forks that fix 1.x security, especially, in-house > ones. > For instance, https://github.com/JetBrains/intellij-deps-log4j > > Vladimir
Re: [VOTE] Release log4net 2.0.14
> I have updated staging docs and I _think_ I've done the right thing with > respect to getting binaries and source up to the dev repo at > https://dist.apache.org/repos/dist/dev/logging, but the download links on > the staging docs point to the release download area, so I'm not sure if I > should rather upload there so that staging documentation "works as > expected" for the vote to continue. My understanding is that you don't upload to the release area until the release is done. Having the staging docs point at the release area is fine to me at least(it's what I do for log4cxx), since that's effectively a known issue with a release vote in my mind. Anyway, I checked the binaries on https://dist.apache.org/repos/dist/dev/logging, unfortunately it seems as though there may be two problems: 1. SHA512 does not match the zip files at all 2. Signature doesn't seem to be valid, or I don't have the pubkey. Which key is it signed with? -Robert Middleton On Thu, Dec 16, 2021 at 8:47 AM Davyd McColl wrote: > > Hi all > > I'd like to raise a vote to release log4net 2.0.14. Changelog is up on the > pre-release page at > https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1 > > I have updated staging docs and I _think_ I've done the right thing with > respect to getting binaries and source up to the dev repo at > https://dist.apache.org/repos/dist/dev/logging, but the download links on > the staging docs point to the release download area, so I'm not sure if I > should rather upload there so that staging documentation "works as > expected" for the vote to continue. > > Thanks Ralph for assisting me in being able to uplodate artifacts myself. > Much appreciated. > > -d > > PS. This email is a duplicate of the one sent from my work email ( > davyd.mcc...@codeo.co.za) which I believe has been lost somewhere along the > way. Please ignore the other if it pops up. > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > If you say that getting the money is the most important thing > You will spend your life completely wasting your time > You will be doing things you don't like doing > In order to go on living > That is, to go on doing things you don't like doing > > Which is stupid. > > - Alan Watts > https://www.youtube.com/watch?v=-gXTZM_uPMY > > *Quidquid latine dictum sit, altum sonatur. *
Re: [VOTE] Move log4j 1.x from SVN to Git, use the current apache/log4j mirror
I think this is a good idea - regardless of whether or not we do a release of 1.2, having the git repo easily available for reference is nice. -Robert Middleton On Thu, Dec 16, 2021 at 12:18 PM Matt Sicker wrote: > > I think migrating the repo to Git would make an eventual release easier to > accomplish. I’ll note that long ago before Log4j2 switched to Git, I was > using our Subversion repository via git-svn anyways, so that’s also an option > (note that it’s a little finicky as you can’t introduce complicated commit > histories back into subversion). However, if that approach doesn’t work for > performing a release, then I think it would make sense to migrate. We can > always mark the repository as archived on GitHub after the release. > -- > Matt Sicker > > > On Dec 16, 2021, at 07:32, Gary Gregory wrote: > > > > Let me also point out another aspect of the overall issue for Log4j 1 vs 2: > > Log4j 2 provides a compatibility layer for 1, for the 1.2 API and for some > > configuration files. It is not a 100% drop in replacement, but it could be > > made much better with some work. So, I would prefer that brain power for > > 1.x be applied in this direction, such that we could say update to 2.x and > > pow, it works :-) > > > > Gary > > > > On Thu, Dec 16, 2021, 08:13 Gary Gregory wrote: > > > >> I am just voicing my opinion, others can still cause this to pass. > >> > >> Gary > >> > >> On Thu, Dec 16, 2021, 00:12 Vladimir Sitnikov > >> wrote: > >> > >>> I thought there was an agreement on releasing 1.2.18 as "networkless" > >>> release. > >>> I think moving to Git (which is a no-op basically), would greatly simplify > >>> that. > >>> > >>>> 1.x has been EOL since 2015 > >>> > >>> There's a demand for fixing CVEs in 1.x > >>> > >>>> with possible confusion as to which version > >>>> 1.x vs 2.x to use in which circumstance > >>> > >>> There are cases when users can't upgrade. For instance, if they use > >>> configuration from code, etc. > >>> > >>>> 1.x has been EOL since 2015, this would only encourage full resurrection > >>> > >>> 1.x live as long as there are individuals that want to maintain it. > >>> As of now, several people suggested patches that make 1.x buildable float > >>> at dev@logging. > >>> Having the same patches as GitHub PR would make it easier for everyone. > >>> > >>> Vladimir > >>> > >> >
Re: [log4cxx] ABI stability
At this point, I believe that I have converted all of the important classes to be ABI-stable. There are a few that I have missed, some probably unintentional, some because I plan on removing them. There are also a handful of classes that don't need to be(nor perhaps should be) ABI-stable - I'm thinking mostly of the LocationInfo in PR#75. We should probably allocate a few extra bytes onto the end of any classes like LocationInfo incase we ever need to add extra members(the current PR does break the ABI as it changes the size of the LocationInfo class - we don't make any claims as to being ABI-stable at the moment, so it doesn't really matter). As per the LocationInfo, in the future we should probably make more use of std::string_view(C++17) or the equivalent boost::string_view. The string_view would be perfect for use in the LocationInfo class, since it just needs to point at a const char* but having the ability to do string-like functions would be useful. I suspect that there are several other places where we can make use of string_view as well, perhaps gaining some performance improvements. Some notes on string_view: https://rules.sonarsource.com/cpp/RSPEC-6009 I'll merge this into a new branch(log4cxx-next?) shortly, unless anybody finds any problems. Once that is complete, it should be much easier to fix problems going forward. I think my immediate plans after this would be to: * Get the multi-process RollingFileAppender working. Since you currently need a custom-built version of log4cxx to make it work, it's of somewhat limited usefulness at the moment(I don't think there are any tests at the moment either, so that's not too useful) * Remove any APR references in the header files. Since most of what we use APR for is in C++11, my plan is to try to eliminate APR for basic logging setups. e.g. the date/time that is used can be replaced with std::chrono, threads we have already switched to std::thread, networking we can switch between using APR and using boost::asio, etc. This /should/ mean that if you have a C++11 only compiler, you'll need to have boost installed to build, but if you have a C++17 compiler you won't need any dependencies to build. -Robert Middleton On Sun, Nov 7, 2021 at 12:02 PM Thorsten Schöning wrote: > > Guten Tag Robert Middleton, > am Sonntag, 7. November 2021 um 17:36 schrieben Sie: > > > I don't see any advantage to this over a macro, unless you were > > thinking of something else? > > That's exactly what I meant and the benefits I see are simply avoiding > a macro and having something documented for the class as part of its > (private) API. With having that method abstract, one can even force > it's implementation in subclasses, resulting in a more uniform access > to the data across the code base etc. > > That's different with a macro, which might result in bad error > messages during compilation, might be named differently across > classes, might not be available because devs missed it etc. > > Though, it's a matter of taste most likely. > > Mit freundlichen Grüßen > > Thorsten Schöning > > -- > AM-SoFT IT-Service - Bitstore Hameln GmbH > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK > > E-Mail: thorsten.schoen...@am-soft.de > Web:http://www.AM-SoFT.de/ > > Tel: 05151- 9468- 0 > Tel: 05151- 9468-55 > Fax: 05151- 9468-88 > Mobil: 0178-8 9468-04 > > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska > > > >
Re: [log4cxx] ABI stability
I think I see what you're saying now. We can do something like this:
class A{
virtual APrivate* private_data(){
return priv.get();
}
unique_ptr priv;
};
class B: public A{
virtual BPrivate* private_data(){
return static_cast(priv.get());
}
};
I don't see any advantage to this over a macro, unless you were
thinking of something else?
-Robert Middleton
On Sat, Nov 6, 2021 at 12:42 PM Thorsten Schöning wrote:
>
> Guten Tag Robert Middleton,
> am Samstag, 6. November 2021 um 16:52 schrieben Sie:
>
> > Unfortunately not, for the reasons above. Since the parent class only
> > holds a single pointer to the private data, whatever data is stored
> > must be a subclass of the parent's private data. So we must cast it
> > to whatever class's private data that we are currently using.
>
> Understood, but does it really needs to be a macro? Why not use a
> method implementing the cast which can then be overridden by
> subclasses as necessary? Looks like a covariant return type to me,
> doesn't it?
>
> https://en.wikipedia.org/wiki/Covariant_return_type
>
> Mit freundlichen Grüßen
>
> Thorsten Schöning
>
> --
> AM-SoFT IT-Service - Bitstore Hameln GmbH
> Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK
>
> E-Mail: thorsten.schoen...@am-soft.de
> Web:http://www.AM-SoFT.de/
>
> Tel: 05151- 9468- 0
> Tel: 05151- 9468-55
> Fax: 05151- 9468-88
> Mobil: 0178-8 9468-04
>
> AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
>
>
>
>
Re: [log4cxx] ABI stability
> Great work! Is there something I should specifically look out when
> testing or would it be fione to know if things run at all already?
>
Mostly just looking for anything obvious that I may have missed, or
concerns with the implementation.
> Get a lot of warnings like this one currently:
>
> > Schweregrad CodeBeschreibungProjekt Datei Zeile
> > Unterdrückungszustand
> > Warnung C4251 "log4cxx::helpers::FileInputStream::m_priv": class
> > "std::unique_ptr>"
> > erfordert eine DLL-Schnittstelle, die von Clients von class
> > "log4cxx::helpers::FileInputStream" verwendet wird
> > C:\Users\tschoening\Documents\Svn\Src\Libs\trunk\C++\Logging\log4cxx\master\src\out\build\x64-Debug\src
> >
> > C:\Users\tschoening\Documents\Svn\Src\Libs\trunk\C++\Logging\log4cxx\master\src\src\main\include\log4cxx\helpers\fileinputstream.h
> > 40
>
I'm going to guess that is something about not being able to use the
class across a DLL boundary. That's /probably/ not an issue for
reasons that I'll get into in a moment.
> Should this be the following instead? Looks like a copy error.
>
> > std::unique_ptr m_priv;
>
Yeah that's probably just a copy/paste error.
> Some naming discussion: How about using "ParentPriv" and
> "ParentPriv.h" instead of heaving "ParentPrivate", "Parent-private.h"
> and "m_priv". It's shorter, "-private" doesn't follow QT conventions
> anyway and the abbreviation "priv" is used already as well.
>
That sounds reasonable to me.
> When looking at your code, you are using some "XyPriv" and "xy_priv.h"
> and some "XyPrivate" and "xy_priv.h" already. For existing classes, I
> suggest keeping "xy_priv.h", but for newer classes "XyPriv" and
> "xyPriv.h" read better in my opinion. So I would suggest that in your
> new docs.
>
> About inheritance: Wouldn't it be better in most cases to provide
> protected or public getters in base classes anyway instead of
> accessing private data structs?
>
> I understand your example to show how it could be done in case no such
> getters are available or should be used for some reason. Or is that
> example showing how it needs to be done always regardless how the
> private data is accessed by subclasses?
>
The example shows how it needs to be done anyway. The reason for this
is explained a bit more in the Qt documentation, but here's a simple
explanation:
If we have a class with private data:
class A {
unique_ptr a_priv;
}
And we then need to subclass it:
class B : public A{
unique_ptr b_priv;
}
Whenever we create class B, we now do two memory allocations(APrivate
and BPrivate). In the code for B, you then also need to keep track of
which superclass actually holds the data. If we instead subclass
'APrivate' in 'BPrivate', we can then store the pointer to 'BPrivate'
in the 'A' class.
struct APrivate{
int32_t a;
};
struct BPrivate : public APrivate{
int32_t b;
};
BPrivate is now 8 bytes in size. Because it is a subclass of
APrivate, we can store the pointer to BPrivate inside of A, thus
saving us a memory allocation and letting us pretend that we still
have a "normal" inheritance:
class A{
unique_ptr priv;
};
class B: public A{
B(){
priv = make_unique(); // 'priv' is of type APrivate, so
must downclass in B whenever we want to use it
}
};
> > #define priv static_cast(m_priv.get())
>
> Does it make sense to mention something like that in your new docs?
> Is it possible to make it a (generic?) getter or alike instead of a
> macro?
Unfortunately not, for the reasons above. Since the parent class only
holds a single pointer to the private data, whatever data is stored
must be a subclass of the parent's private data. So we must cast it
to whatever class's private data that we are currently using.
Because of this as well, the 'private' classes don't actually need to
be exported out of the library: you only need them if you are
subclassing an object and you are interested in doing only one memory
allocation for your private instance variables.
-Robert Middleton
[log4cxx] ABI stability
I've been working on making log4cxx ABI stable, and I believe that I have converted most(if not all) classes at this point to be stable. I've got a branch here that has all of the changes: https://github.com/apache/logging-log4cxx/tree/LOGCXX-510 There are some notes on how this is done here: https://github.com/apache/logging-log4cxx/blob/LOGCXX-510/src/site/markdown/library-design.md If people can provide feedback on how this currently looks and if they notice anything wrong, I'd greatly appreciate it. I'm not planning on merging this to master for a while; since this contains a number of breaking changes I want to keep it separate(and do some other breaking changes in the near future). -Robert Middleton
Re: [Vote] Release log4net 2.0.13-rc2
Looks good to me. +1 -Robert Middleton On Fri, Oct 29, 2021 at 6:08 PM Davyd McColl wrote: > > Thank-you Remko > > -d > Sent from Mailspring (https://getmailspring.com/), the best free email app > for work > On Oct 29 2021, at 11:04 pm, Remko Popma wrote: > > +1 > > > > On Sat, Oct 30, 2021 at 2:13 AM Davyd McColl > > wrote: > > > > > Hi > > > > > > I'd like to raise a vote to release log4net 2.0.13 (this is an rc2 where > > > the only difference is the archive layout for the associated source and > > > binary artifacts) > > > > > > - there's an rc up at GitHub with release notes: > > > https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.13-rc2 > > > - documentation is updated on staging: > > > https://logging.staged.apache.org/log4net/ [ > > > https://logging.staged.apache.org/log4net/] > > > > > > I do, however, require some assistance with getting the artifacts from the > > > GitHub release page to download.apache.org - if I'm able to do so, I > > > don't know how, so any assistance is appreciated. > > > > > > Once ratified, I will > > > - publish to nuget.org > > > - push documentation live > > > > > > Thanks > > > -d > > > > > >
