Re: How to compile log4cxx for libc++
Have you compiled it with the autotools package at all? I *think* that all you have to do is when you do the ./configure, you can do it like the following: CC=clang ./configure and it will use clang instead of gcc. -Robert Middleton On Tue, Nov 7, 2017 at 5:51 AM, miguel angel rodriguez wrote: > Hi I would like to know how to compile log4cxx fro libc++ and clang. > Is there any build available or any that you can generate? > > Does anyone have the commands to do so through source? > > Thanks
Re: Planning out what we can do to get Chainsaw back in the game
What would the advantage be of using Scala vs just normal Java? Mostly from a curiosity standpoint; I've never done Scala so I don't know it works. Did you actually have trouble building? I'm pretty sure that when I built it a few months ago I simply opened up the project in Netbeans and it built immediately as a maven project(although looking at the POM it does look like it uses ant on the backend for some reason). -Robert Middleton On Fri, Nov 10, 2017 at 2:07 PM, Matt Sicker wrote: > Release candidate available. Based on my experiences here, I think one of > the first useful things to do for 3.x would be to overhaul the build > system. Since it seems like Scala may be the desired language to write this > in, I may experiment with using SBT for the build instead of Maven+Ant. > > On 16 October 2017 at 18:47, Matt Sicker wrote: > >> On 16 October 2017 at 16:11, Scott Deboy wrote: >> >>> FYI, I think most folks just use pattern layout, which probably makes >>> VFSLogFilePatternReceiver the most commonly used receiver. Since it's >>> VFS, anything accessible over SSH is retrievable and can be >>> live-tailed. >>> >> >> That would make sense since it doesn't have any dependencies and is the >> typical way people configure logging. It's how I usually do it, too, >> whether it's to the console or to a file. >> >> >>> I use VFSLogFilePatternReceiver in my cloud configs to remotely tail >>> logs from multiple hosts and combine those logs into a single view in >>> Chainsaw. >>> >> >> That's a pretty cool use case! >> >> -- >> Matt Sicker >> > > > > -- > Matt Sicker
Re: Planning out what we can do to get Chainsaw back in the game
With regard to the Qt idea, while that's certainly possible I don't really see the need to go that route, as it would (still) be a complete re-write at that point. While it's true that Qt does have scripting in it(QML, which is essentially JavaScript), I'm not quite sure how that solves problems. When I do GUIs in Qt, I have simply used the Widgets framework, as it's more Swing-like(I'm more comfortable in the Swing world). That being said, Qt being under an LGPL license sounds like it's a non-starter: https://www.apache.org/legal/resolved.html#category-x Perhaps a better question would be to define what exactly Chainsaw should do, rather than arguing about what technology to build it with. >From my point of view, as long as it can read log files easily, being a boring desktop app is fine, and in some ways preferable to a fancy UI. Having a program that can read log files on your phone doesn't make much sense to me, given the small screen size... -Robert Middleton On Sun, Nov 12, 2017 at 9:21 PM, Matt Sicker wrote: > On 12 November 2017 at 20:10, Ole Ersoy wrote: > >> If you use it with PouchDB, localStorage, or session storage then it's a >> NoSQL database. PouchDB also features sync replication with CouchDB. >> > > I was thinking more like the uses I've seen where ES was used in place of > something more sane like Cassandra, CouchDB, etc. > > -- > Matt Sicker
Re: [log4cxx] State of this project?
Not sure if it helps you at all, but I do have a branch that will build with libapr(not apr2) that uses CMake if you want to try it out: https://github.com/rm5248/logging-log4cxx/tree/cmake-updates -Robert Middleton On Thu, Jan 11, 2018 at 10:25 AM, James E. King, III wrote: > Hello, > > I have used log4cxx for a number of years and the last official release was > 7 years ago. There was an effort to make a 0.11.x release in October but I > don't see the result of that, plus it looks like all Windows based build > projects and tools have been removed from the trunk. There are a number of > web sites / projects out there to help people build log4cxx, apr, and > apr-util on Windows. It seems to be a second-class citizen. > > I spent yesterday making a cmake build environment for log4cxx that builds > against the libapr-2 trunk on Windows. Since apr provides its own cmake > environment, this simply picks up the installed artifacts and builds > log4cxx on Windows. In the process I have found that although static > linking seems to build okay, shared libraries are missing some > LOG4CXX_EXPORT commands. > > I was able to build on linux against the apr-2 trunk as well by telling it > that "--with-apr" and "--with-apr-util" come from the same location, since > apr-util merged into apr. > > I see no quality controls on pull requests, leveraging the free travis and > appveyor CI environments to ensure pull requests are of high quality. So > my question is this - what is the state of this project? Is it dead? Are > there people actively using it and working on it? > > Thanks, > > Jim
[log4cxx] Current State
As prompted by the discussion last week about the state of log4cxx, is there a current blocker(apart from Thorsten's time) halting a release of log4cxx/regular maintenance? I would like to help out on the project to do a release / add new features, but I'm not sure what the best way to go about this is, or even if my help is needed. There are some place where I as a user of log4cxx would like to see it go, but I don't want to spend the time to implement updates/new features if they're not going to be used. -Robert Middleton
Re: [log4j] The shape of Log4j
If you're interested in reading about how Google uses their monorepo, they have a paper you can read through: https://research.google.com/pubs/pub45424.html It's not clear to me reading the paper if they do this for all of their projects(including public repos on github) or just in-house code; it sounds like the latter. It's not something that would be practical for most projects. -Robert Middleton On Wed, Jan 24, 2018 at 7:45 PM, Matt Sicker wrote: > I'm going to sum up my view here: if we split up repos to include plugins > that depend on log4j-core, then we first need to define and release a > stable plugin API. If we can't guarantee BC for plugins, then there's no > realistic way to both split out additional plugins and have them be > officially endorsed plugins. If said plugins were completely outside Apache > (e.g., personal GitHub pages), then it wouldn't be as strict. > > Also, I find it hard to believe that Google really uses a monorepo anymore. > Such an idea wouldn't work too well with software that isn't continuously > released. > > I suppose that's an alternative: I'd be open to splitting up repos however > desired if releases were continually published to avoid version number > synchronisation efforts, but I'm not so sure how well that meshes with the > Apache Way for releasing software.
Re: Chainsaw configured in Jenkins and JIRA
The permissions seem to be wrong - I can't see the project without logging into JIRA. Also, should it go under the 'logging' category in JIRA? -Robert Middleton On Sat, Mar 10, 2018 at 1:45 AM, Matt Sicker wrote: > https://builds.apache.org/job/Chainsaw/ > https://issues.apache.org/jira/projects/CHAINSAW/summary > > I've added a minimal Jenkins file here. I also started a JIRA project, > though we still have an outstanding infra request to migrate old Bugzilla > issues there. > > -- > Matt Sicker
Log4cxx website
It looks like there's a bad redirect when vising the website from the main homepage of https://logging.apache.org/. When I click on it, I go to https://logging.apache.org/log4cxx which then goes to https://logging.apache.org/log4cxx/latest_stable/latest_stable/, which gives me a 404. I'm able to go to the website directly if I change it to go to index.html instead: https://logging.apache.org/log4cxx/latest_stable/index.html -Robert Middleton
Re: Chainsaw configured in Jenkins and JIRA
While it now shows up under the 'logging' category, I still can't see the project at all unless I'm logged in. I'm assuming that's not intentional. -Robert Middleton On Sun, Mar 11, 2018 at 7:05 PM, Matt Sicker wrote: > This was fixed yesterday by the way. I still need to gather a list of users > to add as project admins, though. > > On Sat, Mar 10, 2018 at 11:08, Matt Sicker wrote: > >> I can’t seem to change any settings. I’ll file an issue with infra. >> >> On Sat, Mar 10, 2018 at 09:44, Robert Middleton >> wrote: >> >>> The permissions seem to be wrong - I can't see the project without >>> logging into JIRA. >>> >>> Also, should it go under the 'logging' category in JIRA? >>> >>> -Robert Middleton >>> >>> On Sat, Mar 10, 2018 at 1:45 AM, Matt Sicker wrote: >>> > https://builds.apache.org/job/Chainsaw/ >>> > https://issues.apache.org/jira/projects/CHAINSAW/summary >>> > >>> > I've added a minimal Jenkins file here. I also started a JIRA project, >>> > though we still have an outstanding infra request to migrate old >>> Bugzilla >>> > issues there. >>> > >>> > -- >>> > Matt Sicker >>> >> -- >> Matt Sicker >> > -- > Matt Sicker
Re: Chainsaw configured in Jenkins and JIRA
Looks good to me. :) -Robert Middleton On Mon, Mar 12, 2018 at 10:49 AM, Matt Sicker wrote: > Alright, permissions should match that of LOG4J2. Let me know if you're > having any issues viewing it now. > > On 12 March 2018 at 09:11, Matt Sicker wrote: > >> This appears to be beyond the scope of my permissions again, so I filed a >> ticket: https://issues.apache.org/jira/browse/INFRA-16172 >> >> On 12 March 2018 at 09:07, Matt Sicker wrote: >> >>> No, that's not intentional. Thanks for the feedback! I'll see what's >>> misconfigured this morning and will report back. >>> >>> On 11 March 2018 at 21:45, Robert Middleton wrote: >>> >>>> While it now shows up under the 'logging' category, I still can't see >>>> the project at all unless I'm logged in. I'm assuming that's not >>>> intentional. >>>> >>>> -Robert Middleton >>>> >>>> On Sun, Mar 11, 2018 at 7:05 PM, Matt Sicker wrote: >>>> > This was fixed yesterday by the way. I still need to gather a list of >>>> users >>>> > to add as project admins, though. >>>> > >>>> > On Sat, Mar 10, 2018 at 11:08, Matt Sicker wrote: >>>> > >>>> >> I can’t seem to change any settings. I’ll file an issue with infra. >>>> >> >>>> >> On Sat, Mar 10, 2018 at 09:44, Robert Middleton >>>> >> wrote: >>>> >> >>>> >>> The permissions seem to be wrong - I can't see the project without >>>> >>> logging into JIRA. >>>> >>> >>>> >>> Also, should it go under the 'logging' category in JIRA? >>>> >>> >>>> >>> -Robert Middleton >>>> >>> >>>> >>> On Sat, Mar 10, 2018 at 1:45 AM, Matt Sicker >>>> wrote: >>>> >>> > https://builds.apache.org/job/Chainsaw/ >>>> >>> > https://issues.apache.org/jira/projects/CHAINSAW/summary >>>> >>> > >>>> >>> > I've added a minimal Jenkins file here. I also started a JIRA >>>> project, >>>> >>> > though we still have an outstanding infra request to migrate old >>>> >>> Bugzilla >>>> >>> > issues there. >>>> >>> > >>>> >>> > -- >>>> >>> > Matt Sicker >>>> >>> >>>> >> -- >>>> >> Matt Sicker >>>> >> >>>> > -- >>>> > Matt Sicker >>>> >>> >>> >>> >>> -- >>> Matt Sicker >>> >> >> >> >> -- >> Matt Sicker >> > > > > -- > Matt Sicker
Re: Re-enable appbundle-maven-plugin in Chainsaw build
To add a build plugin inside a profile, it should be as simple as the following: osx-build sh.tak.appbundler appbundle-maven-plugin ... other plugin information here ... I just had to do this the other day, not with a DMG builder but with the maven-assembly-plugin. So I'm reasonably sure that this will work as-is. It should package t with: mvn -P osx-build package appbundle:bundle -Robert Middleton On Thu, Mar 15, 2018 at 5:06 PM, Scott Deboy wrote: > I don't know how to fix it, but would like to be able to build > DMGs...is there an alternative to reverting this change until we can > figure out how to get both? > > On 3/15/18, Matt Sicker wrote: >> I wasn't able to figure out how to do it. I can't seem to add a build >> plugin inside a profile. Do you know how? I only discovered this issue when >> writing the Jenkinsfile since I build it on macOS locally (and while >> releasing). >> >> On 15 March 2018 at 14:58, Scott Deboy wrote: >> >>> Hi Matt, >>> >>> Re: 1123826836323a94d73355f0f6d7fd39466ad657 - Disable macOS packaging >>> step >>> >>> Looks like you disabled this to get jenkins working? Has a comment: >>> "FIXME: make this plugin optional" >>> >>> Can you re-enable it? Optional is fine, I test with this all the time. >>> >>> Thanks, >>> >>> Scott >>> >> >> >> >> -- >> Matt Sicker >>
[log4cxx] Release
Hey all, any updates on any releases for log4cxx? I know there was a push a few months ago to try and get it out but I haven't heard anything else since then. -Robert Middleton
Re: [log4cxx] Logging in Timing-Critical Applications
Interesting results! I haven't experienced any problems with logging myself, but I've also never gone into benchmarking it. I don't have much experience with memory pools, but if you're still getting blockages on a call to new/malloc you may be able to get around it by using the memory pool and then calling the constructor in-place(I have never done this before, but I know it is possible to do). [1][2]. Or there may be some way to do it using a custom allocator, that's something that I have never done either. -Robert Middleton [1]: https://stackoverflow.com/questions/519808/call-a-constructor-on-a-already-allocated-memory [2]: https://stackoverflow.com/questions/222557/what-uses-are-there-for-placement-new On Thu, Aug 16, 2018 at 11:58 AM, Matt Sicker wrote: > I don't know much about the state of log4cxx architecture, but nearly all > your points (other than the lock in stringstream) are points we optimize > for in log4j2 at least. Even the stringstream optimization sounds similar > to StringBuffer versus StringBuilder in java. As for the queue used in > async logging, I'm not sure what guarantees you get in C++ memory models, > but I'm curious if the disruptor queue pattern made its way over to boost? > > On Thu, 16 Aug 2018 at 10:37, Denys Smolainiuk < > denys.smolian...@harmonicinc.com> wrote: > >> Hello All, >> >> I'd like to share some experience as well as some patches with regard to >> using log4cxx in timing-critical application. First few words about our >> requirements: it's a service which must generate some network packets with >> up to hundred of microseconds precision. Thus, it's very important to have >> predictable code timing. One can argue that log4cxx is not very well suited >> for such applications, but surprisingly it works pretty well after some >> light tuning. >> >> So, what were the issues? >> Basically from library user's point of view they looked the same: one of a >> sudden logging done with LOG4CXX_DEBUG() macro could take unexpectedly long >> time to complete. For example the same trace which takes several μs for 99% >> of the time would take hundreds microseconds and even few milliseconds >> sometimes. After further investigation this has been traced down to few of >> the root-causes: >> >> 1. Asyns logger (which we have been using of course) has internal queue to >> pass log entries to background disk-writer thread. This queue is >> mutex-protected which might seem fine unless you think a little bit more >> about it. First of all, someone calling LOG4CXX_DEBUG() to simply put >> something into the log might not expect to be blocked inside waiting for a >> mutex at all. Second point is that, although there were measures taken to >> minimize time disk-thread holds that lock, OS-schedulers often work in a >> way that thread which is blocked on a mutex gets de-scheduled. With normal >> OS-scheduler quantum that means that the logging thread can be preempted >> for milliseconds. >> >> 2. There are some mutexes protecting internal states of both loggers and >> appenders. This means that two separate threads calling LOG4CXX_DEBUG() can >> block each other. Even if they are using different loggers they would block >> on appender! This has the same consequences for execution timing and the >> performance as described above. >> >> 3. std::stringstream class constructor has some internal locks on it's >> own. Unfortunately each MessageBuffer has it's own instance of this class. >> And also unfortunately MessageBuffer is created inside LOG4CXX_DEBUG() >> macro. There is optimization to not create stringstream for logging simple >> strings, but as soon as your log statement has single '<<' operator it's >> created. >> >> 4. Dynamic memory allocations. Unfortunately there are still quite few of >> them even though memory pool is used in some other places. Thus, hidden >> calls to new and malloc induce unpredictable delays. >> >> So, what we did to mitigate these problems? >> >> 1. Natural solution for this issue was to use atomic queue. There are few >> of them available, but we made use of boost::lockfree::queue as it can >> serve as a drop-in replacement allowing us to keep all present >> functionality. >> >> 2. After looking more into the code it has appeared that two concurrent >> calls to LOG4CXX_DEBUG() from within different threads are not harmful >> because internal structures of logger and appender are not being changed >> there. What only really requires protection is concurrency between logging >>
Re: Building the latest log4cxx from source
Sandhya, There has been no release of log4xx 0.11.0. The latest version of 0.10.0 is the latest released version. I use the version of log4cxx that is in the Debian repositories, it is still version 0.10.0 with a few patches applied. Unfortunately I can't provide any information on the multi process logging, that's not a feature that I have ever used. -Robert Middleton On Mon, Nov 26, 2018 at 2:48 PM Sandhya Sundaresan < sandhya.sundare...@esgyn.com> wrote: > Hello again, > Didn’t get any responses to my question below. Any log4cxx developers or > users out there ? A few additional questions : 1. Which version are > you’ll using ? 2. Did you build your own version from the latest > source repository and is it working ok ? 3. Is log4cxx 0.10.0 (from > 2008) really the latest release ? I see references to 0.11.0 in many of the > JIRAs but cannot find it in the Downloads page for log4cxx. > https://logging.apache.org/log4cxx/latest_stable/download.html > > > We are using log4cxx in Apache Trafodion . > > Thanks > > Sandhya > > > > > > *From:* Sandhya Sundaresan > *Sent:* Friday, November 16, 2018 3:40 PM > *To:* dev@logging.apache.org; log4cxx-u...@logging.apache.org > *Subject:* Building the latest log4csxx from source > > > > Hi, > > Has anyone built the latest version from the source tree and used it ? > Yesterday while I was looking for version 0.11 (maintenance version) to > download and try , I couldn't find the tar file and today even the broken > link is gone. So I guess I have to build it myself from source. We really > need the support for multiple processes to be able to log to one log file > working. We see incosistencies while using RollingFileAppender today and > the logfiles and backups don't happen until the logging processes stop . > > So we'd like to try with a version that has the fix for > https://issues.apache.org/jira/browse/LOGCXX-412. > > The latest source source seems to have this fix but there is no version > available for download. > > In this JIRA it says we need to set this define LOG4CXX_MULTI_PROCESS > > > > Which Makefile do I set it in so it takes effect ? > > > > Thank you in advance > > Sandhya >
Re: log4cxx vxworks
Niv, log4cxx uses mostly APR(Apache Portable Runtime) on the backend, so as long as APR is supported log4cxx may work. Most of the other stuff that is supported should be conditionally compiled. I've never used VxWorks before though, so I don't know what(if anything) works or doesn't. -Robert Middleton On Tue, Feb 19, 2019 at 1:09 AM Nachmani Niv wrote: > > Hello, > > Regarding log4cxx project, is it compatible with VxWorks? > Specific with VxWorks 7? > > Thanks, > Niv > > The information in this e-mail transmission contains proprietary and business > sensitive information. Unauthorized interception of this e-mail may > constitute > a violation of law. If you are not the intended recipient, you are hereby > notified that any review, dissemination, distribution or duplication of this > communication is strictly prohibited. You are also asked to contact the sender > by reply email and immediately destroy all copies of the original message.
Re: [C++] Found some interest from APR
Build tooling meaning what exactly? Making it easy to include the libraries in your application? -Robert Middleton On Tue, May 14, 2019 at 10:57 AM Matt Sicker wrote: > I was speaking with Bill Rowe from httpd/apr the other day at > ApacheCon Roadshow, and he's been working on some build tooling > improvements for C and C++ projects starting from apr. I'd like to > start this thread somewhat as a reminder to myself about this. He said > it may be possible that it's useful for log4net as well, though that's > unknown at this time. > > -- > Matt Sicker >
[log4cxx] releasing and contributing
Hey all, I noticed Thorsten's comment on LOG4CXX-486[1] earlier, and was wondering what is the best way to help in order to try and move this forward? It seems like the project is in a stuck place where there's enough to keep it as-is but not enough to get to a release. I'm willing to help on this, but there's only so much that I can do without being able to commit. -Robert Middleton [1]: https://issues.apache.org/jira/browse/LOGCXX-486?focusedCommentId=16948277&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16948277
[log4cxx] Contributing
Hi all, What's the bets way to contribute to log4cxx? There's a comment from a few months ago on LOG4CXX-486[1], and not much has been done since then. I'm willing to do the work to maintain log4cxx and do the release, so what is the best way to become a contributor/committer? -Robert Middleton [1]: https://issues.apache.org/jira/browse/LOGCXX-486?focusedCommentId=16948277&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16948277
Re: [log4cxx] Contributing
On Wed, Jan 1, 2020 at 10:52 AM Thorsten Schöning wrote: > > Guten Tag Robert Middleton, > am Dienstag, 31. Dezember 2019 um 21:44 schrieben Sie: > > > [...]so what is the best way to become a contributor/committer? > > I suggest you start reading through the following docs: > > > A committer is a developer that was given write access to the code > > repository and has a signed Contributor License Agreement (CLA) on > > file. They have an apache.org mail address. > > http://www.apache.org/foundation/how-it-works.html#committers > Thanks for that, I haven't seen that page before. > https://www.apache.org/foundation/getinvolved.html > https://community.apache.org/contributors/ > After re-reading these, I wonder who are the PMC members for log4cxx at the moment, and is it the same people as for log4j(e.g. Ralph, Matt, etc.)? And would it make sense for me to sign a CLA, or would that not be helpful? > The following covers what needs to be done for releases: > > http://www.apache.org/dev/release-publishing.html > http://www.apache.org/legal/release-policy.html > > Some parts have already been automated using "release_*.sh"-scripts in > the root of the project, I think up to the point on which releases > where tagged, build and uploaded to the following staging repo: > > https://dist.apache.org/repos/dist/dev/logging/log4cxx > > After that point, if I remember correctly, people need to vote on the > release, it needs to be moved to the release-repo "somehow" and your > keys used to sign the release should have been added to the keys of > the release-repo BEFOREHAND. >From my reading of the documentation, the release repo is just an SVN repository that the signed packages go to. See: http://www.apache.org/legal/release-policy.html#upload-ci Although this goes back to who exactly is PMC, since according to the documentation only the PMC members have the rights to upload... -Robert Middleton
Re: [log4cxx] Contributing
On Sat, Jan 4, 2020 at 11:40 PM Ralph Goers wrote: > > The project to which PMC members belong is Apache Logging Services. When a > committer is invited they have access to all the logging project repositories > except for the one area that is limited to PMC members. > > If you plan on making significant contributions you should sign an ICLA. > That makes sense; I'll look into doing that shortly. > Yes, there are a few steps in a release that require a PMC member but most of > the release process can be accomplished by a committer. That said, acting as > a release manager is a quick way to get invited to any ASF PMC :-) > I have been doing a lot of releases at work lately, so working on most of the release process should be pretty straightforward for me to do. I should be able to take a look at the (current) release scripts in the next few days or so. -Robert Middleton
[log4cxx] Jenkinsfile and tests
I've created a Jenkinsfile for use with log4cxx that can be seen here: https://github.com/rm5248/logging-log4cxx/blob/f39b1737541ed31b8e56a8f6f550c0797a47bca5/Jenkinsfile It's fairly complicated, but it does attempt to build log4cxx on both Windows and Linux(see the latest build here: https://jenkins.rm5248.com/job/log4cxx-pipeline/) It does this by first downloading the latest APR, APR-util, and expat, and then building those in the workspace(so that they need not be installed on the build system). However, attempting to configure log4cxx at the moment results in an error due to some of the tests, due to an extra entry in src/test/cpp/xml/CMakeLists.txt(https://github.com/apache/logging-log4cxx/blob/76671956437e35864e1a5d843cefdf42c8154b76/src/test/cpp/xml/CMakeLists.txt#L5) Anyway, it would be nice to get this running on builds.apache.org, but I don't know at the moment a) how to do that, and b) if the Jenkins instance there is configured properly in the first place. It seems that Jenkins seems to be building only Java applications, while APR and other C applications seem to be built on ci.apache.org. What's the best way to help with this? -Robert Middleton
Re: [log4cxx] Jenkinsfile and tests
I looked into using Docker, but I haven't used it enough to know how to actually get it to work correctly for that purpose. All of my personal projects get built as Debian packages, which accomplishes the same thing(with a clean filesystem for each build), but that doesn't work on Windows. If anybody has an example of how to use docker to do the builds, I'd appreciate it and could use that to create a better build environment. The Jenkins documentation is of limited usefulness, as it doesn't show how to build /inside/ the container and get the results back out while also installing the proper dependencies. -Robert Middleton On Wed, Feb 19, 2020 at 6:53 PM Matt Sicker wrote: > > Some of the Jenkins nodes have Docker available which makes building > simpler here. > > On Wed, Feb 19, 2020 at 17:49 Robert Middleton wrote: > > > I've created a Jenkinsfile for use with log4cxx that can be seen here: > > > > https://github.com/rm5248/logging-log4cxx/blob/f39b1737541ed31b8e56a8f6f550c0797a47bca5/Jenkinsfile > > > > It's fairly complicated, but it does attempt to build log4cxx on both > > Windows and Linux(see the latest build here: > > https://jenkins.rm5248.com/job/log4cxx-pipeline/) > > > > It does this by first downloading the latest APR, APR-util, and expat, > > and then building those in the workspace(so that they need not be > > installed on the build system). However, attempting to configure > > log4cxx at the moment results in an error due to some of the tests, > > due to an extra entry in > > src/test/cpp/xml/CMakeLists.txt( > > https://github.com/apache/logging-log4cxx/blob/76671956437e35864e1a5d843cefdf42c8154b76/src/test/cpp/xml/CMakeLists.txt#L5 > > ) > > > > Anyway, it would be nice to get this running on builds.apache.org, but > > I don't know at the moment a) how to do that, and b) if the Jenkins > > instance there is configured properly in the first place. It seems > > that Jenkins seems to be building only Java applications, while APR > > and other C applications seem to be built on ci.apache.org. What's > > the best way to help with this? > > > > -Robert Middleton > > > -- > Matt Sicker
Re: design rationale
Note: I wasn't involved with the design of this at all, but some thoughts:
Likely the reason this was done is because that's how log4j worked -
the classes that you see in log4cxx map closely to log4j(1) classes.
One of the problems involved with storing the level directly in the
logger would be actually traversing the log tree to find the correct
level to set would be prone to error, especially if you're changing
the levels at runtime. It's simpler and less likely to cause errors
if you simply check whenever you log a message.
With performance as well, the thing to recognize about logging(and
really outputting data from an application in general) is that writing
is slw. For instance, here's a simple C program you can try:
#include
int main( int argc, char** argv ){
for( int x = 0; x < 100; x++ ){
printf( "hi this is a line\n" );
}
}
When running on my system, this takes ~2.2 seconds to run, printing to
stdout. If I instead output the data to /dev/null, it takes between
.02 and .05 seconds. Sending it to a file about doubles this time to
about .04 - .08 seconds, so still slower than discarding the data but
several times faster than writing to stdout.
Taking all of this together, it's very likely that storing the log
level directly in the logger wouldn't have any appreciable difference
in efficiency, unless you're trying to log thousands of statements per
second. There's probably some way this could be improved, but unless
you actually profile and can point to a specific spot in the code
where a lot of time is being spent, it's probably not worth it to
change.
-Robert Middleton
On Tue, Mar 31, 2020 at 3:04 PM Norman Goldstein wrote:
>
> I very much appreciate the great description of how to use log4cxx. My
> question is about a design choice that affects performance (paragraph 2
> in https://logging.apache.org/log4cxx/latest_stable/usage.html ). A
> hierarchical approach for logging levels makes sense. However, each
> run-time check of the level involves a walk of the logger hierarchy.
> Why not do this walk when assigning levels, so that the walk does not
> need to be done at each call to log i.e. each logger stores its logging
> level, directly?
Re: [slf4j-user] Combined logging and throwing question
This would result in a large number of methods to be added most
likely, but you could potentially combine the logging with the
exception throwing:
logger.errorAndThrow( message, ValidationException.class );
which would log the message at the error level, and then use the given
class to construct the exception and throw it.
-Robert Middleton
On Wed, May 6, 2020 at 3:43 PM Matt Sicker wrote:
>
> Potentially useful API update to look at here. Some sort of Logger that
> throws an exception with the log message instead?
>
> -- Forwarded message -
> From: Norbert Kiesel
> Date: Wed, 6 May 2020 at 12:59
> Subject: [slf4j-user] Combined logging and throwing question
> To: User list for the slf4j project
>
>
> Hi,
>
> we have quite a few places in our code where we do:
>
> logger.error("Param {} must be in [{}-{}]", name, low, high);
> throw new ValidationException("Param " + name + " must be in [" + low +
> "-" + high + "]");
>
> This is obviously ugly. Other options would be to use
>
> String msg = String.format("Param %s must be in [%s-%s]", name, low,
> high);
> logger.error(msg);
> throw new ValidationException(msg);
>
> or
>
> String msg = MessageFormatter.format("Param {} must be in [{}-{}]", new
> Object[] {name, low, high}).getMessage();
> logger.error(msg);
> throw new ValidationException(msg);
>
> Both are not ideal. Can't we have a logger.format method which returns a
> FormattingTuple w/o the explicit array creation
> and allow logger.error etc. to be called with a FormattingTuple? Then I
> could write
>
> FormattingTuple entry = logger.format("Param {} must be in [{}-{}]",
> name, low, high);
> logger.error(entry);
> throw new ValidationException(entry.getMessage());
>
> For my own exception classes I could then even offer a constructor that
> takes a FormattingTuple and internally use the
> message and the throwable (if it is not null).
>
>
>
> ---
>
>
> Norbert Kiesel
> Systems Architect, Engineering
> E: nkie...@metricstream.com
> W: www.metricstream.com
>
> ___
> slf4j-user mailing list
> slf4j-u...@qos.ch
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
>
>
> --
> Matt Sicker
[log4cxx] Release Testing
I went and tested the current version of log4cxx, and at least on Linux I don't have any failures. There are a bunch of failures on the Windows side, but I don't know enough about windows to know where to start to debug those. The tests that failed: 90% tests passed, 6 tests failed out of 60 Total Test time (real) = 528.17 sec The following tests FAILED: 14 - minimumtestcase (Failed) 16 - patternlayouttest (Failed) 54 - sizebasedrollingtest (Failed) 55 - timebasedrollingtest (Failed) 57 - errorhandlertestcase (Failed) 60 - xmltests (Failed) Regardless, I've uploaded the zip and tar.gz here: https://rm5248.com/log4cxx/ As of this point, do the zip/tar.gz files contain everything required for release? Is there anything that needs to be added? I want to try and help if there's something that's missing. -Robert Middleton
Re: [log4cxx] Release Testing
> How did you create those archives? I guess you didn't use the created > release_*-scripts, but "make dist dist-zip" again? No, I used the release_prepare.sh to generate it, since it's my understanding that is the script that should do that. I'm not sure if the autotools still work at this point; I haven't tested with them in a while. > Everyone is free to ignore failing tests anyway. Not running many of > those and not notifying the user about that OTOH provides a wrong > feeling that everything's OK, while things might fail at runtime. I guess that's one way of thinking about it. However, if you do that it seems like you should always run all tests, while (for example) the NT Event Logger appender test is only run on Windows; this would always fail on Linux/OSX. As per Ralph's comment: > That said, I don’t see anyplace on the log4cxx web site that even states what > platforms it supports. It /should/ work wherever APR works, although for some parts of the code log4cxx relies on external applications being present(see [1] for example code, and [2] for the test). There's also support for uncommon character encodings like EBCDIC, which I have no idea if it still works. I would like to create a minimal library that depends solely on the C++ standard library, but that would probably be easier with more modern versions of C++(C++17 has filesystem library, C++20 introduces formatting[3], which is possibly libfmt[4] on the backend, I'm not sure). -Robert Middleton [1]: https://github.com/apache/logging-log4cxx/blob/229106fd7ce99452501bd8406bd653793c756f69/src/main/cpp/gzcompressaction.cpp#L110 [2]: https://github.com/apache/logging-log4cxx/blob/229106fd7ce99452501bd8406bd653793c756f69/src/test/cpp/rolling/sizebasedrollingtest.cpp#L188 [3]: https://en.cppreference.com/w/cpp/utility/format [4]: https://fmt.dev/latest/index.html
Re: [log4cxx] Release Testing
On Thu, Jul 16, 2020 at 2:24 AM Thorsten Schöning wrote:
> Am I correct that you are using JDK 11 already? Because I'm running
> into problems when executing Maven in my UB 16.04 with JDK 8 setup a
> while ago.
>
Correct, Java 11 and Maven 3.6.3 for me. I'm on Debian 10, so Java 11
is readily available and I simply downloaded the latest version of
maven and put it on my $PATH to execute.
> > I'm not sure if the autotools still work at this point; I haven't
> > tested with them in a while.
>
> I just did and they compiled the project fine, the only test failing
> is most likely related to my setup:
>
> > log4cxx: Cannot get information about host: unknown.invalid
> > log4cxx: Could not find unknown.invalid. All logging will FAIL.
> > log4cxx: Cannot get information about host: unknown.invalid
>
> I have a proper name in /etc/hostname, so does anyone have an idea?
>
> > apr_sockaddr_t* address = 0;
> > apr_status_t status =
> > apr_sockaddr_info_get(&address, encodedHost.c_str(),
> > APR_INET, 0, 0, addrPool.getAPRPool());
> >
> > if (status != APR_SUCCESS)
> > {
> > LogString msg(LOG4CXX_STR("Cannot get information about
> > host: "));
> > msg.append(host);
> > LogLog::error(msg);
> > throw UnknownHostException(msg);
> > }
>
> > ping ub-16-04-lts-server-x64
> > PING ub-16-04-lts-server-x64 (127.0.1.1) 56(84) bytes of data.
> > 64 bytes from ub-16-04-lts-server-x64 (127.0.1.1): icmp_seq=1 ttl=64
> > time=0.017 ms
>
> > ping 0.0.0.0
> > PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
> > 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.017 ms
>
> > ping unknown.invalid
> > ping: unknown host unknown.invalid
>
> Not sure when I executed tests the last time, might be with UB 14.04.
>
Which test is this?
> > I guess that's one way of thinking about it. However, if you do that
> > it seems like you should always run all tests, while (for example) the
> > NT Event Logger appender test is only run on Windows; this would
> > always fail on Linux/OSX.
>
> Running only those tests which are designed for some platform at all
> and most likely to succeed with somewhat easy setup does read like a
> good compromise to me. SED and Co. are really easy to provide on
> Windows, for many users of GIT or WSL already available.
>
So perhaps the best solution is based a little bit off of Stephen's
earlier PR(#18[1]), but instead of compiling out the code that depends
on gzip we make the test more granular(one test for rolling zip, one
test for rolling gz, etc) and disable[2] the test if the appropriate
executable is not found.
-Robert Middleton
[1]: https://github.com/apache/logging-log4cxx/pull/18
[2]: https://cmake.org/cmake/help/latest/prop_test/DISABLED.html
Re: [log4cxx] Release Testing
I guess I'm viewing this as an "optional" test - we know that the test is going to fail(because e.g. we don't have gzip installed), so there's no reason to run the test. If gzip is installed, then the test should run and pass appropriately. I definitely agree that developers should have all tests working. My thought is more the case of somebody who simply downloads log4cxx and wants to use it. They may be confused by the failing tests, even though they're not critical, but they don't want/need to setup a system that will cause 100% of the tests to pass. Does anything similar happen with log4j2? -Robert Middleton On Fri, Jul 17, 2020 at 6:57 AM Thorsten Schöning wrote: > > Guten Tag Robert Middleton, > am Donnerstag, 16. Juli 2020 um 14:54 schrieben Sie: > > > So perhaps the best solution is based a little bit off of Stephen's > > earlier PR(#18[1]), but instead of compiling out the code that depends > > on gzip we make the test more granular(one test for rolling zip, one > > test for rolling gz, etc) and disable[2] the test if the appropriate > > executable is not found. > > And the same with missing Java? And then you will run those tests and > tell people everything is OK? But it's too much work for you to > provide the necessary binaries in your Windows? OTOH, you don't want > to simply trust e.g. me running all Windows-tests as well and want to > run at least some of those, but not all yourself? And because they are > no docs which tests are ever executed when, those disabled in case of > a missing binary will never be executed by anone anymore? So why not > simply delete them? > > And what's with the Linux-test that fails in my environment for some > reason? Delete as wlel right away or disable first because it's not > working in my environment or what is so different to the Windows tests > not working in your environment? > > I still don't see much benefit of this approach. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...05151- 9468- 55 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow >
[log4cxx] Feature Proposals
Hey all,
I'd like to propose some new features/updates for log4cxx, if there's
interest. A number of these are rather large changes, so it probably
doesn't make sense to work on them until there's a known-good release, as
they would likely break both API and ABI compatibility.
Big Changes:
1. Using std::shared_ptr(LOG4CXX-486). I did a proof-of-concept about
three years ago at this point, but I never did a patch/pull request as this
would change quite a lot. I think as a result of this I also removed the
mutex implementation and replaced with std::mutex.
2. Removal of most APR usage. Since C++11 we have mutexes, threads,
condition_variable, time functions, atomic functions, etc. There's still
some things beyond what I've mentioned that APR provides, but I could see a
potential use-case where the core library doesn't depend on APR, although
it would have limited functionality at that point.
3. Removal of maven for site generation. While it does provide a
consistent feel with log4j2, it seems like it is the source of a large
number of problems(releasing, building, etc.). It seems to me that the
best way would be to use doxygen to generate the site instead; we can use
markdown to create documentation pages instead of the doxia apt format.
The other advantage to this would be that it also means that only one site
is generated that contains both normal documentation as well as the API
documentation at the same time.
4. ABI compatibility. It would be good to keep all instance variables
in a private data member, so that they can be added/removed without
breaking the ABI. This may require some other changes to the API though,
as it would probably break some inline methods(this pattern is commonly
called a pimpl).
Medium changes:
1. Adding in libfmt to format arguments[1]. I did a proof-of-concept
earlier today by adding a new macro earlier today that looks like the
following: LOG4CXX_ERROR_F( logger, "hi {}", "Robert" ); Since this
library provides a bunch of nice formatting functions it should make
logging much clearer and more like log4j2.
2. Remove the autotools build - it seems to me that the CMake tooling
has successfully worked, and is fully cross-platform at this point. Is
there a particular reason to keep it around still?
3. Support for log4j2-style XML/JSON/YAML documents. The information
for log4j(1) style documents is harder to find now, so it seems to me that
having commonality with log4j2 moving forward would be a good idea for
consistency.
4. Add a new library to allow logging from Qt-based applications, e.g.
log4cxx-qt. I've done this before using qInstallMessageHandler[2], so it's
not too difficult to do. Also having some default appenders for e.g.
QString is useful, so that when I'm logging I don't need to do
.toStdString() all the time on the QStrings.
Going through the currently open issues in JIRA, there's also a large
number that are either so old that they don't make much sense, or may have
been fixed already. Would it make sense to go through them at some point?
That's probably not something that I can do alone, but I can help to go
through them.
-Robert Middleton
[1]: https://fmt.dev/latest/index.html
[2]: https://doc.qt.io/qt-5/qtglobal.html#qInstallMessageHandler
Re: [log4cxx] Feature Proposals
Thorsten, > > A number of these are rather large changes, so it probably > > doesn't make sense to work on them until there's a known-good release, as > > they would likely break both API and ABI compatibility. > > Does it really matter much if things are broken now vs. with 0.12.0 or > alike? Backwards compatibility was somewhat broken already when > changing how the macros are implemented, when returning new LevelPtrs > to fix threading-issues and with introducing CMAKE in favor of > building with Maven+ANT. > I have a few thoughts on that: 1. Having a known-good release means that there should be more users, helping to better test the library. 2. It depends on the level of backwards-compatability breakage that there is. For people like you who have a limited environment, having a version that does not depend on new C++ features allows for a 'legacy' version and a 'modern' version. 3. Adopting a semver[1] versioning at some point would probably make sense. If there's an API breakage that should be properly documented as part of the versioning. Arguably since this is technically 0.11.0 version it doesn't really matter, since major version 0 allows major API breakage. > Would be enough already if you would go through them and provide a > second opinion about which of those could easily be closed. I would > close ideas like APR database layer, CI-related stuff etc. most > likely. Additionally some very old 0.9.7-related issues. But that > keeps lots of other errors and improvements like new appenders. > Here's my quick run-through of issues currently in JIRA: LOG4CXX-490 - Should be easily fixable, but do we care about VS2015? LOG4CXX-483 - Issue was resolved; I will create some documentation if this comes up again though. LOG4CXX-481 - I'm not sure who is the responsible member for this. LOG4CXX-455 - This looks to still be an issue, although I'm not sure what the correct way to do it would be. Maybe we add a new check to also suppress exceptions? LOG4CXX-454 - VS2013 issue, can probably be closed at the moment. LOG4CXX-439 - Very old, not sure if still relevant at this point LOG4CXX-438 - Very old, not sure if still relevant at this point LOG4CXX-431 - Probably still an issue, but I think the best solution here is to document and have a callback function that gets called whenever a new thread starts, allowing the user to do their own signal handling(a default implementation would be good too). e.g. log4cxx::thread::setThreadStartFn --> called in new thread. LOG4CXX-398 - It looks like this has already been fixed? LOG4CXX-396 - Probably no longer relevant with CMAKE LOG4CXX-389 - Very old and not enough information LOG4CXX-384 - Very old and not enough information LOG4CXX-377 - Very old and not enough information LOG4CXX-374 - Very old and not correct usage of the library(using std::endl in logging operation) LOG4CXX-352 - Probably not an actual bug according to the comments LOG4CXX-345 - Very old and not enough information LOG4CXX-343 - Very old and not enough information LOG4CXX-341 - Very old and not enough information LOG4CXX-338 - Very old and not much activity, probably not an issue anymore LOG4CXX-335 - Who uses sun studio anymore? LOG4CXX-333 - Very old and likely not an issue LOG4CXX-309 - Very old, probably not a bug in log4cxx LOG4CXX-301 - Very old, probably best to close it out LOG4CXX-289 - Very old, who uses Solaris anymore? LOG4CXX-276 - Looks to be fixed LOG4CXX-274 - very old at this point, may no longer be an issue LOG4CXX-261 - Very old, who uses Solaris anymore? LOG4CXX-260 - should be fixed as of LOG4CXX-457 LOG4CXX-244 - Very old versions here, I don't see the point in keeping this open. LOG4CXX-205 - Very old issue, maynot be a problem LOG4CXX-101 - Very old issue, unless somebody has a specific need to use mysql this is almost certainly too old to be useful. LOG4CXX-61 - Unless APR has database support(it doesn't seem too) this should probably be closed LOG4CXX-1 - I would say we should close this; any SMTP support may or may not even work anymore There are a bunch of other old issues as well, but some of them at least have potentially enough information to do something with. -Robert Middleton [1]: https://semver.org/
Re: [ANNOUNCE] Welcome our new committer, Robert Middleton!
Thanks! I hope to be able to contribute to other logging projects as well in the future(e.g. chainsaw). -Robert Middleton On Tue, Aug 4, 2020 at 5:35 PM Remko Popma wrote: > > Welcome, Robert! > > Remko. > > > > (Shameless plug) Every java main() method deserves http://picocli.info > > > On Aug 5, 2020, at 4:28, Matt Sicker wrote: > > > > Hi, > > > > It is my pleasure to announce to the community that Robert Middleton > > has joined our ranks. > > > > Robert has been contributing to log4cxx for a while and helping to > > shape a new release, and we think that he'll be a valuable member of > > Apache Logging Services now and in the future. Please welcome aboard > > our newest committer, Robert! > > > > Kind regards, > > Matt Sicker > > VP Logging Services, ASF
[log4cxx] Status update
In the coming week or two I will work on doing an official release for log4cxx. I just need to test on my side that I at least am comfortable with building; I don't expect any issues. The only critical thing at the moment that I can think of is LOG4CXX-512, which I discovered last night. Thorsten, are there any other issues that you can think of that are critical? I'll also close all of the issues that I put in my last email on feature proposals at that time, unless you object to those. -Robert Middleton
[VOTE] [log4xx] Release log4cxx 0.11.0
I've run through the release of log4cxx 0.11.0. There's still something strange about how it all works(mostly due to the tooling of shell script/maven/ant/cmake/autotools). However, I do believe that I have a workable release at this point. A quick note on the release: I did the 'mvn release:prepare' manually, which is where these artifacts come from; running through the 'mvn release:perform' causes the generated files to be -SNAPSHOT versioned, instead of 0.11.0. This means that the version of the pom.xml in the tag is still 0.11.0-SNAPSHOT, but since maven isn't really used to build I don't think this will be an issue. Artifacts uploaded here: https://dist.apache.org/repos/dist/dev/logging/log4cxx/ tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2 The artifacts are signed, although I still need to send my key to Matt so he can import it into the logging KEYS file. -Robert Middleton
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
This new RC has the latest fixes that we've done(LOG4CXX-512,490,398). I'm not sure exactly why the autotools are there now; something about doing the maven release triggers them. I don't think they get generated until after the website gets uploaded, which I couldn't do before. They /should/ be there in general, as that's the normal way to configure the project(unless you are checking out the source code directly). -Robert Middleton On Mon, Aug 10, 2020 at 5:50 AM Thorsten Schöning wrote: > Guten Tag Robert Middleton, > am Sonntag, 9. August 2020 um 19:24 schrieben Sie: > > > Artifacts uploaded here: > > https://dist.apache.org/repos/dist/dev/logging/log4cxx/ > > tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2 > > +1 for me. > > Do you know what's the difference compared to what you have uploaded > last time in the thread about test release? The current archives > contain more individual autotools-files. Did you simply execute > "autogen.sh" this time compared to the last? > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...05151- 9468- 55 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > >
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
So I realize that I never set a normal time for this vote to be open, but it has been 72 hours at this point. Do people still need more time to validate, or are there some issues that need to be resolved first? -Robert Middleton On Mon, Aug 10, 2020 at 5:49 PM Remko Popma wrote: > +1 > Remko. > > > > > > On Aug 11, 2020, at 6:27, Robert Middleton wrote: > > > > This new RC has the latest fixes that we've done(LOG4CXX-512,490,398). > > > > I'm not sure exactly why the autotools are there now; something about > doing > > the maven release triggers them. I don't think they get generated until > > after the website gets uploaded, which I couldn't do before. They > /should/ > > be there in general, as that's the normal way to configure the > > project(unless you are checking out the source code directly). > > > > -Robert Middleton > > > >> On Mon, Aug 10, 2020 at 5:50 AM Thorsten Schöning < > tschoen...@am-soft.de> > >> wrote: > >> > >> Guten Tag Robert Middleton, > >> am Sonntag, 9. August 2020 um 19:24 schrieben Sie: > >> > >>> Artifacts uploaded here: > >>> https://dist.apache.org/repos/dist/dev/logging/log4cxx/ > >>> tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2 > >> > >> +1 for me. > >> > >> Do you know what's the difference compared to what you have uploaded > >> last time in the thread about test release? The current archives > >> contain more individual autotools-files. Did you simply execute > >> "autogen.sh" this time compared to the last? > >> > >> Mit freundlichen Grüßen, > >> > >> Thorsten Schöning > >> > >> -- > >> Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > >> AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > >> > >> Telefon...05151- 9468- 55 > >> Fax...05151- 9468- 88 > >> Mobil..0178-8 9468- 04 > >> > >> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > >> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > >> > >> >
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Ralph, Thanks for taking a look at it whenever you get a chance. Also to note: I did manage to get it building via Github actions, and while Linux(Ubuntu) works fine, OSX has one test failure(the same that you saw the other week), and Windows has 8 failures(some are timeout, some have to do with encoding, and possibly some other issues as well). At this point that makes me much less confident in everything working properly, so perhaps it is best to fix those issues first. -Robert Middleton On Wed, Aug 12, 2020 at 10:01 PM Ralph Goers wrote: > Yeah - ideally this would be done within 72 hours but that doesn’t always > happen - especially since this is the first release in a long, long time. > I have been planning on reviewing it but probably can’t get to it until > tomorrow. > > Ralph > > > On Aug 12, 2020, at 6:34 PM, Robert Middleton > wrote: > > > > So I realize that I never set a normal time for this vote to be open, but > > it has been 72 hours at this point. Do people still need more time to > > validate, or are there some issues that need to be resolved first? > > > > -Robert Middleton > > > > On Mon, Aug 10, 2020 at 5:49 PM Remko Popma > wrote: > > > >> +1 > >> Remko. > >> > >> > >> > >> > >>> On Aug 11, 2020, at 6:27, Robert Middleton > wrote: > >>> > >>> This new RC has the latest fixes that we've done(LOG4CXX-512,490,398). > >>> > >>> I'm not sure exactly why the autotools are there now; something about > >> doing > >>> the maven release triggers them. I don't think they get generated > until > >>> after the website gets uploaded, which I couldn't do before. They > >> /should/ > >>> be there in general, as that's the normal way to configure the > >>> project(unless you are checking out the source code directly). > >>> > >>> -Robert Middleton > >>> > >>>> On Mon, Aug 10, 2020 at 5:50 AM Thorsten Schöning < > >> tschoen...@am-soft.de> > >>>> wrote: > >>>> > >>>> Guten Tag Robert Middleton, > >>>> am Sonntag, 9. August 2020 um 19:24 schrieben Sie: > >>>> > >>>>> Artifacts uploaded here: > >>>>> https://dist.apache.org/repos/dist/dev/logging/log4cxx/ > >>>>> tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2 > >>>> > >>>> +1 for me. > >>>> > >>>> Do you know what's the difference compared to what you have uploaded > >>>> last time in the thread about test release? The current archives > >>>> contain more individual autotools-files. Did you simply execute > >>>> "autogen.sh" this time compared to the last? > >>>> > >>>> Mit freundlichen Grüßen, > >>>> > >>>> Thorsten Schöning > >>>> > >>>> -- > >>>> Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > >>>> AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > >>>> > >>>> Telefon...05151- 9468- 55 > >>>> Fax...05151- 9468- 88 > >>>> Mobil..0178-8 9468- 04 > >>>> > >>>> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > >>>> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > >>>> > >>>> > >> > > >
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
By my count at this point, that means we have 3 binding +1 votes from Ralph, Christian, Remko; and +1 votes from Thorsten and Stephen. Ralph, do you want to upload to the releases repo with the fix for the .sha file, or do you want me to do that?(it is a SHA-512, it's just named incorrectly) -Robert Middleton On Mon, Aug 17, 2020 at 5:47 AM Stephen Webb wrote: > I am using a recent version in production Ubuntu servers, so it is > definitely release ready. > +1 > > On Mon, Aug 17, 2020, 7:27 PM Christian Grobmeier > wrote: > > > Hello, > > > > I am not an expert on c++ or something, but I looked on the content, read > > this thread and think it is safe to release this. However, my hope is > that > > in future more competent cxx devs than me would check it :) > > > > I vote +1 also > > > > Cheers, > > Christian > > > > On Mon, Aug 17, 2020, at 08:08, Ralph Goers wrote: > > > I noticed that the files have she and md5 files. We are not supposed to > > > use either of these any more and only use sha512. I can fix that. > > > > > > I vote +1 > > > > > > Ralph > > > > > > > > > > > > > > > > On Aug 9, 2020, at 10:24 AM, Robert Middleton > > wrote: > > > > > > > > I've run through the release of log4cxx 0.11.0. There's still > > something > > > > strange about how it all works(mostly due to the tooling of shell > > > > script/maven/ant/cmake/autotools). However, I do believe that I > have a > > > > workable release at this point. A quick note on the release: I did > the > > > > 'mvn release:prepare' manually, which is where these artifacts come > > from; > > > > running through the 'mvn release:perform' causes the generated files > > to be > > > > -SNAPSHOT versioned, instead of 0.11.0. This means that the version > > of the > > > > pom.xml in the tag is still 0.11.0-SNAPSHOT, but since maven isn't > > really > > > > used to build I don't think this will be an issue. > > > > > > > > Artifacts uploaded here: > > > > https://dist.apache.org/repos/dist/dev/logging/log4cxx/ > > > > tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2 > > > > > > > > The artifacts are signed, although I still need to send my key to > Matt > > so > > > > he can import it into the logging KEYS file. > > > > > > > > -Robert Middleton > > > > > > > > > > > >
Re: Log4cxx version
I'm working on changes for log4cxx at the moment that involve upgrades to use C++11 features; that would definitely require a major change in the versioning, although the API would be largely the same. Part of the question with that as well is what platforms and compilers are supported, as Thorsten uses a very old compiler. So would it make sense to have two branches for development, the "legacy" 0.XX version and a new 1.XX version that depends on (at least) C++11? -Robert Middleton On Sat, Aug 22, 2020 at 4:30 PM Stephen Webb wrote: > I would completely support that change. > > On Sun, Aug 23, 2020, 3:14 AM Ralph Goers > wrote: > > > In looking at the log4cxx changelog I can’t help notice that the first > > release was 17 years ago. After all these years one would expect that the > > version should have hit 1.0.0 at least 10-15 years ago. Isn’t it time to > > correct that? > > > > Ralph > > >
Re: [VOTE] [log4xx] Release log4cxx 0.11.0
Since we have an actual release now, should we make an announcement email on the gene...@logging.apache.org list? I can write up a blurb, but I'm not sure who can post to that list. I've also updated the tag for the release appropriately(v0.11.0) -Robert Middleton On Sun, Aug 23, 2020 at 1:09 PM Matt Sicker wrote: > The Log4j release-2.x branch is only there because master is > effectively the "release-3.x" branch right now. We forked the branch > to continue 2.x releases while we started making breaking changes in > the 3.x branch (mostly involving moving plugins around; the API is > still the same). > > On Sun, 23 Aug 2020 at 06:41, Thorsten Schöning > wrote: > > > > Guten Tag Ralph Goers, > > am Samstag, 22. August 2020 um 19:04 schrieben Sie: > > > > > I didn’t try to run the build from master. I checked out the > > > release tag. > > > > The site needed to be updated without new releases in the past > > already. I didn't see how this was possible without a branch, so > > simply created one and thought it was a good idea to have one for new > > releases as well. From what I seen, Log4j has a release-2.x branch as > > well. So it might perfectly be that I didn't even consider generating > > the site based on a release tag at all. > > > > > [...]I expected > > > to see the log4cxx release version in the pom on the release tag and > > > it wasn’t there. > > > > This heavily depends on how exactly Robert created the release and > > simply needs to be debugged further. The created scripts should have > > taken care of version numbers, but might not work properly under all > > conditions or whatever. The goal was that "release_prepare" should > > have created a branch and associated tags with correct numbers to base > > releases on. In the end, "changes.xml" wasn't properly updates as well > > for some reason. > > > > So either this needs to be debugged or, as has been discussed already, > > one needs to implement new release-handling without using MVN at all. > > Though I think fixing the existing problems and/or improve docs is the > > easier way forward right now. > > > > > Once a release tag is created no modifications can > > > be made so everything needs to be correct. In Log4j I only create a > > > release branch from the tag if a patch to that release is required. > > > To date, we have never done that. > > > > When I worked last on a release years ago, things were expected to get > > changed or simply didn't work for some reason and that's only easily > > possible with a release branch in my opinion. Manually creating > > branches on each and every RC didn't seem like a good way to me. > > > > Mit freundlichen Grüßen, > > > > Thorsten Schöning > > > > -- > > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > > > Telefon...05151- 9468- 55 > > Fax...05151- 9468- 88 > > Mobil..0178-8 9468- 04 > > > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > > > > > -- > Matt Sicker >
Re: Your project website
Something is funny with logging.apache.org - the links for log4cxx and chainsaw lead to a 404 at the moment. I'm not sure if that's because things are changing or if something else is messed up. I assume this means now that the site will be committed to git instead of svn? -Robert Middleton On Mon, Aug 31, 2020 at 4:15 PM Ralph Goers wrote: > The download link for Log4net is wrong even for the live site. For some > reason it doesn’t seem it was updated during the release process. > > Ralph > > > On Aug 31, 2020, at 11:47 AM, Matt Sicker wrote: > > > > Looks good to me. The download link on the log4net page is broken, but > > everything else looks good. > > > > On Mon, 31 Aug 2020 at 13:31, Ralph Goers <mailto:ralph.go...@dslextreme.com>> wrote: > >> > >> The logging site is now working properly. Please look at > http://logging.staged.apache.org <http://logging.staged.apache.org/> < > http://logging.staged.apache.org/ <http://logging.staged.apache.org/>>. > I will not work on documenting this in Confluence. I know that not all of > the past log4j releases are in git yet. I will be taking care of that soon. > Please let me know if you see any other problems. > >> > >> Ralph > >> > >>> On Aug 30, 2020, at 10:21 PM, Ralph Goers > wrote: > >>> > >>> Another follow-up. After a discussion on Slack with infra I > determined that using GitHub pages isn’t what we want to do. I then > modified the site to work with the normal “pub/sub” that infra supports via > the .asf.yaml files. The documentation for that says it supports having > sub-projects be hosted in separate repos so I followed those instructions. > Unfortunately, those sites are not deploying. I have opened > https://issues.apache.org/jira/browse/INFRA-20792 < > https://issues.apache.org/jira/browse/INFRA-20792> to try to get this > addressed but have not gotten a response to this yet nor to the questions I > asked on Slack. Not surprising since it was a Sunday afternoon. > >>> > >>> I have not documented the process yet since I am not sure I did > everything correctly. > >>> > >>> FWIW, I plan to hold off starting the log4j release process until this > is resolve since trying to commit a new Log4j web site using svn has been > taking at least 30 minutes. My experience in committing the preview site to > my personal GitHub site has shown that it is significantly faster. > >>> > >>> Ralph > >>> > >>>> On Aug 30, 2020, at 11:29 AM, Ralph Goers > wrote: > >>>> > >>>> I have created the logging site in git at > https://github.com/apache/logging-site < > https://github.com/apache/logging-site>. I used jbake to generate the > CMS portion of the site. It is pretty easy. All you have to do is > >>>> > >>>> cd sources > >>>> Make the required changes > >>>> mvn install > >>>> > >>>> You will then have a viewable site in the /docs directory and can > view it by opening docs/index.html in the browser. > >>>> > >>>> I created a .asf.yaml file with the intention of having a preview > site on the asf-staging branch and the live site at master. However, the > instructions for the staging site seem to imply using pypubsub where I am > attempting to use GitHub Pages for the live site. These seem to conflict as > GitHub pages wants the site in the /docs directory while pypubsub seems to > imply it needs to be in the root directory. > >>>> > >>>> I am able to get a site up at https://apache.github.io/logging-site < > https://apache.github.io/logging-site> but it is not being reflected at > https://logging.apache.org <https://logging.apache.org/>. > >>>> > >>>> At this point without clearer instructions from infra I am not sure > where to go to make the site live. > >>>> > >>>> I have started a confluence page to document managing the site but it > seems much easier than using the CMS. > >>>> > >>>> Ralph > >>>> > >>>> > >>>> > >>>>> On Aug 5, 2020, at 5:30 AM, Andrew Wetmore > wrote: > >>>>> > >>>>> Hi: > >>>>> > >>>>> I am part of the Infrastructure team, and am writing to ask whether > your > >>>>> project is still using the Apache CMS for your project website. As > you > >>>>> know, the CMS is
[log4cxx] Tests and auto-builds
Thorsten, do all of the tests pass for you? The reason I ask is because the 'encodingtest' always fails for me. I've gotten the build to run with Github Actions as well, and it always fails there as well, so maybe there's some sort of locale/encoding issue going on? One of the tests currently fails on OSX as well with a segfault, which is the same thing that Ralph indicated a few weeks ago. I have an old mac that I can try to reproduce it on, but if anybody has a chance sometime to help debug this I would appreciate it. -Robert Middleton
Re: [log4cxx] Tests and auto-builds
Figured it out. Apparently when I checked out the code, I indicated that git should convert the \n to \r\n(native line ending on Windows), which causes the tests to fail, as the "known-good" files were subtly changed with their line endings, which caused the (binary) comparison to fail. Fortunately, adding a .gitattributes file fixes this issue. I'll put that up shortly, and then do a bigger PR with the github actions sometime soon, hopefully with the OSX crash fixed. -Robert Middleton On Mon, Sep 7, 2020 at 3:23 AM Thorsten Schöning wrote: > Guten Tag Robert Middleton, > am Sonntag, 6. September 2020 um 20:54 schrieben Sie: > > > Thorsten, do all of the tests pass for you? The reason I ask is because > > the 'encodingtest' always fails for me. I've gotten the build to run > with > > Github Actions as well, and it always fails there as well, so maybe > there's > > some sort of locale/encoding issue going on? > > It works for me when running in Visual Studio with pretty much default > installation, executing "ctest" manually on the old "cmd.exe" and > doing the same with Powershell as well. I just pulled your merged PR > and tested with MASTER after removing all old CMAKE- and VS-related > directories from the project. > > I did NOT customize any string-related options of the CMAKE-build, so > whatever the build defaults to should be used in my environment. > > Additionally, running the tests after building with Embarcadero RAD > Studio 10.2 on "cmd.exe" succeeds as well. One important difference is > that I'm using the wchar_t-API of log4cxx in those cases. > > Running those tests additionall results in lots of output on the > console, which is not the case for "ctest". There's e.g. the following > first line, but nothing more specifically focussing "encodingtest": > > > LC_CTYPE: LC_CTYPE=German_Germany.850 > > [...] > > encodingtest: SUCCESS > > Do you get any useful error output at all somewhere? If not, not using > "ctest" in favour of a plain exe might help debugging. I've uploaded > my built projects somewhere, just if it is of any help: > > https://gofile.io/d/xvkWcK > > The attached mail contains infos about where to place things. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...05151- 9468- 55 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
[log4cxx] Site / Documentation thoughts
I've been working on smart pointer updates for log4cxx, and as part of that effort I would also like to improve the documentation to make sure that it is clear how to use the library. However, this brings up a question as to how we want to create the website. Currently, the main site is generated using maven, and the API documentation is created with Doxygen. I would like to move away from maven for the site generation, as it means that the build procedure for the site is weird(utilizing maven and ant). There are three main options that I see: 1. Continue to utilize maven. This has the advantage of making the site consistent with the other log4___ sites. The disadvantage is that it is(currently) weird to update the site and has issues with releases. 2. Move the entire site to doxygen. This would mean that both the main site and the API documentation would be generated at the same time(which would be convenient), but is generally a lot uglier than the maven site. 3. Put the documentation in the log4cxx-site repo and utilize jekyll for the site(see: https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-JekyllCMS) This has the advantage of allowing custom skins(like the read-the-docs theme:https://github.com/rundocs/jekyll-rtd-theme), but it means that the API documentation would still have to be updated manually and comitted separately, and that the site content would live in a separate repository(as far as I can tell the site can't use a subdirectory from the main repository). Thoughts? -Robert Middleton
Re: [log4cxx] Site / Documentation thoughts
> > 1. Continue to utilize maven. This has the advantage of making the site > > consistent with the other log4___ sites. The disadvantage is that it > > is(currently) weird to update the site and has issues with releases. > > Another advantage is that Maven generates some parts automatically, > like the overview for the lists, changes etc. One doesn't need to > maintain that manually too much, which would be the case when > switching. > The mailing lists and download links are in my mind rather trivial to implement correctly, since they don't exactly change often. The changes still needs to be updated manually, so adding a new entry into a table doesn't seem like a big deal to me. > In any case one needs to have a look at the additional logic > implemented by MVN/ANT to decide if that is needed for the new site as > well. Some of that logic deals with SVN-specifics, but some is related > to updating versions numbers and stuff like that when I remember > correctly. So content-based changes would need some replacement. > The good news is that because cmake can also do text replacements, updating the version number only needs to happen in one place(the cmake files) instead of two or three(pom.xml, cmake files, autotools[if we still support autotools]). > You have worked on GitHub-actions, isn't that something which could be > used to update the API-docs automatically somehow? Those are pretty > different from the site anyway, the content of the latter is to be > maintained manually, while API-docs are designed to be generated > automatically on each commit in theory. Perhaps, although that does require doxygen to be installed. My thought on that though is that you only want to generate API docs on every commit if they are clearly for bleeding-edge uses; generally, people should be using the documentation for the release that they are using. Anyway, I've done some conversion that you can see here: https://rm5248.com/log4cxx/apidocs/index.html I have not converted everything over yet(and there's still some formatting to fix), but at a minimum the main page, changelog, dependencies, and FAQ page should work. The usage page is there, but a lot of the formatting is missing at the moment. The page links on the left can be reordered somehow and given drop-downs like the entries for 'Classes' to match closer with maven. -Robert Middleton
Re: Chainsaw update
Would this be a total removal of the Java deserialization? I ask because I think I've used that before with log4cxx to send log messages to chainsaw. Alternatively, I guess the better question is "should chainsaw support structured log messages input?" I know that there was something about log4j2 supporting GELF a while ago - perhaps that could be a good standard for sending log messages? -Robert Middleton On Sat, Nov 7, 2020 at 12:27 PM Matt Sicker wrote: > > Any use of deserialization over the network (or from untrusted input > sources in general) should use an allowlist of deserializable classes. > That's what we did in log4j2's serialized log event receiver code a > few years ago, for example: > https://github.com/apache/logging-log4j2/commit/5dcc192 > (CVE-2017-5646). > > On Sat, 7 Nov 2020 at 11:12, Scott Deboy wrote: > > > > I assume reverse-connect is still fine (SocketHubAppender/Receiver), > > as Chainsaw is being configured to reach a specific (assumed trusted) > > endpoint, yes? > > > > > > > > On 11/6/20, Scott Deboy wrote: > > > Holy cow. February? > > > > > > I have zero problem with us nuking the object serialization receiver > > > support. I think the vfs receiver is the way to go, still works great. > > > > > > I can remove the code in Chainsaw master. > > > > > > Hope all are well, good to hear from you! > > > > > > Scott > > > > > > On Fri, Nov 6, 2020, 7:53 PM Ralph Goers > > > wrote: > > > > > >> Great to hear from you again! I don’t know if you saw it but there is a > > >> Chainsaw related email on Feb 12 of this year in the private list that > > >> you > > >> should take a look at if you are planning on doing some work on Chainsaw. > > >> > > >> Ralph > > >> > > >> > On Nov 6, 2020, at 5:57 PM, Scott Deboy wrote: > > >> > > > >> > Hey all, > > >> > > > >> > Long time. > > >> > > > >> > I decided to work through the pom ugliness and a couple of swing > > >> > degradation issues in Chainsaw. > > >> > > > >> > I found an ASL2 Mac dmg creation maven plugin, and it works well on my > > >> > Mac, if anyone cares to try it out please do. > > >> > > > >> > Pushing changes to master shortly. > > >> > > > >> > > >> > > >> > > >
Re: Chainsaw update
It looks like it will do that - there is an xmllayout that I haven't paid too much attention to in the past. Part of this is that I really need to update some of the documentation for log4cxx to show the possible options for how to do things. The chainsaw documentation could also be updated as well, but I haven't used it enough to know where to start. -Robert Middleton On Sat, Nov 7, 2020 at 5:49 PM Scott Deboy wrote: > > If I recall correctly, log4cxx supports the log4j xml format over tcp. > > Scott > > On Sat, Nov 7, 2020, 11:49 AM Matt Sicker wrote: > > > It would limit the supported classes to a safe allowlist. Ideally, we > > should be using both standardized logging formats (including de facto > > standards like GELF) as well as developing a proper binary logging > > format proposed a few years ago. > > > > On Sat, 7 Nov 2020 at 13:45, Robert Middleton wrote: > > > > > > Would this be a total removal of the Java deserialization? I ask > > > because I think I've used that before with log4cxx to send log > > > messages to chainsaw. > > > > > > Alternatively, I guess the better question is "should chainsaw support > > > structured log messages input?" I know that there was something about > > > log4j2 supporting GELF a while ago - perhaps that could be a good > > > standard for sending log messages? > > > > > > -Robert Middleton > > > > > > On Sat, Nov 7, 2020 at 12:27 PM Matt Sicker wrote: > > > > > > > > Any use of deserialization over the network (or from untrusted input > > > > sources in general) should use an allowlist of deserializable classes. > > > > That's what we did in log4j2's serialized log event receiver code a > > > > few years ago, for example: > > > > https://github.com/apache/logging-log4j2/commit/5dcc192 > > > > (CVE-2017-5646). > > > > > > > > On Sat, 7 Nov 2020 at 11:12, Scott Deboy > > wrote: > > > > > > > > > > I assume reverse-connect is still fine (SocketHubAppender/Receiver), > > > > > as Chainsaw is being configured to reach a specific (assumed trusted) > > > > > endpoint, yes? > > > > > > > > > > > > > > > > > > > > On 11/6/20, Scott Deboy wrote: > > > > > > Holy cow. February? > > > > > > > > > > > > I have zero problem with us nuking the object serialization > > receiver > > > > > > support. I think the vfs receiver is the way to go, still works > > great. > > > > > > > > > > > > I can remove the code in Chainsaw master. > > > > > > > > > > > > Hope all are well, good to hear from you! > > > > > > > > > > > > Scott > > > > > > > > > > > > On Fri, Nov 6, 2020, 7:53 PM Ralph Goers < > > ralph.go...@dslextreme.com> > > > > > > wrote: > > > > > > > > > > > >> Great to hear from you again! I don’t know if you saw it but > > there is a > > > > > >> Chainsaw related email on Feb 12 of this year in the private list > > that > > > > > >> you > > > > > >> should take a look at if you are planning on doing some work on > > Chainsaw. > > > > > >> > > > > > >> Ralph > > > > > >> > > > > > >> > On Nov 6, 2020, at 5:57 PM, Scott Deboy > > wrote: > > > > > >> > > > > > > >> > Hey all, > > > > > >> > > > > > > >> > Long time. > > > > > >> > > > > > > >> > I decided to work through the pom ugliness and a couple of swing > > > > > >> > degradation issues in Chainsaw. > > > > > >> > > > > > > >> > I found an ASL2 Mac dmg creation maven plugin, and it works > > well on my > > > > > >> > Mac, if anyone cares to try it out please do. > > > > > >> > > > > > > >> > Pushing changes to master shortly. > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > > > >
[General] Logging Wiki
One thing that I've been doing over the holidays is to work more on the log4cxx website migration to Doxygen instead of Maven, and I came across the log4cxx wiki(that seems to have been migrated by infra): https://cwiki.apache.org/confluence/display/LOGGINGLOG4CXX/Home However, it seems to have a lot of spam in it, along with the LOGGINGLOG4J and LOGGINGLOG4PHP wikis. Is there any reason for us to keep the wiki around? They don't seem to be used at all. -Robert Middleton
[log4cxx] Site / Release?
I have ported all of the documentation that is currently built with maven to Markdown to make it possible to generate the single site with Doxygen. You can see the results here: https://rm5248.com/log4cxx/apidocs/ Overall, this seems to be a much easier way to build the site and documentation, since Doxygen is smart enough to link to class members / methods when they appear in the documentation, as opposed to having to put a hardcoded link in the documentation(for example, the current usage xml has a hardcoded link[1], while the markdown version only requires you to write log4cxx::Logger::getRootLogger for the same link to be generated) At this point, I would propose that we do the following: 1. Merge this doxygen site into the main branch to make the website and release creation easier. As part of the documentation update, I also added a target 'dist' that will tar/zip up the sources and sign them at the same time, so it should be much easier than messing around with maven. 2. Do a minor release(0.11.1) that contains the current fixes since 0.11.0(all in master at the moment): * CMake updates to display path to test binaries * OSX segfault * Build without wchar * Mapfilter chaining * Intermediate directory creation for rolling files 3. (optional) remove the maven, ant, autotools files 4. document the release procedure(create a checklist) for the future releases. It is not as automated as maven is, but half of it is just tagging and uploading the generated files to the correct place, so I don't see it being a big issue to do manually. Thoughts? -Robert Middleton [1]: https://github.com/apache/logging-log4cxx/blob/beb771eae0d7e8ee40067a969d8199ab9639982e/src/site/xdoc/usage.xml#L78
Re: [log4cxx] Site / Release?
> I'm somewhat sure to try your changes on my > Windows as well, which might lead to additional changes, which might > make the release with included changes obsolete already. I would be curious to know how things work for you. I think that I've avoided a lot of the C++14 and C++17 features, but some may have snuck in(although from looking at the Embarcadero wiki any recent version should support both). > I wonder if the changes to the docs, the removal of autotools from the > release etc. are a breaking change worth for something like 0.12.0 > anyway. > That's something that I've been thinking of as well - especially if we throw in the std::shared_ptr into the release as well. There are some other things that I would like to see for a big release as well, so perhaps that should be the next goal? Thinking about that, I'm going to make a few JIRA issues for that so I don't forget them. -Robert Middleton On Sat, Dec 26, 2020 at 3:44 PM Thorsten Schöning wrote: > > Guten Tag Robert Middleton, > am Samstag, 26. Dezember 2020 um 19:10 schrieben Sie: > > > Thoughts? > > Do you really think the changes for 0.11.1 are worth it to do a > release or do you only want to have a release testing+documenting the > new release process with? I'm somewhat sure to try your changes on my > Windows as well, which might lead to additional changes, which might > make the release with included changes obsolete already. > > I wonder if the changes to the docs, the removal of autotools from the > release etc. are a breaking change worth for something like 0.12.0 > anyway. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning > AM-SoFT IT-Service - Bitstore Hameln GmbH > > E-Mail: thorsten.schoen...@am-soft.de > Web: http://www.AM-SoFT.de/ > > Telefon: 05151- 9468-55 > Fax: 05151- 9468-88 > Mobil:0178-8 9468-04 > > Firmensitz: Bitstore IT-Consulting, Frankfurter Allee 285, 10317 Berlin > Steuernummer 037/230/30566, HR 27198, Amtsgericht Potsdam Geschäftsführer > Janine Galonska >
Re: [log4cxx] Site / Release?
> I'm using C++Builder 10.2 with the legacy compiler currently, that > surely doesn't support C++14 or 17. So what should I test? Do you want > to create a DRAFT-PR on GitHub or tell me some special branch in your > fork or ...? The DRAFT seems like the easiest approach. Sure, I'll do that in a little bit, although looking at the compiler support for C++11 with the classic compiler I don't think it will work as-is at the moment. Obviously I don't know what your codebase looks like, but I would encourage you to upgrade if possible - there are a number of new features / standard library classes that are in the new standards that are very useful. I also have a separate branch for the documentation updates, which should be ready at this point. -Robert Middleton On Wed, Dec 30, 2020 at 3:03 AM Thorsten Schöning wrote: > > Guten Tag Robert Middleton, > am Dienstag, 29. Dezember 2020 um 23:54 schrieben Sie: > > > I would be curious to know how things work for you. I think that I've > > avoided a lot of the C++14 and C++17 features, but some may have snuck > > in(although from looking at the Embarcadero wiki any recent version > > should support both). > > I'm using C++Builder 10.2 with the legacy compiler currently, that > surely doesn't support C++14 or 17. So what should I test? Do you want > to create a DRAFT-PR on GitHub or tell me some special branch in your > fork or ...? The DRAFT seems like the easiest approach. > > > That's something that I've been thinking of as well - especially if we > > throw in the std::shared_ptr into the release as well. There are some > > other things that I would like to see for a big release as well, so > > perhaps that should be the next goal? Thinking about that, I'm going > > to make a few JIRA issues for that so I don't forget them. > > Next goal with or without 0.11.1? :-) Seems to me like skipping 0.11.1 > is less work in the end and should therefore be preferred? > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning > AM-SoFT IT-Service - Bitstore Hameln GmbH > > E-Mail: thorsten.schoen...@am-soft.de > Web: http://www.AM-SoFT.de/ > > Telefon: 05151- 9468-55 > Fax: 05151- 9468-88 > Mobil:0178-8 9468-04 > > Firmensitz: Bitstore IT-Consulting, Frankfurter Allee 285, 10317 Berlin > Steuernummer 037/230/30566, HR 27198, Amtsgericht Potsdam Geschäftsführer > Janine Galonska >
Re: [meta] What's been going on with log4net, log4cxx, and chainsaw? Request for reports
Some quick notes on the log4cxx side: * Build automation via Github actions makes it easy to test cross-platform(Windows/OSX/Linux) * Website documentation is in the processes of being updated to be more thorough * Website build procedure and general release procedure is now much more streamlined to make it easier to do releases * I have a prototype of using updated standard C++ libraries(C++11 and better), but that hasn't been merged in yet -Robert Middleton On Tue, Feb 9, 2021 at 12:40 PM Matt Sicker wrote: > Over the past year or two, I've been working to include more details > in our quarterly board report about what's been going on in the > community and development. As I'm mostly active in Log4j and some > adjacent code, I'm not always very informed about the development > details in log4net, log4cxx, and chainsaw. While I do try to review > the PRs, emails, and Jira issues that had activity during each > quarter, as I'm not deep in the weeds of those subprojects, I haven't > been able to do them justice in our past reports, especially as these > subprojects experienced new bursts of activity. > > Past board reports from this PMC are at [1] which dates back to the > founding of the project. Interestingly enough, this lack of detailed > reporting for non-log4j subprojects here has been a theme since > forever. I'd love to improve on this by emulating what the Apache > Incubator does by having our subprojects individually report summaries > of their past quarter to the PMC. Then we can report and publish > richer and more detailed summaries of what's going on. > > We have a board report due this week, so I don't really expect that we > can fully bootstrap this idea for that one. Our next board report will > be due in early May 2021, so subproject summaries should be assembled > by the end of April 2021. Would anyone like to volunteer to shepherd > or write up summaries for any particular subproject here? We > particularly need people to help report on the projects mentioned in > the subject. > > [1]: https://whimsy.apache.org/board/minutes/Logging_Services.html >
[log4cxx] Smart pointer implementation
I now have a plausible implementation of log4cxx using smart pointers ready for review. Basic overview of the changes: * Removed all of the AddRef / ReleaseRef functions for the reference counting of objects, since that is now handled by the smart pointer * Added the ability to switch between classes in std and their boost equivalents. This is a little ugly, so it's not ideal but it does seem to work in my testing. * Reworked the casting to act more like C++ than Java * Started converting some code to use atomics instead of mutexes * Refactored some code to allow for reconfiguration in an atomic manner(probably) * Refactored code to not use recursive locks * If your compiler supports C++17, this should work without any external dependencies(apart from APR). Other compilers will require boost. All the tests currently pass, and the good news is that I have tested with asan and it reports no memory leaks at this point! The current version of log4cxx does produce a number of memory leaks, so this is a big improvement. This should also fix issues with people who use asan on their programs, so that they are not getting(probably valid) warnings about memory access in log4cxx on their code. Somebody was asking about this a while ago, but now I can't remember where they were asking about it. PR available here: https://github.com/apache/logging-log4cxx/pull/53 -Robert Middleton
Re: What is going on with Master?
> My guess is that the default file locking level is different
> between JVM's or OS's.
My understanding with Windows is that when you open a file, you have
exclusive access by default. If you try to delete a file that another
application has open(or possibly even your application?), you'll get
an error. On Linux, this isn't the case - unless you explicitly lock
the file, it's available for everybody. You can happily delete a file
on Linux, and the FD that you can read/write to won't become invalid,
even if you can't open it anymore on the filesystem.
-Robert Middleton
On Thu, Feb 18, 2021 at 9:02 PM Tim Perry wrote:
>
> It looks to me like LoggerContext.stop(...) closes the file 'test.log'.
> However, I can't find anything closing 'status.log'. They are configured in
> the same XML file: log4j-filetest.xml
>
> name="XMLConfigTest">
>
> target/test.log
> ...
>
>
> I modified the @Test from FileOutputTest to see if it could delete the log
> files in the test. On windows, neither file gets deleted and in both delete
> attempts I get an IOException with the message "The process cannot access
> the file because it is being used by another process.". On Ubuntu, no
> exception is thrown even though the file is obviously open. See the code
> below.
>
> From this I'm guessing that nothing closes status.log before the
> FileCleaner goes to delete it and that it triggers an exception on Windows,
> but not Linux. My guess is that the default file locking level is different
> between JVM's or OS's. What should be releasing the file handle for
> status.log? LoggerContext?
>
>
> @Test
> @LoggerContextSource("classpath:log4j-filetest.xml")
> public void testConfig() throws IOException {
> final Path logFile = Paths.get("target", "status.log");
> assertTrue(Files.exists(logFile), "Status output file does not
> exist");
> assertTrue(Files.size(logFile) > 0, "File is empty");
>
> try {
> Files.deleteIfExists(logFile);
> fail("Should not have been able to delete " + logFile); // this
> is called on Ubuntu, but not Windows
> } catch (IOException ioe) {
> // this is called for Windows,but not Ubuntu
> System.err.println("THIS SHOULD FAIL: Failed to delete " +
> logFile + ": " + ioe.getMessage());
> }
> final Path testLog = Paths.get("target", "test.log");
> try {
> Files.deleteIfExists(testLog);
> fail("Should not have been able to delete " + testLog); // this
> presumably would be called for Ubuntu, but we failed above.
> } catch (IOException ioe) {
> // this is called for Windows,but not Ubuntu
> System.err.println("THIS SHOULD FAIL: Failed to delete " +
> testLog + ": " + ioe.getMessage());
> }
> }
>
> On Thu, Feb 18, 2021 at 8:48 AM Matt Sicker wrote:
>
> > The gist of what I recall the problem being was that sometimes, a file
> > might still be in use asynchronously for various appenders (e.g.,
> > during rolling, compression, etc.), so the shutdown and removal of
> > temporary files needs to signal that the configuration needs to shut
> > down. It looks like you may have found the missing link as to why this
> > wasn't working properly. In that particular error message, that is
> > some race condition where the temporary file is attempted to be
> > deleted before the configuration stops.
> >
> > On Wed, 17 Feb 2021 at 18:19, Tim Perry wrote:
> > >
> > > Matt,
> > >
> > > The problem is:
> > > target\status.log failed with java.nio.file.FileSystemException:
> > > target\status.log: The process cannot access the file because it is being
> > > used by another process.
> > >
> > > I'm not familiar with how log4j should be releasing the log file to know
> > > where to look. I did notice the afterAll(context) method is never called
> > on
> > > the LoggerContextResolver. Would that explain why the file stays locked?
> > >
> > > Tim
> > >
> > > On Wed, Feb 17, 2021 at 1:49 PM Tim Perry wrote:
> > >
> > > > Yes, I am on windows 10. I'm using Zulu OpenJdk for both Java 8 and 11,
> > > > maven 3.6.3, and a fairly new Eclipse. I'd be happy to help you sort
> > out
> > > > the problem. It will be fun: I haven't
Re: [log4cxx] Smart pointer implementation
> > * If your compiler supports C++17, this should work without any external > > dependencies(apart from APR). Other compilers will require boost. > > Great and obviously a lot of work! Though, I've ran into multiple > problems with my old C++-Builder 10.2 UPD 3 with 32 Bit BCC-compiler. > "boost::atomic" doesn't seem to be available and you are using > language constructs not supported yet, like the following: > > https://stackoverflow.com/a/2795024/2055163 > That was one area that I wasn't sure of, if that would work with your system. The atomics are also not strictly needed, but they provide a convenient lock-free way of setting variables without locking the mutex. I ran into a number of problems with recursive mutex locking, so atomics sidesteps that issue. It's also likely slightly faster, since you don't need to lock and unlock the mutex, although with a modern system it's probably not noticeable. > It seems worth it discussing (again) if such old compilers should be > supported at all anymore or not. I'm not sure if there was a concrete > result in the end sayong only C++11 and newer or alike. > I feel that requiring at least C++11 is perfectly reasonable at this point. The latest release is a good choice for legacy systems, and if needed we can branch from the last release(or from the current master version) to give updates for those platforms. New code is also much easier to implement with newer C++ features, and has the potential for better optimization using move semantics for example. There are a few features that BCC32X doesn't support from C++11, but those should be easy enough to work around(thread_local being an example). Some other compilers took a while to implement the C++11 features, although those should be pretty rare at this point(e.g. MSVC before 2015). Oddly enough, the newer C++ versions seem to have better support in older compilers(e.g. they were implemented by compiler vendors faster than C++11). Requiring C++11 also simplifies some code - as you saw, I left in some std::shared_ptrs around instead of log4cxx::pointer, but the code that detects for C++ wouldn't be needed if we can assume that it already exists(some detection code for C++14/17 features would still be required). -Robert Middleton
Re: [log4cxx] Smart pointer implementation
> > Requiring C++11 also simplifies some code - as you saw, I left in some > > std::shared_ptrs around instead of log4cxx::pointer, but the code that > > detects for C++ wouldn't be needed if we can assume that it already > > exists(some detection code for C++14/17 features would still be > > required). > > So remove the boost-switches for C++11-features entirely and switch > to plain C++ instead? Mixing std::shared_ptr with log4cxx::shared_ptr > doesn't sound like a too good idea to me. It's not too many > std::shared_ptr to change as well. > In terms of leaving the 'std::shared_ptr in', what I meant was that I accidentally left those in when I was doing my conversion. As for removing them completely, it depends on what we want to do. Personally, I don't like typedefs too much(see some thoughts from Linus Torvalds[1] for some more information). it's a bit more typing, but I prefer to do something like: std::shared_ptr logger = instead of log4cxx::LoggerPtr logger = ... since it makes it more obvious to me what the type is. Removing the typedefs would break a lot of existing code that depends on LoggerPtr though, so I would be fine just typedef-ing the pointers with the macros that we have now, but permanently typedef-ing to std::shared_ptr(no utilization of boost fallback behavior). -Robert Middleton [1]: https://yarchive.net/comp/linux/typedefs.html
Re: [log4cxx] Smart pointer implementation
Sounds good. I'll update that in the coming days/weeks - I have a deadline approaching for work, so I may not be able to do much for a bit. I'll also assume that other C++11 features are available(e.g. std::thread, enhanced for loop) moving forward. -Robert Middleton On Tue, Mar 2, 2021 at 9:06 AM Thorsten Schöning wrote: > > Guten Tag Robert Middleton, > am Samstag, 27. Februar 2021 um 17:22 schrieben Sie: > > > As for removing them completely, it depends on what we want to do. > > Personally, I don't like typedefs too much[...] > > I'm the opposite and prefer "log4cxx::LoggerPtr" in general, as in > most cases I don't need to care about the underlying type. > > > Removing the typedefs would break a lot of existing code that depends > > on LoggerPtr though, so I would be fine just typedef-ing the pointers > > with the macros that we have now, but permanently typedef-ing to > > std::shared_ptr(no utilization of boost fallback behavior). > > We are talking about two different things: Yes, let's only use > std::shared_ptr without BOOST. I suggest to not rebase your PR but > keep individual commits with those changes instead to document the > decision and get access to the them if necessary at some point. > > The other aspect you are mentioning is that some code is using > typedefs directly and some is using the macros. So, should the former > be changed as well? > > > class LoggingEvent; > > typedef std::shared_ptr LoggingEventPtr; > > to? > > > class LoggingEvent; > > LOG4CXX_PTR_DEF(LoggingEvent); > > Or leave it as is? In the long term LOG4CXX_PTR_DEF could be replaced > entirely as well. > > OTOH: > > > #define LOG4CXX_PTR_DEF(T) typedef log4cxx::shared_ptr T##Ptr;\ > > typedef log4cxx::weak_ptr T##WeakPtr > > to > > > #define LOG4CXX_PTR_DEF(T) typedef std::shared_ptr T##Ptr;\ > > typedef std::weak_ptr T##WeakPtr > > Because of not using BOOST-fallbacks anymore, additionally removing > the CMAKE-based checks. > > Mit freundlichen Grüßen > > Thorsten Schöning > > -- > AM-SoFT IT-Service - Bitstore Hameln GmbH i.G. > 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 i.G., Brandenburger Str. 7c, 31789 > Hameln > AG Hannover HRB neu - Geschäftsführer: Janine Galonska > > > Für Rückfragen stehe ich Ihnen sehr gerne zur Verfügung. > > Mit freundlichen Grüßen > > Thorsten Schöning > > > Tel: 05151 9468 0 > Fax: 05151 9468 88 > Mobil: > Webseite: https://www.am-soft.de > > AM-Soft IT-Service - Bitstore Hameln GmbH i.G. ist ein Mitglied der Bitstore > Gruppe - Ihr Full-Service-Dienstleister für IT und TK > > AM-Soft IT-Service - Bitstore Hameln GmbH i.G. > Brandenburger Str. 7c > 31789 Hameln > Tel: 05151 9468 0 > > Bitstore IT-Consulting GmbH > Zentrale - Berlin Lichtenberg > Frankfurter Allee 285 > 10317 Berlin > Tel: 030 453 087 80 > > CBS IT-Service - Bitstore Kaulsdorf UG > Tel: 030 453 087 880 1 > > Büro Dallgow-Döberitz > Tel: 03322 507 020 > > Büro Kloster Lehnin > Tel: 033207 566 530 > > PCE IT-Service - Bitstore Darmstadt UG > Darmstadt > Tel: 06151 392 973 0 > > Büro Neuruppin > Tel: 033932 606 090 > > ACI EDV Systemhaus Dresden GmbH > Dresden > Tel: 0351 254 410 > > Das Systemhaus - Bitstore Magdeburg GmbH > Magdeburg > Tel: 0391 636 651 0 > > Allerdata.IT - Bitstore Wittenberg GmbH > Wittenberg > Tel: 03491 876 735 7 > > Büro Liebenwalde > Tel: 033054 810 00 > > HSA - das Büro - Bitstore Altenburg UG > Altenburg > Tel: 0344 784 390 97 > > Bitstore IT – Consulting GmbH > NL Piesteritz > Piesteritz > Tel: 03491 644 868 6 > > Solltec IT-Services - Bitstore Braunschweig UG > Braunschweig > Tel: 0531 206 068 0 > > MF Computer Service - Bitstore Gütersloh GmbH > Gütersloh > Tel: 05245 920 809 3 > > Firmensitz: AM-Soft IT-Service - Bitstore Hameln GmbH i.G. , Brandenburger > Str. 7c , 31789 Hameln > Geschäftsführer Janine Galonska > > > > > >
Re: [log4cxx] Smart pointer implementation
I have just updated my PR with the new changes - at this point, the only class that we use from C++17 is std::shared_mutex, which has an equivalent implementation from boost. Currently, all builds on Github(Ubuntu, OSX, Windows) compile cleanly and pass all tests without boost. What I may do in the future is to add a test for C++11 compatibility, although that probably requires more work as Boost may not always be on the build machines. The builds on Github also feel more reliable(the last two builds have succeeded on all platforms), although that could be something else entirely. -Robert Middleton On Thu, Mar 4, 2021 at 4:04 AM Thorsten Schöning wrote: > > Guten Tag Robert Middleton, > am Donnerstag, 4. März 2021 um 00:46 schrieben Sie: > > > Sounds good. I'll update that in the coming days/weeks - I have a > > deadline approaching for work, so I may not be able to do much for a > > bit. > > If you know to run out of time at some point, consider pushing your > branch UPSTREAM, create a DRAFT-PR or alike and write me what I should > look at. > > Mit freundlichen Grüßen > > Thorsten Schöning > > -- > AM-SoFT IT-Service - Bitstore Hameln GmbH i.G. > 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 i.G., Brandenburger Str. 7c, 31789 > Hameln > AG Hannover HRB neu - Geschäftsführer: Janine Galonska > > > Für Rückfragen stehe ich Ihnen sehr gerne zur Verfügung. > > Mit freundlichen Grüßen > > Thorsten Schöning > > > Tel: 05151 9468 0 > Fax: 05151 9468 88 > Mobil: > Webseite: https://www.am-soft.de > > AM-Soft IT-Service - Bitstore Hameln GmbH i.G. ist ein Mitglied der Bitstore > Gruppe - Ihr Full-Service-Dienstleister für IT und TK > > AM-Soft IT-Service - Bitstore Hameln GmbH i.G. > Brandenburger Str. 7c > 31789 Hameln > Tel: 05151 9468 0 > > Bitstore IT-Consulting GmbH > Zentrale - Berlin Lichtenberg > Frankfurter Allee 285 > 10317 Berlin > Tel: 030 453 087 80 > > CBS IT-Service - Bitstore Kaulsdorf UG > Tel: 030 453 087 880 1 > > Büro Dallgow-Döberitz > Tel: 03322 507 020 > > Büro Kloster Lehnin > Tel: 033207 566 530 > > PCE IT-Service - Bitstore Darmstadt UG > Darmstadt > Tel: 06151 392 973 0 > > Büro Neuruppin > Tel: 033932 606 090 > > ACI EDV Systemhaus Dresden GmbH > Dresden > Tel: 0351 254 410 > > Das Systemhaus - Bitstore Magdeburg GmbH > Magdeburg > Tel: 0391 636 651 0 > > Allerdata.IT - Bitstore Wittenberg GmbH > Wittenberg > Tel: 03491 876 735 7 > > Büro Liebenwalde > Tel: 033054 810 00 > > HSA - das Büro - Bitstore Altenburg UG > Altenburg > Tel: 0344 784 390 97 > > Bitstore IT – Consulting GmbH > NL Piesteritz > Piesteritz > Tel: 03491 644 868 6 > > Solltec IT-Services - Bitstore Braunschweig UG > Braunschweig > Tel: 0531 206 068 0 > > MF Computer Service - Bitstore Gütersloh GmbH > Gütersloh > Tel: 05245 920 809 3 > > Firmensitz: AM-Soft IT-Service - Bitstore Hameln GmbH i.G. , Brandenburger > Str. 7c , 31789 Hameln > Geschäftsführer Janine Galonska > > > > > >
[General] JIRA permissions
I was just looking at some of the JIRA issues for log4cxx, and was going to do some cleanup on issues(marking 0.11.0 as released for example), but then I realized that I don't have the proper permissions on JIRA to do that. I assume that is done by the project lead(currently Christian Grobmier), or is that a PMC-level activity? -Robert Middleton
Re: [General] JIRA permissions
I've switched over to using the rmiddleton account, since that's tied to the ASF LDAP. I think Steven Webb is also a committer, although I haven't seen him around much. -Robert Middleton On Wed, Mar 10, 2021 at 10:47 PM Ralph Goers wrote: > I don’t even see you as a committer in Jira. I see two users for you. Do > you use rm5248, rmiddleton, or both? I see Thorsten there and a lot of > people I’ve never heard of. Is there anyone else I should add? > > > Ralph > > > On Mar 10, 2021, at 7:07 PM, Robert Middleton > wrote: > > > > I was just looking at some of the JIRA issues for log4cxx, and was going > to > > do some cleanup on issues(marking 0.11.0 as released for example), but > then > > I realized that I don't have the proper permissions on JIRA to do that. > I > > assume that is done by the project lead(currently Christian Grobmier), or > > is that a PMC-level activity? > > > > -Robert Middleton > > >
Re: [General] JIRA permissions
Hmm.. that doesn't seem to have changed anything on my side. -Robert Middleton On Thu, Mar 11, 2021 at 10:40 PM Ralph Goers wrote: > Your user is now a committer on the Logcxx project in Jira. There are > multiple users in Jira named Stephen Webb so I will need confirmation of > his userid. I had an email exchange with Stephen last month. He has been > very bush with work. Feel free to reach out to him just to say hi if > nothing else. > > Ralph > > > On Mar 11, 2021, at 4:01 PM, Robert Middleton > wrote: > > > > I've switched over to using the rmiddleton account, since that's tied to > > the ASF LDAP. > > > > I think Steven Webb is also a committer, although I haven't seen him > around > > much. > > > > -Robert Middleton > > > > On Wed, Mar 10, 2021 at 10:47 PM Ralph Goers > > > wrote: > > > >> I don’t even see you as a committer in Jira. I see two users for you. Do > >> you use rm5248, rmiddleton, or both? I see Thorsten there and a lot of > >> people I’ve never heard of. Is there anyone else I should add? > >> > >> > >> Ralph > >> > >>> On Mar 10, 2021, at 7:07 PM, Robert Middleton > >> wrote: > >>> > >>> I was just looking at some of the JIRA issues for log4cxx, and was > going > >> to > >>> do some cleanup on issues(marking 0.11.0 as released for example), but > >> then > >>> I realized that I don't have the proper permissions on JIRA to do that. > >> I > >>> assume that is done by the project lead(currently Christian Grobmier), > or > >>> is that a PMC-level activity? > >>> > >>> -Robert Middleton > >> > >> > >> > > >
Re: [Discuss] EOL of Java 6 and 7
According to Adopt OpenJDK[1], version 8 will be supported until at least May 2026, while Java 11 will be supported until at least October 2024. That obviously doesn't affect Java 7, but it may affect any plans as to when Java 8 will be dropped. -Robert Middleton [1]: https://adoptopenjdk.net/support.html On Sat, Mar 13, 2021 at 7:48 PM Gary Gregory wrote: > On Sat, Mar 13, 2021 at 7:20 PM Ralph Goers > wrote: > > > > InfoQ had an article from Sept 2020 indicating Java 11 was about 20% of > production deployments and Java 8 had the rest. So release 2.x is going to > be around a while. > > I'm fine with that. We have users that are cranking along on Java 8 > set ups, that's not going to change for a while I guess ... until the > next panic over licensing, EOL, or somesuch. > > Gary > > > > > Ralph > > > > > On Mar 13, 2021, at 5:17 PM, Ralph Goers > wrote: > > > > > > The JRebel report from January shows that about 69% of Java users are > using Java 8. Java 11 is at about 36%. The only problem here is that Java > 12 or newer is 12% and Java 7 or older is 15% That totals 132% so I really > have no idea what to make of these numbers. > > > > > > Ralph > > > > > >> On Mar 13, 2021, at 4:53 PM, Gary Gregory > wrote: > > >> > > >> That's fine with me. > > >> > > >> FWIW: At work, what is holding us back moving from Java 8 to 11 is > > >> that IBM does not support a production level Java 11 on the i/Series > > >> yet (EA only IIRC). > > >> > > >> Gary > > >> > > >> On Sat, Mar 13, 2021 at 5:28 PM Ralph Goers < > ralph.go...@dslextreme.com> wrote: > > >>> > > >>> Log4j 2.3 was the last Log4j 2 release to support Java 6. We have > made no patches to it since it was released in 2015. As I recall Java 6 > was already EOL on public updates by the time we moved to Java 7. As near > as I can tell Oracle’s extended support for Java 6 ended in December 2018. > Maven Central indicates about 1.7% of all log4j-api downloads are for > release 2.3 and prior, including the alpha and beta releases. > > >>> > > >>> Log4j 2.12.1 was the last Log4j 2 release to support Java 7. Java 7 > public updates ended in April 2015, premier support ended in Mar 2019, and > extended support ends in July 2022. Maven Central statistics show that > Log4j 2 1.12.1 is our 3rd most popular version of log4j-api and about 12% > of downloads. Of course, if is far more likely that users of Log4j 2.12.1 > are running Java 8 than Java 7 since the latest JRebel report indicates > that only 7% of Java users are using Java 7 or older. > > >>> > > >>> > > >>> I suspect that if I tried to do a patch release to 2.3 today it > would be difficult. I still have Java 6 present on my computer, but that > computer has probably been upgraded twice since 2.3 was released. > > >>> > > >>> I am proposing that we publish that we no longer support Java 6 or > Java 7. If we want to continue to support Java 7 we should at least > indicate when we will drop support. > > >>> > > >>> Thoughts? > > >>> > > >>> Ralph > > >> > > > > > > > > > > > > > >
[log4cxx] ABI checks
As part of my goal of making log4cxx ABI compatible, I've added a new check to the Github actions that will run automatically to see if there are any ABI changes. Currently it's just sitting in a PR( https://github.com/apache/logging-log4cxx/pull/58) if anybody wants to check it out before I merge it. If you go to the abi-compatibility action, there is now an artifact to download that has an HTML file with the ABI compatibility report in it - it has a few warnings at the moment, likely because the version of g++ that I compiled with is different from the one that Ubuntu is using. On a somewhat related note, since we are now making use of the new C++11 features(shared_ptr, mutex, etc), what should the goal of our next release be and when would it make sense? I ask because we could go for the next release being ABI-compatible, although it would be rather tedious to do that - there's a lot of code that would need to be changed, but it's not particularly hard. -Robert Middleton
Re: [log4cxx] ABI checks
> > As part of my goal of making log4cxx ABI compatible, I've added a new check > > to the Github actions that will run automatically to see if there are any > > ABI changes. Currently it's just sitting in a PR( > > https://github.com/apache/logging-log4cxx/pull/58) if anybody wants to > > check it out before I merge it.[...] > > Just to be sure I understand correctly: There's always an "abi.dump" > in the repo as how the ABI should look like. For each new commit the > GitHub action generates "new-abi.dump" to compare against and fails in > case of differences. If the ABI should be changed by purpose, the > action can be made aware by simply committing a newer version of > "abi.dump" as part of a change/PR. > > Correct? > Yes, that is correct. > > On a somewhat related note, since we are now making use of the new C++11 > > features(shared_ptr, mutex, etc), what should the goal of our next release > > be and when would it make sense? I ask because we could go for the next > > release being ABI-compatible, although it would be rather tedious to do > > that - there's a lot of code that would need to be changed, but it's not > > particularly hard. > > This reads to me like if you want to release pretty soon what is > available now? If so, I totally agree, otherwise I would be fine with > as well. ;-) > > Everything you have changed right now should make the lib more stable. > Just think of the memory leaks and thread-issues which should be fixed > now. OTOH, it has the risk of breaking things for users with older > toolchains like me. THOUGH, even then it's good to make people aware > of that early with a release right now. So make a 0.12.0 now, so that > fixes mostly related to C++11 etc. can be published as 0.12.X and keep > ABI-compatibility for 0.13 or alike. > That sounds like a good idea to me. I'll start doing that in a week or two, I think there's still some documentation that I want to make sure is updated. That should also give it a period of time to allow for any new bug(s) to be reported. I have some applications on my side as well that I'll compile with and make sure that they still work correctly. -Robert Middleton
[log4cxx] Release Prep
Before I go and do a release of log4cxx, are there any issues that may need to be taken care of before the next release? Otherwise, if there are no objections, I'll call for a release vote here shortly for version 0.12.0. -Robert Middleton
Re: [log4cxx] Release Prep
> Using ${CMAKE_SOURCE_DIR} instead of a relative path creates a problem
> when including the log4cxx root directory from a higher level
> CMakeLists.txt. CMAKE_SOURCE_DIR is (inconveniently) set where the top-most
> CMakeLists.txt file resides.
>
> You are using ${CMAKE_SOURCE_DIR} in src/main /include and src/main/cpp.
Apparently also in the Doxyfile.in as well - do you know what the
correct variable should be? It looks like we may want to use
PROJECT_SOURCE_DIR instead, if we can't do absolute paths. Or maybe
we just need something like LOG4CXX_SOURCE_DIR?
-Robert Middleton
Re: [log4cxx] Release Prep
Also, question for Thorsten: are you comfortable closing PR #22 at
this point? There's been no activity on it for a year at this point,
and it seems like the resolution we came up with was "don't do
anything".
-Robert Middleton
On Wed, Apr 14, 2021 at 9:27 PM Robert Middleton
wrote:
>
> > Using ${CMAKE_SOURCE_DIR} instead of a relative path creates a problem
> > when including the log4cxx root directory from a higher level
> > CMakeLists.txt. CMAKE_SOURCE_DIR is (inconveniently) set where the top-most
> > CMakeLists.txt file resides.
> >
> > You are using ${CMAKE_SOURCE_DIR} in src/main /include and src/main/cpp.
>
> Apparently also in the Doxyfile.in as well - do you know what the
> correct variable should be? It looks like we may want to use
> PROJECT_SOURCE_DIR instead, if we can't do absolute paths. Or maybe
> we just need something like LOG4CXX_SOURCE_DIR?
>
> -Robert Middleton
Re: [log4cxx] Release Prep
If you're able to test the PR that I just did, that would be helpful:
https://github.com/apache/logging-log4cxx/pull/63
All of the tests pass so it's probably good, but an extra set of eyes
is helpful.
-Robert Middleton
On Thu, Apr 15, 2021 at 4:32 AM Stephen Webb wrote:
>
> > Or maybe we just need something like LOG4CXX_SOURCE_DIR?
>
> yes, I like that idea - something we control.
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Thu, Apr 15, 2021 at 11:28 AM Robert Middleton <
> robert.middle...@rm5248.com> wrote:
>
> > > Using ${CMAKE_SOURCE_DIR} instead of a relative path creates a problem
> > > when including the log4cxx root directory from a higher level
> > > CMakeLists.txt. CMAKE_SOURCE_DIR is (inconveniently) set where the
> > top-most
> > > CMakeLists.txt file resides.
> > >
> > > You are using ${CMAKE_SOURCE_DIR} in src/main /include and src/main/cpp.
> >
> > Apparently also in the Doxyfile.in as well - do you know what the
> > correct variable should be? It looks like we may want to use
> > PROJECT_SOURCE_DIR instead, if we can't do absolute paths. Or maybe
> > we just need something like LOG4CXX_SOURCE_DIR?
> >
> > -Robert Middleton
> >
[log4cxx] XML configuration with compression
Does anybody happen to have a known good XML file for rollover with compression? I'm working on LOGCXX-523 and I'm trying to configure the XML file to gzip the files when rolling over, but I can't get it to work. It seems that the only configuration that we have in the tests programmatically configures it, so I'm not sure if it actually works when it's configured from the file or not. -Robrt Middleton
Re: [log4cxx] XML configuration with compression
So there is apparently a difference between having your config appender being org.apache.log4j.rolling.RollingFileAppender vs. org.apache.log4j.RollingFileAppender. The second one(which doesn't have the extra 'rolling' in its namespace) will only be activated if you have /exactly/ the following in your config file: This loads the obsolete rolling file appender for log4cxx, which doesn't seem to work properly. It certainly doesn't work correctly for the test that I've been trying to do. As the name would suggest, it's probably obsolete and we should think about removing it post 0.12. The quirky thing about this is that because log4cxx doesn't actually care about the Java class name, the following lines in the config file are all equivalent: -Robert Middleton On Sat, Apr 17, 2021 at 4:27 AM Thorsten Schöning wrote: > > Guten Tag Robert Middleton, > am Samstag, 17. April 2021 um 04:31 schrieben Sie: > > > Does anybody happen to have a known good XML file for rollover with > > compression? I'm working on LOGCXX-523 and I'm trying to configure > > the XML file to gzip the files when rolling over, but I can't get it > > to work.[...] > > What did you try so for? RollingFileAppender has an example > documented, if that doesn't work, that should be changed as well. > > https://svn.apache.org/repos/asf/logging/site/trunk/docs/log4cxx/apidocs/classlog4cxx_1_1rolling_1_1_rolling_file_appender.html > > Might just have been copied&pasted from log4j in the past: > > https://stackoverflow.com/questions/19616641/log4j-configurations-with-daily-rolling-gzip-and-max-backup-files > > Mit freundlichen Grüßen > > Thorsten Schöning > > -- > AM-SoFT IT-Service - Bitstore Hameln GmbH i.G. > 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 i.G., Brandenburger Str. 7c, 31789 > Hameln > AG Hannover HRB neu - Geschäftsführer: Janine Galonska > > > Für Rückfragen stehe ich Ihnen sehr gerne zur Verfügung. > > Mit freundlichen Grüßen > > Thorsten Schöning > > > Tel: 05151 9468 0 > Fax: 05151 9468 88 > Mobil: > Webseite: https://www.am-soft.de > > AM-Soft IT-Service - Bitstore Hameln GmbH i.G. ist ein Mitglied der Bitstore > Gruppe - Ihr Full-Service-Dienstleister für IT und TK > > AM-Soft IT-Service - Bitstore Hameln GmbH i.G. > Brandenburger Str. 7c > 31789 Hameln > Tel: 05151 9468 0 > > Bitstore IT-Consulting GmbH > Zentrale - Berlin Lichtenberg > Frankfurter Allee 285 > 10317 Berlin > Tel: 030 453 087 80 > > CBS IT-Service - Bitstore Kaulsdorf UG > Tel: 030 453 087 880 1 > > Büro Dallgow-Döberitz > Tel: 03322 507 020 > > Büro Kloster Lehnin > Tel: 033207 566 530 > > PCE IT-Service - Bitstore Darmstadt UG > Darmstadt > Tel: 06151 392 973 0 > > Büro Neuruppin > Tel: 033932 606 090 > > ACI EDV Systemhaus - Bitstore Dresden GmbH > Dresden > Tel: 0351 254 410 > > Das Systemhaus - Bitstore Magdeburg GmbH > Magdeburg > Tel: 0391 636 651 0 > > Allerdata.IT - Bitstore Wittenberg GmbH > Wittenberg > Tel: 03491 876 735 7 > > Büro Liebenwalde > Tel: 033054 810 00 > > HSA - das Büro - Bitstore Altenburg UG > Altenburg > Tel: 0344 784 390 97 > > Bitstore IT – Consulting GmbH > NL Piesteritz > Piesteritz > Tel: 03491 644 868 6 > > Solltec IT-Services - Bitstore Braunschweig UG > Braunschweig > Tel: 0531 206 068 0 > > MF Computer Service - Bitstore Gütersloh GmbH > Gütersloh > Tel: 05245 920 809 3 > > Firmensitz: AM-Soft IT-Service - Bitstore Hameln GmbH i.G. , Brandenburger > Str. 7c , 31789 Hameln > Geschäftsführer Janine Galonska > > > > > >
Re: [log4cxx] XML configuration with compression
> > The quirky thing about this is that because log4cxx doesn't actually > > care about the Java class name, the following lines in the config file > > are all equivalent: > > > class="org.apache.log4j.rolling.RollingFileAppender"> > > > > > > I don't get your point: The second and third line could be used to > address the wrong RollingFileAppender currently, the obsolete one? > Looking at the class loader, the absolute name is preferred, so NOT > using those names for appenders could easily be considered a user > error or docs would need to be made more clear. > All of those configuration lines load the correct version of RollingFileAppender. The meta-data about the class(in the DECLARE_LOG4CXX_OBJECT macro) contains the class name. For the non-obsolete version, the class name is simply "RollingFileAppender". The obsolete version is defined here: https://github.com/apache/logging-log4cxx/blob/79352bd0160866d06b61414f2dc83d1f71b44335/src/main/cpp/obsoleterollingfileappender.cpp#L40 If the exact class name isn't found, then the code simply looks at everything beyond the last '.' to load the class: https://github.com/apache/logging-log4cxx/blob/79352bd0160866d06b61414f2dc83d1f71b44335/src/main/cpp/class.cpp#L123 Since all of the examples that I gave end in 'RollingFileAppender' and they don't equal "org.apache.log4j.RollingFileAppender", the correct RollingFileAppender is used. -Robert Middleton
Re: [log4cxx] Release Prep
Yes, adding a note about casting would be a good idea. Note that there is a log4cxx::cast function that should handle this for you - I believe that this is more reliable than using dynamic_cast, especially across DLL boundaries. It should also properly do the shared_ptr portion(so that you can have shared_ptrs of different types pointing at the same object). -Robert Middleton On Wed, Apr 21, 2021 at 2:52 AM Stephen Webb wrote: > Hi Robert, > > I suggest adding the following to 'change-report-gh.md' > > > Migrating from 0.11.0 > - > > Code changes are required for log4cxx pointer downcasting. The automatic > cast performed by the log4cxx 0.11 smart pointer assign operator is no > longer supported. > > For example: > > log4cxx::FileAppenderPtr fileAppender = > log4cxx::Logger::getRootLogger()->getAppender(logAppender); > if (fileAppender) > fileAppender->getFile(); > > would become: > > auto appender = > log4cxx::Logger::getRootLogger()->getAppender(logAppender); > if (auto fileAppender = > dynamic_cast(appender.get())) > result = fileAppender->getFile(); > > > On Tue, Apr 13, 2021 at 12:09 PM Robert Middleton > wrote: > > > Before I go and do a release of log4cxx, are there any issues that may > > need to be taken care of before the next release? Otherwise, if there > > are no objections, I'll call for a release vote here shortly for > > version 0.12.0. > > > > -Robert Middleton > > >
Re: [log4cxx] Release Prep
As long as the classes that you are trying to cast to/from descend from log4cxx::Object, the cast should work fine. The aliasing constructor for std::shared_ptr means that both shared_ptrs point at the same control block for the shared pointer, so the object is the same; I'll add some notes about that. -Robert Middleton On Thu, Apr 22, 2021 at 3:46 AM Stephen Webb wrote: > Yes, your fancy new cast function looks like a better approach. > > Should the note mention it uses the aliasing constructor std::shared_ptr or > is it always going to be safe with log4cxx::Object pointers? > > On Thu, Apr 22, 2021 at 7:54 AM Robert Middleton > wrote: > > > Yes, adding a note about casting would be a good idea. > > > > Note that there is a log4cxx::cast function that should handle this for > you > > - I believe that this is more reliable than using dynamic_cast, > especially > > across DLL boundaries. It should also properly do the shared_ptr > > portion(so that you can have shared_ptrs of different types pointing at > the > > same object). > > > > -Robert Middleton > > > > On Wed, Apr 21, 2021 at 2:52 AM Stephen Webb > wrote: > > > > > Hi Robert, > > > > > > I suggest adding the following to 'change-report-gh.md' > > > > > > > > > Migrating from 0.11.0 > > > - > > > > > > Code changes are required for log4cxx pointer downcasting. The > automatic > > > cast performed by the log4cxx 0.11 smart pointer assign operator is no > > > longer supported. > > > > > > For example: > > > > > > log4cxx::FileAppenderPtr fileAppender = > > > log4cxx::Logger::getRootLogger()->getAppender(logAppender); > > > if (fileAppender) > > > fileAppender->getFile(); > > > > > > would become: > > > > > > auto appender = > > > log4cxx::Logger::getRootLogger()->getAppender(logAppender); > > > if (auto fileAppender = > > > dynamic_cast(appender.get())) > > > result = fileAppender->getFile(); > > > > > > > > > On Tue, Apr 13, 2021 at 12:09 PM Robert Middleton < > rmiddle...@apache.org > > > > > > wrote: > > > > > > > Before I go and do a release of log4cxx, are there any issues that > may > > > > need to be taken care of before the next release? Otherwise, if > there > > > > are no objections, I'll call for a release vote here shortly for > > > > version 0.12.0. > > > > > > > > -Robert Middleton > > > > > > > > > >
[VOTE] Release log4cxx 0.12.0
This is a vote to release log4cxx 0.12.0. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... As we had some issues with people building and running last time, this vote will remain open for one week(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/12338615 Tag: For a new copy do "git clone https://github.com/apache/logging-log4cxx.git"; and then "git checkout tags/v0.12.0-RC1" For an existing working copy, do "git pull" and then "git checkout tags/v012.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: [VOTE] Release log4cxx 0.12.0
As reported on JIRA earlier today: https://issues.apache.org/jira/browse/LOGCXX-526 This won't be hard to fix, so I'm going to go and add the correct include files here shortly and do an RC2 if that sounds good? That'll give me a chance to also fix the two minor issues from Thorsten. -Robert Middleton On Tue, Apr 27, 2021 at 10:32 PM Stephen Webb wrote: > +1 > > I built and used it with the systems I maintain and everything looks good. > > On Tue, Apr 27, 2021 at 11:44 AM Robert Middleton > wrote: > > > This is a vote to release log4cxx 0.12.0. > > > > Please download, test, and cast your votes on the log4j developers list. > > [] +1, release the artifacts > > [] -1, don't release because... > > > > As we had some issues with people building and running last time, this > vote > > will remain open for one week(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/12338615 > > > > Tag: > > For a new copy do "git clone > https://github.com/apache/logging-log4cxx.git > > " > > and then "git checkout tags/v0.12.0-RC1" > > For an existing working copy, do "git pull" and then "git checkout > > tags/v012.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 > > >
[VOTE] Release log4cxx 0.12.0-RC2
This is a vote to release log4cxx 0.12.0. This is RC2. This vote supersedes the original vote. Please download, test, and cast your votes on the log4j developers list. [] +1, release the artifacts [] -1, don't release because... As we had some issues with people building and running last time, this vote will remain open for one week(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/12338615 Tag: For a new copy do "git clone https://github.com/apache/logging-log4cxx.git"; and then "git checkout tags/v0.12.0-RC2" For an existing working copy, do "git pull" and then "git checkout tags/v012.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). Changes since RC1: * Fixed build with GCC-11 * Removed ABI file from release tarball, since that is really not interesting to most end-users * Ignored a few files that were incorrectly added to release tarball(*.swp, CMakeLists.txt.user) * Added release date on changelog(now 2021-05-01) -Robert Middleton
Re: [LOG4CXX] Release log4cxx 0.12.0-RC2
I honestly don't know how important these warnings are - I don't do much on Windows. As far as I'm aware the declspec should be #defined correctly, could that have something to do with it? -Robert Middleton On Mon, May 3, 2021 at 2:20 PM Patrick Mills wrote: > > Anyone else building DLLs in Windows environment? > > I'm seeing lots of warnings in VS 2019. Wondering if these should be > disabled or a note added about ignoring them. > > Or perhaps I'm doing something wrong in my cmake build: > > cmake -DCMAKE_GENERATOR_PLATFORM=x64 -DCMAKE_BUILD_TYPE=Release > -DCMAKE_INSTALL_PREFIX="" -DBUILD_SHARED_LIBS=ON > -DAPR_STATIC=ON -DAPU_STATIC=ON -DLOG4CXX_INSTALL_PDB=ON > -DBUILD_TESTING=OFF .. > cmake --build . --config RelWithDebInfo --target install > > Here are the warnings I'm seeing: > > Tons of these relating to std::xyz which I believe can mostly be safely > ignored as long as the compiler versions are the same. ( > https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4251?view=msvc-160 > ) > apache-log4cxx-0.12.0\src\main\include\log4cxx/helpers/loglog.h(50,19): > warning C4251: 'log4cxx::helpers::LogLog::mutex': class 'std::mutex' needs > to have dll-interface to be used by clients of class > 'log4cxx::helpers::LogLog' > [apache-log4cxx-0.12.0\CFS_Build\src\main\cpp\log4cxx.vcxproj] > > apache-log4cxx-0.12.0\src\main\include\log4cxx/rolling/timebasedrollingpolicy.h(291,1): > warning C4250: 'log4cxx::rolling::TimeBasedRollingPolicy': inherits > 'log4cxx::rolling::RollingPolicyBase::log4cxx::rolling::RollingPolicyBase::setOption' > via dominance [apache-log4cxx-0.12.0\CFS_Build\src\main\cpp\log4cxx.vcxproj] > > Lots of these too... > apache-log4cxx-0.12.0\CFS_Build\src\main\include\log4cxx/private/log4cxx_private.h(67,1): > warning C4005: 'LOG4CXX_MEMSET_IOS_BASE': macro redefinition > [apache-log4cxx-0.12.0\CFS_Build\src\main\cpp\log4cxx.vcxproj] > > apache-log4cxx-0.12.0\src\main\cpp\charsetencoder.cpp(472,16): warning > C4244: '=': conversion from 'const wchar_t' to 'char', possible loss of > data [apache-log4cxx-0.12.0\CFS_Build\src\main\cpp\log4cxx.vcxproj] > apache-log4cxx-0.12.0\src\main\cpp\nteventlogappender.cpp(246,56): warning > C4267: 'argument': conversion from 'size_t' to 'DWORD', possible loss of > data [apache-log4cxx-0.12.0\CFS_Build\src\main\cpp\log4cxx.vcxproj] > apache-log4cxx-0.12.0\src\main\cpp\nteventlogappender.cpp(248,56): warning > C4267: 'argument': conversion from 'size_t' to 'DWORD', possible loss of > data [apache-log4cxx-0.12.0\CFS_Build\src\main\cpp\log4cxx.vcxproj] > apache-log4cxx-0.12.0\src\main\cpp\rollingpolicybase.cpp(117,39): warning > C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of > data [apache-log4cxx-0.12.0\CFS_Build\src\main\cpp\log4cxx.vcxproj] > apache-log4cxx-0.12.0\src\main\cpp\simpledateformat.cpp(143,7): warning > C4244: 'argument': conversion from 'wchar_t' to 'char', possible loss of > data [apache-log4cxx-0.12.0\CFS_Build\src\main\cpp\log4cxx.vcxproj] > apache-log4cxx-0.12.0\src\main\cpp\socket.cpp(124,26): warning C4267: '+=': > conversion from 'size_t' to 'int', possible loss of data > [apache-log4cxx-0.12.0\CFS_Build\src\main\cpp\log4cxx.vcxproj] > apache-log4cxx-0.12.0\src\main\cpp\syslogwriter.cpp(64,29): warning C4267: > 'argument': conversion from 'size_t' to 'int', possible loss of data > [apache-log4cxx-0.12.0\CFS_Build\src\main\cpp\log4cxx.vcxproj] > apache-log4cxx-0.12.0\src\main\cpp\transcoder.cpp(380,17): warning C4244: > 'argument': conversion from 'const wchar_t' to 'const _Elem', possible loss > of data [apache-log4cxx-0.12.0\CFS_Build\src\main\cpp\log4cxx.vcxproj]
Re: [VOTE] Release log4cxx 0.12.0-RC2
I've updated the NOTICE file in git, so it will be correct for the next release. :) Otherwise everything still looks good to me, so adding my +1 now. -Robert Middleton On Mon, May 3, 2021 at 2:02 PM Matt Sicker wrote: > > If you don't feel the NOTICE file is a problem, then please make sure > to update it in git for the next release. :) > > Signatures checked out, source archives look good. +1 > > On Mon, 3 May 2021 at 10:54, Thorsten Schöning wrote: > > > > Guten Tag Robert Middleton, > > am Samstag, 1. Mai 2021 um 23:07 schrieben Sie: > > > > > Please download, test, and cast your votes on the log4j developers list. > > > > +1 > > > > The wrong NOTICE can be fixed later in my opinion, it has been wrong > > for multiple releases already. > > > > Mit freundlichen Grüßen > > > > Thorsten Schöning > > > > -- > > AM-SoFT IT-Service - Bitstore Hameln GmbH i.G. > > 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 i.G., Brandenburger Str. 7c, > > 31789 Hameln > > AG Hannover HRB neu - Geschäftsführer: Janine Galonska > > > > > > Für Rückfragen stehe ich Ihnen sehr gerne zur Verfügung. > > > > Mit freundlichen Grüßen > > > > Thorsten Schöning > > > > > > Tel: 05151 9468 0 > > Fax: 05151 9468 88 > > Mobil: > > Webseite: https://www.am-soft.de > > > > AM-Soft IT-Service - Bitstore Hameln GmbH i.G. ist ein Mitglied der > > Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK > > > > AM-Soft IT-Service - Bitstore Hameln GmbH i.G. > > Brandenburger Str. 7c > > 31789 Hameln > > Tel: 05151 9468 0 > > > > Bitstore IT-Consulting GmbH > > Zentrale - Berlin Lichtenberg > > Frankfurter Allee 285 > > 10317 Berlin > > Tel: 030 453 087 80 > > > > CBS IT-Service - Bitstore Kaulsdorf UG > > Tel: 030 453 087 880 1 > > > > Büro Dallgow-Döberitz > > Tel: 03322 507 020 > > > > Büro Kloster Lehnin > > Tel: 033207 566 530 > > > > PCE IT-Service - Bitstore Darmstadt UG > > Darmstadt > > Tel: 06151 392 973 0 > > > > Büro Neuruppin > > Tel: 033932 606 090 > > > > ACI EDV Systemhaus - Bitstore Dresden GmbH > > Dresden > > Tel: 0351 254 410 > > > > Das Systemhaus - Bitstore Magdeburg GmbH > > Magdeburg > > Tel: 0391 636 651 0 > > > > Allerdata.IT - Bitstore Wittenberg GmbH > > Wittenberg > > Tel: 03491 876 735 7 > > > > Büro Liebenwalde > > Tel: 033054 810 00 > > > > HSA - das Büro - Bitstore Altenburg UG > > Altenburg > > Tel: 0344 784 390 97 > > > > Bitstore IT – Consulting GmbH > > NL Piesteritz > > Piesteritz > > Tel: 03491 644 868 6 > > > > Solltec IT-Services - Bitstore Braunschweig UG > > Braunschweig > > Tel: 0531 206 068 0 > > > > MF Computer Service - Bitstore Gütersloh GmbH > > Gütersloh > > Tel: 05245 920 809 3 > > > > Firmensitz: AM-Soft IT-Service - Bitstore Hameln GmbH i.G. , Brandenburger > > Str. 7c , 31789 Hameln > > Geschäftsführer Janine Galonska > > > > > > > > > > > >
[Chainsaw] Minor fixes
I've been doing some messing around with chainsaw the past few days, and I've fixed a few minor issues(and put in some PRs for them) - does somebody(Scott?) want to take a look at them? I can merge stuff if needed, but I'm not sure if somebody else prefers to take some lead on chainsaw. Side note, the Jenkins build fails for chainsaw at the moment - I'm not sure who takes care of that either. -Robert Middleton
Re: [Chainsaw] Minor fixes
> > On Sat, May 8, 2021, 11:19 AM Matt Sicker wrote: > > > As for committing the repository, > > > you are a committer and can do so. We do commit-then-review here which > > > allows people to asynchronously review changes with lazy consensus. Sounds fine to me - I just didn't want to go and start to make a bunch of changes randomly, especially since chainsaw is not my primary focus. > On Sat, 8 May 2021 at 13:22, Scott Deboy wrote: > > > > Chainsaw Mac integration leverages java9 features now (Mac prefs menu > > integration). I can review merge requests. Those changes cause it to crash on Linux at least, due to it not supporting the integration, so I wanted to fix that. There are also a few UI changes so that it will let you see what you're typing. -Robert Middleton On Sat, May 8, 2021 at 2:30 PM Matt Sicker wrote: > > Looks like Jenkins is under maintenance at the moment. Will check if > my recent changes fixed that build when it's up again. > > On Sat, 8 May 2021 at 13:22, Scott Deboy wrote: > > > > Chainsaw Mac integration leverages java9 features now (Mac prefs menu > > integration). I can review merge requests. > > > > On Sat, May 8, 2021, 11:19 AM Matt Sicker wrote: > > > > > It appears that Chainsaw updated its minimum Java version to 9. I'll > > > get that fixed in the Jenkins build. As for committing the repository, > > > you are a committer and can do so. We do commit-then-review here which > > > allows people to asynchronously review changes with lazy consensus. > > > > > > On Fri, 7 May 2021 at 21:45, Robert Middleton > > > wrote: > > > > > > > > I've been doing some messing around with chainsaw the past few days, > > > > and I've fixed a few minor issues(and put in some PRs for them) - does > > > > somebody(Scott?) want to take a look at them? I can merge stuff if > > > > needed, but I'm not sure if somebody else prefers to take some lead on > > > > chainsaw. > > > > > > > > Side note, the Jenkins build fails for chainsaw at the moment - I'm > > > > not sure who takes care of that either. > > > > > > > > -Robert Middleton > > >
Re: [VOTE] Release log4cxx 0.12.0-RC2
As a reminder, this vote is still outstanding. -Robert Middleton On Tue, May 4, 2021 at 7:10 PM Robert Middleton wrote: > > I've updated the NOTICE file in git, so it will be correct for the > next release. :) > > Otherwise everything still looks good to me, so adding my +1 now. > > -Robert Middleton > > On Mon, May 3, 2021 at 2:02 PM Matt Sicker wrote: > > > > If you don't feel the NOTICE file is a problem, then please make sure > > to update it in git for the next release. :) > > > > Signatures checked out, source archives look good. +1 > > > > On Mon, 3 May 2021 at 10:54, Thorsten Schöning > > wrote: > > > > > > Guten Tag Robert Middleton, > > > am Samstag, 1. Mai 2021 um 23:07 schrieben Sie: > > > > > > > Please download, test, and cast your votes on the log4j developers list. > > > > > > +1 > > > > > > The wrong NOTICE can be fixed later in my opinion, it has been wrong > > > for multiple releases already. > > > > > > Mit freundlichen Grüßen > > > > > > Thorsten Schöning > > > > > > -- > > > AM-SoFT IT-Service - Bitstore Hameln GmbH i.G. > > > 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 i.G., Brandenburger Str. 7c, > > > 31789 Hameln > > > AG Hannover HRB neu - Geschäftsführer: Janine Galonska > > > > > > > > > Für Rückfragen stehe ich Ihnen sehr gerne zur Verfügung. > > > > > > Mit freundlichen Grüßen > > > > > > Thorsten Schöning > > > > > > > > > Tel: 05151 9468 0 > > > Fax: 05151 9468 88 > > > Mobil: > > > Webseite: https://www.am-soft.de > > > > > > AM-Soft IT-Service - Bitstore Hameln GmbH i.G. ist ein Mitglied der > > > Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK > > > > > > AM-Soft IT-Service - Bitstore Hameln GmbH i.G. > > > Brandenburger Str. 7c > > > 31789 Hameln > > > Tel: 05151 9468 0 > > > > > > Bitstore IT-Consulting GmbH > > > Zentrale - Berlin Lichtenberg > > > Frankfurter Allee 285 > > > 10317 Berlin > > > Tel: 030 453 087 80 > > > > > > CBS IT-Service - Bitstore Kaulsdorf UG > > > Tel: 030 453 087 880 1 > > > > > > Büro Dallgow-Döberitz > > > Tel: 03322 507 020 > > > > > > Büro Kloster Lehnin > > > Tel: 033207 566 530 > > > > > > PCE IT-Service - Bitstore Darmstadt UG > > > Darmstadt > > > Tel: 06151 392 973 0 > > > > > > Büro Neuruppin > > > Tel: 033932 606 090 > > > > > > ACI EDV Systemhaus - Bitstore Dresden GmbH > > > Dresden > > > Tel: 0351 254 410 > > > > > > Das Systemhaus - Bitstore Magdeburg GmbH > > > Magdeburg > > > Tel: 0391 636 651 0 > > > > > > Allerdata.IT - Bitstore Wittenberg GmbH > > > Wittenberg > > > Tel: 03491 876 735 7 > > > > > > Büro Liebenwalde > > > Tel: 033054 810 00 > > > > > > HSA - das Büro - Bitstore Altenburg UG > > > Altenburg > > > Tel: 0344 784 390 97 > > > > > > Bitstore IT – Consulting GmbH > > > NL Piesteritz > > > Piesteritz > > > Tel: 03491 644 868 6 > > > > > > Solltec IT-Services - Bitstore Braunschweig UG > > > Braunschweig > > > Tel: 0531 206 068 0 > > > > > > MF Computer Service - Bitstore Gütersloh GmbH > > > Gütersloh > > > Tel: 05245 920 809 3 > > > > > > Firmensitz: AM-Soft IT-Service - Bitstore Hameln GmbH i.G. , > > > Brandenburger Str. 7c , 31789 Hameln > > > Geschäftsführer Janine Galonska > > > > > > > > > > > > > > > > > >
Re: [VOTE] Release log4cxx 0.12.0-RC2
This vote has passed with binding +1 votes from Matt Sicker, Robert Middleton, Remko Popma and Ralph Goers, with non-binding +1 votes from Thorsten Schöning and Steven Webb. I will proceed with the release. -Robert Middleton On Sun, May 9, 2021 at 12:36 AM Ralph Goers wrote: > > +1 > > Ralph > > > On May 8, 2021, at 8:28 PM, Remko Popma wrote: > > > > +1 > > > > On Sun, May 9, 2021 at 12:21 PM Stephen Webb wrote: > > > >> +1 > >> > >> On Sun, May 9, 2021 at 1:13 PM Robert Middleton > >> wrote: > >> > >>> As a reminder, this vote is still outstanding. > >>> > >>> -Robert Middleton > >>> > >>> On Tue, May 4, 2021 at 7:10 PM Robert Middleton > >>> wrote: > >>>> > >>>> I've updated the NOTICE file in git, so it will be correct for the > >>>> next release. :) > >>>> > >>>> Otherwise everything still looks good to me, so adding my +1 now. > >>>> > >>>> -Robert Middleton > >>>> > >>>> On Mon, May 3, 2021 at 2:02 PM Matt Sicker wrote: > >>>>> > >>>>> If you don't feel the NOTICE file is a problem, then please make sure > >>>>> to update it in git for the next release. :) > >>>>> > >>>>> Signatures checked out, source archives look good. +1 > >>>>> > >>>>> On Mon, 3 May 2021 at 10:54, Thorsten Schöning < > >> tschoen...@am-soft.de> > >>> wrote: > >>>>>> > >>>>>> Guten Tag Robert Middleton, > >>>>>> am Samstag, 1. Mai 2021 um 23:07 schrieben Sie: > >>>>>> > >>>>>>> Please download, test, and cast your votes on the log4j > >> developers > >>> list. > >>>>>> > >>>>>> +1 > >>>>>> > >>>>>> The wrong NOTICE can be fixed later in my opinion, it has been > >> wrong > >>>>>> for multiple releases already. > >>>>>> > >>>>>> Mit freundlichen Grüßen > >>>>>> > >>>>>> Thorsten Schöning > >>>>>> > >>>>>> -- > >>>>>> AM-SoFT IT-Service - Bitstore Hameln GmbH i.G. > >>>>>> 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 i.G., Brandenburger Str. > >>> 7c, 31789 Hameln > >>>>>> AG Hannover HRB neu - Geschäftsführer: Janine Galonska > >>>>>> > >>>>>> > >>>>>> Für Rückfragen stehe ich Ihnen sehr gerne zur Verfügung. > >>>>>> > >>>>>> Mit freundlichen Grüßen > >>>>>> > >>>>>> Thorsten Schöning > >>>>>> > >>>>>> > >>>>>> Tel: 05151 9468 0 > >>>>>> Fax: 05151 9468 88 > >>>>>> Mobil: > >>>>>> Webseite: https://www.am-soft.de > >>>>>> > >>>>>> AM-Soft IT-Service - Bitstore Hameln GmbH i.G. ist ein Mitglied der > >>> Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK > >>>>>> > >>>>>> AM-Soft IT-Service - Bitstore Hameln GmbH i.G. > >>>>>> Brandenburger Str. 7c > >>>>>> 31789 Hameln > >>>>>> Tel: 05151 9468 0 > >>>>>> > >>>>>> Bitstore IT-Consulting GmbH > >>>>>> Zentrale - Berlin Lichtenberg > >>>>>> Frankfurter Allee 285 > >>>>>> 10317 Berlin > >>>>>> Tel: 030 453 087 80 > >>>>>> > >>>>>> CBS IT-Service - Bitstore Kaulsdorf UG > >>>>>> Tel: 030 453 087 880 1 > >>>>>> > >>>>>> Büro Dallgow-Döberitz > >>>>>> Tel: 03322 507 020 > >>>>>> > >>>>>> Büro Kloster Lehnin > >>>>>> Tel: 033207 566 530 > >>>>>> > >>>>>> PCE IT-Service - Bitstore Darmstadt UG > >>>>>> Darmstadt > >>>>>> Tel: 06151 392 973 0 > >>>>>> > >>>>>> Büro Neuruppin > >>>>>> Tel: 033932 606 090 > >>>>>> > >>>>>> ACI EDV Systemhaus - Bitstore Dresden GmbH > >>>>>> Dresden > >>>>>> Tel: 0351 254 410 > >>>>>> > >>>>>> Das Systemhaus - Bitstore Magdeburg GmbH > >>>>>> Magdeburg > >>>>>> Tel: 0391 636 651 0 > >>>>>> > >>>>>> Allerdata.IT - Bitstore Wittenberg GmbH > >>>>>> Wittenberg > >>>>>> Tel: 03491 876 735 7 > >>>>>> > >>>>>> Büro Liebenwalde > >>>>>> Tel: 033054 810 00 > >>>>>> > >>>>>> HSA - das Büro - Bitstore Altenburg UG > >>>>>> Altenburg > >>>>>> Tel: 0344 784 390 97 > >>>>>> > >>>>>> Bitstore IT – Consulting GmbH > >>>>>> NL Piesteritz > >>>>>> Piesteritz > >>>>>> Tel: 03491 644 868 6 > >>>>>> > >>>>>> Solltec IT-Services - Bitstore Braunschweig UG > >>>>>> Braunschweig > >>>>>> Tel: 0531 206 068 0 > >>>>>> > >>>>>> MF Computer Service - Bitstore Gütersloh GmbH > >>>>>> Gütersloh > >>>>>> Tel: 05245 920 809 3 > >>>>>> > >>>>>> Firmensitz: AM-Soft IT-Service - Bitstore Hameln GmbH i.G. , > >>> Brandenburger Str. 7c , 31789 Hameln > >>>>>> Geschäftsführer Janine Galonska > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>> > >> > >
[VOTE] Release Apache Chainsaw 2.1.0
This vote is to release Apache Chainsaw 2.1.0. This fixes a few annoying issues with chainsaw and some other bugs, as well as updating some dependencies. 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. Tag: For a new copy do "git clone https://github.com/apache/logging-chainsaw.git"; and then "git checkout tags/apache-chainsaw-2.1.0-RC1" Web site: https://logging.staged.apache.org/chainsaw/2.1.0/ Distribution archives: https://dist.apache.org/repos/dist/dev/logging/chainsaw/ -Robert Middleton
Re: [VOTE] Release Apache Chainsaw 2.1.0
I was just going off of what was in the SVN develop repo before - there wasn't a sources file in there, so I didn't add one. That being said, the only thing that is generated at the moment is a sources.jar with the sources, but that's probably not the correct thing to do for the sources. It looks like we might be missing something in the POM? The current directions for releasing make no mention of the sources, and the sign-artifacts.sh doesn't seem to attempt to sign the sources either. -Robert Middleton On Wed, Jun 2, 2021 at 8:40 AM Gary Gregory wrote: > > On Tue, Jun 1, 2021 at 11:37 PM Matt Sicker wrote: > > > > The NOTICE file still has a copyright from 2007, but that was already > > a problem in the previous release, so that can be fixed in another > > release. Also, it looks like you didn't commit the source archives to > > svn yet? > > As a reminder, Apache really distributes sources, so that's what we > should check as opposed to a git checkout. The binaries we offer are a > convenience to our users. > > Gary > > > > > On Tue, 1 Jun 2021 at 20:58, Robert Middleton wrote: > > > > > > This vote is to release Apache Chainsaw 2.1.0. This fixes a few > > > annoying issues with chainsaw and some other bugs, as well as updating > > > some dependencies. > > > > > > 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. > > > > > > Tag: > > > For a new copy do "git clone > > > https://github.com/apache/logging-chainsaw.git"; and then "git checkout > > > tags/apache-chainsaw-2.1.0-RC1" > > > > > > Web site: https://logging.staged.apache.org/chainsaw/2.1.0/ > > > > > > Distribution archives: > > > https://dist.apache.org/repos/dist/dev/logging/chainsaw/ > > > > > > -Robert Middleton
Re: Apache Log4j is part of the Mars 2020 Helicopter mission
Does that mean we can now say log4j2 is out of this world? ;) -Robert Middleton On Fri, Jun 4, 2021 at 11:47 AM Gary Gregory wrote: > > -- Forwarded message - > From: Gary Gregory > Date: Fri, Jun 4, 2021, 11:27 > Subject: Apache Log4j is part of the Mars 2020 Helicopter mission > To: Log4J Developers List , Sally Khudairi < > sallykhuda...@yahoo.com> > > > Hi Sally and All, > > My GitHub profile was adorned with a new badge today: > https://github.com/garydgregory > > Which points to https://github.com/readme/nasa-ingenuity-helicopter > > It looks like Apache Log4j is part of the Mars 2020 Helicopter mission! > > It would be nice to publicize that fact :-) > > Gary
Re: [DISCUSS] [VOTE] Release Apache Chainsaw 2.1.0
I'm working on that now. I'm just fixing the copyright date in the NOTICE file and making sure that the sign-artifacts will sign the source archive, so just a few minor changes. -Robert Middleton On Sat, Jun 5, 2021 at 8:11 PM Ralph Goers wrote: > > Is something going to be done to address the need for a source archive? It > should be possible to create one based on the release work that has already > been performed. > > Ralph > > > On Jun 3, 2021, at 7:51 AM, Matt Sicker wrote: > > > > Minimal source releases can be made by using git archive on the tag and > > signing/hashing the file. Then commit those to the release candidate repo. > > > > On Wed, Jun 2, 2021 at 23:22 Ralph Goers wrote: > > > >> Unfortunately, without a source zip or gz there is no release to approve. > >> > >> Ralph > >> > >>> On Jun 1, 2021, at 6:58 PM, Robert Middleton > >> wrote: > >>> > >>> This vote is to release Apache Chainsaw 2.1.0. This fixes a few > >>> annoying issues with chainsaw and some other bugs, as well as updating > >>> some dependencies. > >>> > >>> 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. > >>> > >>> Tag: > >>> For a new copy do "git clone > >>> https://github.com/apache/logging-chainsaw.git"; and then "git checkout > >>> tags/apache-chainsaw-2.1.0-RC1" > >>> > >>> Web site: https://logging.staged.apache.org/chainsaw/2.1.0/ > >>> > >>> Distribution archives: > >> https://dist.apache.org/repos/dist/dev/logging/chainsaw/ > >>> > >>> -Robert Middleton > >>> > >> > >> > >> > >
[VOTE] Release Apache Chainsaw 2.1.0-RC2
This vote is to release Apache Chainsaw 2.1.0. This fixes a few annoying issues with chainsaw and some other bugs, as well as updating some dependencies. This vote supersedes the original vote Differences from RC1: * Added source archive. Note that this is created with 'git archive' * Updated copyright date 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. Tag: For a new copy do "git clone https://github.com/apache/logging-chainsaw.git"; and then "git checkout tags/apache-chainsaw-2.1.0-RC2" Web site: https://logging.staged.apache.org/chainsaw/2.1.0/ Distribution archives: https://dist.apache.org/repos/dist/dev/logging/chainsaw/ -Robert Middleton
Re: [CI][FAILURE] Logging/chainsaw/master#25 has potential issues
Thanks; I've been ignoring that while the release happens(there's probably an easier way to do it on my side). Somewhat related question: does the ASF Jenkins have any Mac builders? It would be nice to make sure that the DMG gets generated on builds(I suppose I could use github actions instead). -Robert Middleton On Sun, Jun 6, 2021 at 3:54 PM Matt Sicker wrote: > > I've fixed this issue. The problem was that while the version in master > doesn't have a -SNAPSHOT, it can't be deployed to the snapshots repository > (duh). I've updated the pipeline to check the maven project version for > this before attempting to run a deploy step to publish snapshot builds. As > a bonus, the Chainsaw pipeline is now more "standard" (no need to abstract > out a Windows build or toolchains.xml usage). > > On Sat, 5 Jun 2021 at 19:01, Mr. Jenkins > wrote: > > > *BUILD FAILURE* > > Build URL > > https://ci-builds.apache.org/job/Logging/job/chainsaw/job/master/25/ > > Project: master > > Date of build: Sun, 06 Jun 2021 00:00:00 + > > Build duration: 1 min 35 sec and counting > > * JUnit Tests * > > Name: org.apache.log4j.chainsaw Failed: 0 test(s), Passed: 1 test(s), > > Skipped: 0 test(s), Total: 1 test(s) > > Name: org.apache.log4j.chainsaw.receivers Failed: 0 test(s), Passed: 1 > > test(s), Skipped: 0 test(s), Total: 1 test(s) > > Name: org.apache.log4j.db Failed: 0 test(s), Passed: 2 test(s), Skipped: 0 > > test(s), Total: 2 test(s) > > Name: org.apache.log4j.helpers Failed: 0 test(s), Passed: 1 test(s), > > Skipped: 0 test(s), Total: 1 test(s) > > Name: org.apache.log4j.rewrite Failed: 0 test(s), Passed: 3 test(s), > > Skipped: 0 test(s), Total: 3 test(s) > > Name: org.apache.log4j.xml Failed: 0 test(s), Passed: 4 test(s), Skipped: > > 0 test(s), Total: 4 test(s) > > * CONSOLE OUTPUT * > > [...truncated 1287 lines...] > > Progress (1): 295/858 kB > > Progress (1): 303/858 kB > > Progress (1): 311/858 kB > > Progress (1): 319/858 kB > > Progress (1): 328/858 kB > > Progress (1): 336/858 kB > > Progress (1): 344/858 kB > > Progress (1): 352/858 kB > > Progress (1): 360/858 kB > > Progress (1): 369/858 kB > > Progress (1): 377/858 kB > > Progress (1): 385/858 kB > > Progress (1): 393/858 kB > > Progress (1): 401/858 kB > > Progress (1): 410/858 kB > > Progress (1): 418/858 kB > > Progress (1): 426/858 kB > > Progress (1): 434/858 kB > > Progress (1): 442/858 kB > > Progress (1): 451/858 kB > > Progress (1): 459/858 kB > > Progress (1): 467/858 kB > > Progress (1): 475/858 kB > > Progress (1): 483/858 kB > > Progress (1): 492/858 kB > > Progress (1): 500/858 kB > > Progress (1): 508/858 kB > > Progress (1): 516/858 kB > > Progress (1): 524/858 kB > > Progress (1): 532/858 kB > > Progress (1): 541/858 kB > > Progress (1): 549/858 kB > > Progress (1): 557/858 kB > > Progress (1): 565/858 kB > > Progress (1): 573/858 kB > > Progress (1): 582/858 kB > > Progress (1): 590/858 kB > > Progress (1): 598/858 kB > > Progress (1): 606/858 kB > > Progress (1): 614/858 kB > > Progress (1): 623/858 kB > > Progress (1): 631/858 kB > > Progress (1): 639/858 kB > > Progress (1): 647/858 kB > > Progress (1): 655/858 kB > > Progress (1): 664/858 kB > > Progress (1): 672/858 kB > > Progress (1): 680/858 kB > > Progress (1): 688/858 kB > > Progress (1): 696/858 kB > > Progress (1): 705/858 kB > > Progress (1): 713/858 kB > > Progress (1): 721/858 kB > > Progress (1): 729/858 kB > > Progress (1): 737/858 kB > > Progress (1): 745/858 kB > > Progress (1): 754/858 kB > > Progress (1): 762/858 kB > > Progress (1): 770/858 kB > > Progress (1): 778/858 kB > > Progress (1): 786/858 kB > > Progress (1): 795/858 kB > > Progress (1): 803/858 kB > > Progress (1): 811/858 kB > > Progress (1): 819/858 kB > > Progress (1): 827/858 kB > > Progress (1): 836/858 kB > > Progress (1): 844/858 kB > > Progress (1): 852/858 kB > > Progress (1): 858 kB > > Uploading to apache.releases.https: > > https://repository.apache.org/service/local/staging/deploy/maven2/log4j/apache-chainsaw/2.1.0/apache-chainsaw-2.1.0.pom > > Progress (1): 4.1/21 kB > > Progress (1): 8.2/21 kB > > Progress (1): 12/21 kB > > Progress (1): 16/21 kB > > Progress (1): 20/21 kB > > Progress (1): 21 kB > > [INFO] > > > > [INFO] BUILD FAILURE &g
Re: How to get off mailing list
You need to send a message to dev-unsubscr...@logging.apache.org Mailing list info is here: http://logging.apache.org/mailing-lists.html -Robert Middleton On Mon, Jun 7, 2021 at 8:47 AM Palmer, Eric wrote: > > How can I get my email address remove from dev@logging.apache.org > dev@logging.apache.org<mailto:dev@logging.apache.org> > > Thanks > > -- > Eric Palmer > Director of Web Services > University of Richmond > > >
Re: [VOTE] Release Apache Chainsaw 2.1.0-RC2
Adding my +1 here. With that, the release passes with +1 votes from Remko Popma, Matt Sicker, and Robert Middleton. I shall proceed with the release. -Robert Middleton On Sun, Jun 6, 2021 at 3:22 PM Matt Sicker wrote: > > Nits (not blockers, but useful to fix for next release): > * Source archive should be created by adding the option > --prefix=apache-chainsaw-2.1.0/ so that the archives are inside a > directory. As is, they don't have a containing directory which can be > unexpected. > > +1 > > Signatures good, built and tested on Java 11 with the version info: > > Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d) > Maven home: /usr/local/Cellar/maven/3.8.1/libexec > Java version: 11.0.10, vendor: Oracle Corporation, runtime: > /usr/local/Cellar/openjdk@11/11.0.10/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "11.4", arch: "x86_64", family: "mac" > > On Sat, 5 Jun 2021 at 20:06, Remko Popma wrote: > > > > +1 > > > > On Sun, Jun 6, 2021 at 9:36 AM Robert Middleton > > wrote: > > > > > This vote is to release Apache Chainsaw 2.1.0. This fixes a few > > > annoying issues with chainsaw and some other bugs, as well as updating > > > some dependencies. > > > > > > This vote supersedes the original vote > > > > > > Differences from RC1: > > > * Added source archive. Note that this is created with 'git archive' > > > * Updated copyright date > > > > > > 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. > > > > > > Tag: > > > For a new copy do "git clone > > > https://github.com/apache/logging-chainsaw.git"; and then "git checkout > > > tags/apache-chainsaw-2.1.0-RC2" > > > > > > Web site: https://logging.staged.apache.org/chainsaw/2.1.0/ > > > > > > Distribution archives: > > > https://dist.apache.org/repos/dist/dev/logging/chainsaw/ > > > > > > -Robert Middleton > > >
[Chainsaw] JSON Support
I'm looking into adding some more modern JSON support into Chainsaw for processing log statements from applications, but I'm not sure what the best format for that is at the moment. Is there a standard JSON format that would make the most sense to use? Currently, I'm thinking that this would make the most sense to have Chainsaw listen on a TCP or UDP port for the JSON messages. Are there any other ways that you would normally send a log message that I'm not thinking about? -Robert Middleton
Re: [Chainsaw] JSON Support
On Fri, Jun 18, 2021 at 8:40 AM Volkan Yazıcı wrote: > > ECS <https://www.elastic.co/guide/en/ecs/current/ecs-reference.html>, the > default schema shipped with JsonTemplateLayout, is nowadays the de facto > structure for JSON formatted logs. Since Chainsaw will parse logs emitted > mostly from Log4j, it is wise to make it fully compliant with the one we > ship in Log4j. For that, search for EcsLayout.json in the sources. > Thanks for that - I was looking at the ECS stuff a while ago, but I couldn't really figure out their documentation. For whatever reason, the ECS documentation seems to be very concerned with how to use elastic search, but not with how to actually format the messages to send. -Robert Middleton
Re: [Chainsaw] JSON Support
I've added some basic JSON support to Chainsaw:
https://github.com/apache/logging-chainsaw/pull/9
It is a little funny to work with though, because of how Chainsaw
works it is tightly tied to Log4j1 messages, so all we're really doing
is extracting the parts that we care about and putting it into the
Log4j1 format.
This does require adding a new dependency to parse JSON(Genson), but
that is Apache licensed.
-Robert Middleton
On Sat, Jun 19, 2021 at 6:29 AM Volkan Yazıcı wrote:
>
> For the records, JsonTemplateLayout also quotes all escape characters,
> including CR and LF characters, in every(!) string value. For instance, the
> following test succeeds:
>
> String eventTemplate = writeJson(asMap(
> "epochSecs", asMap(
> "$resolver", "exception",
> "field", "stackTrace",
> "stackTrace", asMap(
> "stringified", true;
> JsonTemplateLayout layout = JsonTemplateLayout
> .newBuilder()
> .setConfiguration(CONFIGURATION)
> .setEventTemplate(eventTemplate)
> .setEventDelimiter("")
> .build();
> LogEvent logEvent = Log4jLogEvent
> .newBuilder()
> .setLoggerName(LOGGER_NAME)
> .setThrown(new RuntimeException())
> .build();
> String serializedLogEvent = layout.toSerializable(logEvent);
> assertThat(serializedLogEvent).doesNotContain("\n");
>
> Hence, newlines in stack traces or whatever input string there is to be
> encoded to JSON, are not a problem for JsonTemplateLayout.
>
> On Fri, Jun 18, 2021 at 7:49 PM Ralph Goers
> wrote:
>
> >
> >
> > > On Jun 18, 2021, at 10:40 AM, Matt Sicker wrote:
> > >
> > > A couple other common log collection setups I've come across over time:
> > >
> > > * Logging to stdout/stderr in a standard format, then use a log
> > > collection API from your orchestration engine (common in the
> > > Kubernetes world to avoid logging to a file).
> >
> > NOT recommended for use with Log4j. See
> > http://logging.apache.org/log4j/2.x/manual/cloud.html.
> >
> > > * Logging to a log file as normal, but running a log forwarding agent
> > > alongside (e.g., Splunk, Logstash).
> > > * Logging to syslog (typically more important for auditing and
> > > security related logs)
> > >
> > > For the log format itself, JSON template layouts work great here for
> > > customizing how much info you need in your logs. It also makes it much
> > > easier to create log indices in various log searching products. Which
> > > particular one hasn't been as important in my experience as trying to
> > > stay consistent.
> > >
> >
> > I happen to like GELF as it neatly solves the problem of Java Exceptions
> > having newlines in them. Other formats that use the newline to delimit the
> > end of the message require weird rules to be set up in Logstash to glue
> > the various lines back together again. Invariably some message will
> > violate
> > the assumptions the rules are based on.
> >
> > Ralph
> >
> >
> >
Re: log4cxx build issue on Centos 7.6
Russ, > I've tried guessing where to drop some "#include " lines, and if I do > that, the build heads straight into problems with shared_mutex (which it > should be getting from Boost) instead. If you could provide a patch/PR for that, that would be great - GCC likes to move things around headers sometimes, so things may not always compile with different versions. :( Anyway, if you look at the configuration output, you'll see the following: > -- log4cxx configuration summary: > > -- shared_mutex implementation . : That should print out either std::shared_mutex, or boost::shared_mutex. That would match with what you're seeing on the output with the variables being defined as they are. According to the Boost documentation, shared_mutex should be available with version 1.53. If you look at the log4cxx sources, you can try compiling src/cmake/boost-fallback/test-boostsharedmutex.cpp and see if it fails. If it compiles properly, there may just be a bug with the detection of boost. Otherwise perhaps boost isn't compiled with needed support for shared_mutex? -Robert Middleton On Thu, Jun 24, 2021 at 4:59 PM Miranda, Russel wrote: > > Dear log4cxx developers, > > I am trying to build log4cxx on a Centos 7.6 system, using: > * CMake 3.13.4, > * g++ 4.8.5 > * Boost 1.53.0 > * apr-1.6.2 > * apr-devel-1.6.2 > * apr-util-1.6.0 > * apr-util-devel-1.6.0 > > But I am not having much success. The CMake appears to run without error, > excluding the JAVA pieces (we should be OK to skip those tests): > > [build (test-v0.12.0 %)]$ cmake3 .. > -- Found APR: -L/usr/lib64;-lapr-1 > -- Boost version: 1.53.0 > -- Found the following Boost libraries: > -- thread > -- chrono > -- system > -- date_time > -- atomic > -- Could NOT find Java (missing: Java_JAVAC_EXECUTABLE Java_JAR_EXECUTABLE > Java_JAVADOC_EXECUTABLE Java_JAVAH_EXECUTABLE Development) (found version > "1.8.0.201") > -- > -- > -- log4cxx configuration summary: > -- > -- Build shared library : ON > -- Build tests . : ON > -- Build site .. : OFF > -- Install prefix .. : /usr/local > -- C++ compiler : /usr/bin/c++ > -- log4cxx char API : utf-8 > -- log4cxx wchar API ... : ON > -- log4cxx unichar API . : OFF > -- logchar type : utf-8 > -- charset . : locale > -- Using libESMTP .. : OFF > -- ODBC library : OFF > -- syslog .. : ON > -- Qt support .. : OFF > -- shared_mutex implementation . : > -- Applications required for tests: > -- zip . : /usr/bin/zip > -- sed . : /usr/bin/sed > -- gzip : /usr/bin/gzip > -- Configuring done > -- Generating done > -- Build files have been written to: > /home/shared/ramirand/git2/oamlog4cxx/log4cxx/build > > ... but then the build runs into errors: > > [build (test-v0.12.0 %)]$ make > Checking configuration > [ 0%] Built target configure_log4cxx > Scanning dependencies of target log4cxx > [ 1%] Building CXX object src/main/cpp/CMakeFiles/log4cxx.dir/action.cpp.o > In file included from > /home/shared/ramirand/git2/oamlog4cxx/log4cxx/src/main/cpp/action.cpp:18:0: > /home/shared/ramirand/git2/oamlog4cxx/log4cxx/src/main/include/log4cxx/rolling/action.h:51:3: > error: 'mutex' in namespace 'std' does not name a type >std::mutex mutex; >^ > /home/shared/ramirand/git2/oamlog4cxx/log4cxx/src/main/cpp/action.cpp: In > member function 'void log4cxx::rolling::Action::run(log4cxx::helpers::Pool&)': > /home/shared/ramirand/git2/oamlog4cxx/log4cxx/src/main/cpp/action.cpp:43:36: > error: 'mutex' was not declared in this scope > std::unique_lock lock(mutex); > ^ > /home/shared/ramirand/git2/oamlog4cxx/log4cxx/src/main/cpp/action.cpp:43:36: > note: suggested alternative: > In file included from > /home/shared/ramirand/git2/oamlog4cxx/log4cxx/src/main/cpp/action.cpp:19:0: > /usr/include/c++/4.8.2/mutex:117:9: note: 'std::mutex' >class mutex : private __mutex_base > ^ > /home/shared/ramirand/git2/oamlog4cxx/log4cxx/src/main/cpp/action.cpp: In > member function 'void log4cxx::rolling::Action::close()': > /home/shared/ramirand/git2/oamlog4cxx/log4cxx/src/main/cpp/action.cpp:66:36: > error: 'mutex' was not declared in this scope > std::unique_lock lock(mutex); >
Rolling tests / writing X log messages per second
Is there a reliable way to ensure that X number of log messages get
written out per second? I ask because one of the problems that we
have with log4cxx is that the TimeBasedRollingTest randomly fails(on
OSX). I've narrowed it down to the following function:
void logMsgAndSleep(Pool & pool,
size_t howOften,
std::string srcFunc,
size_t srcLine,
size_t startWith = 0,
float waitFactor = 0.5)
{
for (size_t i = startWith; i < startWith + howOften; ++i)
{
std::string message("Hello---");
message.append(pool.itoa(i));
LOG4CXX_DEBUG(logger, message);
apr_sleep(APR_USEC_PER_SEC * waitFactor);
}
}
The issue seems to be that due to various scheduling whims, we may not
always get the correct number of messages printed out per second, so
the test will fail. Is there a better way to do this, perhaps
something in log4j?
-Robert Middleton
Re: Rolling tests / writing X log messages per second
Firing events at a certain rate. The test configures the rolling file
appender to roll over once a second.
Specifically, the test ensures that the following works:
* Write log line 1 <-- second 1
* Write log line 2 <-- second 1
* Write log line 3, causes rollover <-- second 2
* Write log line 4 <-- second 2
* Write log line 5, causes rollover <-- second 3
etc...
Under certain conditions(mostly when running under Github actions on
OSX) this can result in the file having 1 or 3 log messages in it,
instead of exactly 2. So it almost certainly has to do with the
particular scheduling and sleep interaction.
I'm thinking that the best thing to do is to change up the algorithm
slightly so that it does
* write log line 1
* write log line 2
* wait until the next second
* write log line 3, causing rollover
etc...
-Robert Middleton
On Thu, Jul 1, 2021 at 3:22 PM Volkan Yazıcı wrote:
>
> What do you exactly mean by "ensuring"? Checking if the event rate was
> correct? Or rather firing events at a certain rate? For the former, you can
> collect all the events, split the collection into buckets of seconds, and
> count the number of events in each bucket. For the latter, did you try busy
> spinning rather than apr_sleep to avoid context switch costs? If I would
> want to implement this in Java, I would use a stock rate limiter, and shoot
> using that. That is,
>
> RateLimiter rateLimiter = RateLimiter.ofPermitsPerSecond(10);
> for (int i = 0; i < l; i++) {
> rateLimiter.acquire(); // This will block if the permit is not
> available.
> // You might want to sleep here some random amount of time, just to
> fluctuate the rate over time.
> logger.debug("event {}", i);
> }
>
> For RateLimiter, I would either use Guava or Resilience4j. I actually have a
> single-class rate limiter implementation
> <https://gist.github.com/vy/2f1ff259e0814c4bf32ee89f3a26dfff> that I stole
> from Resilience4j:
>
> On Tue, Jun 29, 2021 at 3:17 AM Robert Middleton
> wrote:
>
> > Is there a reliable way to ensure that X number of log messages get
> > written out per second? I ask because one of the problems that we
> > have with log4cxx is that the TimeBasedRollingTest randomly fails(on
> > OSX). I've narrowed it down to the following function:
> >
> > void logMsgAndSleep(Pool & pool,
> > size_t howOften,
> > std::string srcFunc,
> > size_t srcLine,
> > size_t startWith = 0,
> > float waitFactor = 0.5)
> > {
> >
> > for (size_t i = startWith; i < startWith + howOften; ++i)
> > {
> > std::string message("Hello---");
> > message.append(pool.itoa(i));
> >
> > LOG4CXX_DEBUG(logger, message);
> > apr_sleep(APR_USEC_PER_SEC * waitFactor);
> > }
> >
> > }
> >
> > The issue seems to be that due to various scheduling whims, we may not
> > always get the correct number of messages printed out per second, so
> > the test will fail. Is there a better way to do this, perhaps
> > something in log4j?
> >
> > -Robert Middleton
> >
Re: Rolling tests / writing X log messages per second
That does sound like a good idea. We can probably replace all of the calls
to APR for the time with their C++ standard equivalents as well to allow
for easy mocking.
-Robert Middleton
On Mon, Jul 5, 2021 at 3:26 AM Volkan Yazıcı
wrote:
> I totally agree with Matt on this. Once the code starts changing behaviour
> via the system time, it becomes practically impossible to decently test it.
> If you can mock the clock, testing becomes tractable. To the best of my
> knowledge, that is what we mostly do in Log4j too.
>
> On Sun, Jul 4, 2021 at 8:37 PM Matt Sicker wrote:
>
> > When testing the passage of time, you can always try mocking the clock
> > itself to simulate things like that. In some cases, use of count down
> > latches or cyclic barriers can coordinate the various async actions
> rather
> > than relying on clocks. Once you start testing and modeling these things
> > like that, I think the scheduling bugs and any other weird interactions
> > will become far easier to discover and fix.
> >
> > On Thu, Jul 1, 2021 at 19:09 Robert Middleton
> wrote:
> >
> > > Firing events at a certain rate. The test configures the rolling file
> > > appender to roll over once a second.
> > >
> > > Specifically, the test ensures that the following works:
> > > * Write log line 1 <-- second 1
> > > * Write log line 2 <-- second 1
> > > * Write log line 3, causes rollover <-- second 2
> > > * Write log line 4 <-- second 2
> > > * Write log line 5, causes rollover <-- second 3
> > > etc...
> > >
> > > Under certain conditions(mostly when running under Github actions on
> > > OSX) this can result in the file having 1 or 3 log messages in it,
> > > instead of exactly 2. So it almost certainly has to do with the
> > > particular scheduling and sleep interaction.
> > >
> > > I'm thinking that the best thing to do is to change up the algorithm
> > > slightly so that it does
> > > * write log line 1
> > > * write log line 2
> > > * wait until the next second
> > > * write log line 3, causing rollover
> > > etc...
> > >
> > > -Robert Middleton
> > >
> > > On Thu, Jul 1, 2021 at 3:22 PM Volkan Yazıcı
> > > wrote:
> > > >
> > > > What do you exactly mean by "ensuring"? Checking if the event rate
> was
> > > > correct? Or rather firing events at a certain rate? For the former,
> you
> > > can
> > > > collect all the events, split the collection into buckets of seconds,
> > and
> > > > count the number of events in each bucket. For the latter, did you
> try
> > > busy
> > > > spinning rather than apr_sleep to avoid context switch costs? If I
> > would
> > > > want to implement this in Java, I would use a stock rate limiter, and
> > > shoot
> > > > using that. That is,
> > > >
> > > > RateLimiter rateLimiter = RateLimiter.ofPermitsPerSecond(10);
> > > > for (int i = 0; i < l; i++) {
> > > > rateLimiter.acquire(); // This will block if the permit is not
> > > > available.
> > > > // You might want to sleep here some random amount of time, just
> to
> > > > fluctuate the rate over time.
> > > > logger.debug("event {}", i);
> > > > }
> > > >
> > > > For RateLimiter, I would either use Guava or Resilience4j. I actually
> > > have a
> > > > single-class rate limiter implementation
> > > > <https://gist.github.com/vy/2f1ff259e0814c4bf32ee89f3a26dfff> that I
> > > stole
> > > > from Resilience4j:
> > > >
> > > > On Tue, Jun 29, 2021 at 3:17 AM Robert Middleton <
> > rmiddle...@apache.org>
> > > > wrote:
> > > >
> > > > > Is there a reliable way to ensure that X number of log messages get
> > > > > written out per second? I ask because one of the problems that we
> > > > > have with log4cxx is that the TimeBasedRollingTest randomly
> fails(on
> > > > > OSX). I've narrowed it down to the following function:
> > > > >
> > > > > void logMsgAndSleep(Pool & pool,
> > > > > size_t howOften,
> > > > > std::string srcFunc,
> > > > > size_t srcLine,
> > > > > size_t startWith = 0,
> > > > > float waitFactor = 0.5)
> > > > > {
> > > > >
> > > > > for (size_t i = startWith; i < startWith + howOften; ++i)
> > > > > {
> > > > > std::string message("Hello---");
> > > > > message.append(pool.itoa(i));
> > > > >
> > > > > LOG4CXX_DEBUG(logger, message);
> > > > > apr_sleep(APR_USEC_PER_SEC * waitFactor);
> > > > > }
> > > > >
> > > > > }
> > > > >
> > > > > The issue seems to be that due to various scheduling whims, we may
> > not
> > > > > always get the correct number of messages printed out per second,
> so
> > > > > the test will fail. Is there a better way to do this, perhaps
> > > > > something in log4j?
> > > > >
> > > > > -Robert Middleton
> > > > >
> > >
> >
>
[log4cxx] Do a 12.1 release?
Without the fix for LOGCXX-534, multithreaded rolling logging is broken. Since it's a pretty simple and minor fix, I was thinking that we should do a release with just this fix, as this seems like it could be a common configuration. Thoughts? -Robert Middleton
Re: [log4cxx] Do a 12.1 release?
I'll do a release sometime in the next week or two then, cherry-picking that one commit. It shouldn't be that hard to do. -Robert Middleton On Mon, Sep 13, 2021 at 10:00 AM Thorsten Schöning wrote: > > Guten Tag Robert Middleton, > am Montag, 13. September 2021 um 15:24 schrieben Sie: > > > Without the fix for LOGCXX-534, multithreaded rolling logging is > > broken. Since it's a pretty simple and minor fix, I was thinking > > that we should do a release with just this fix, as this seems like it > > could be a common configuration. Thoughts? > > Sounds reasonable to me, especially when looking at the signalling > stuff. Who knows what that might break, so +1 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] Do a 12.1 release?
I've created a 0.12.x branch: https://github.com/apache/logging-log4cxx/tree/v0.12.x Currently, this fixes LOGCXX-528(which had to do with not compiling on C++11 only systems), and LOGCXX-534. There are a few other minor fixes in there that have to do with buildsystem updates, but otherwise I expect this to be what is released for 12.1. I'll do the proper release in a day or so, unless something else comes up that we feel is needed for this release. -Robert Middleton On Mon, Sep 13, 2021 at 5:43 PM Robert Middleton wrote: > > I'll do a release sometime in the next week or two then, > cherry-picking that one commit. It shouldn't be that hard to do. > > -Robert Middleton > > On Mon, Sep 13, 2021 at 10:00 AM Thorsten Schöning > wrote: > > > > Guten Tag Robert Middleton, > > am Montag, 13. September 2021 um 15:24 schrieben Sie: > > > > > Without the fix for LOGCXX-534, multithreaded rolling logging is > > > broken. Since it's a pretty simple and minor fix, I was thinking > > > that we should do a release with just this fix, as this seems like it > > > could be a common configuration. Thoughts? > > > > Sounds reasonable to me, especially when looking at the signalling > > stuff. Who knows what that might break, so +1 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 > > > > > > > >
[VOTE] Release log4cxx 0.12.1
This is a vote to release log4cxx 0.12.1. 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/12350609 Tag: For a new copy do "git clone https://github.com/apache/logging-log4cxx.git"; and then "git checkout tags/v0.12.1-RC1" For an existing working copy, do "git pull" and then "git checkout tags/v012.1-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
