Re: Filters and Async Appender
Hi Ralph,
First, thank you for your quick answer! :)
I just wrote a simple project to show you this behavior I am adding 2 filters
one should be global(at least I think) and other to the logger.
Project: https://github.com/dennysfredericci/log4j2-filter-spike
Main class:
https://github.com/dennysfredericci/log4j2-filter-spike/blob/master/src/main/java/br/com/fredericci/Main.java
The output will be:
Global Filter: 0
Logger Filter: 3
For some reason, the filter on the logger was called 3 times and the global
filter was never called.
Is there any mistake on how I am adding the global filter? Why it is not
working?
If a global filter is called just once will be perfect for my use case.
Thank you!
Regards,
Dennys Fredericci
On 2020/08/04 21:18:57, Ralph Goers wrote:
> A Global Filter can be called once during the isEnabled check and then again
> when the event is actually logged. But Filters that are attached to Loggers,
> Appender-Refs and Appenders should only be called once. I am not sure why
> thought would be any different with an Async appender.
>
> Ralph
>
>
>
> > On Aug 4, 2020, at 12:55 PM, Dennys Fredericci
> > wrote:
> >
> > Hi All,
> >
> > There is a library micrometer(https://micrometer.io/) used to collect
> > metrics, one of these metrics is a log rate, several calls for log.info,
> > log.debug, log.warn, etc.
> >
> > Micrometer implements a
> > Filter(org.apache.logging.log4j.core.filter.AbstractFilter) and for each
> > call to the method filter we increment a counter.
> >
> > After some research, I noticed that the method filter can be called
> > multiple times especially when an Async appender is configured and in this
> > case, we have a wrong logging rate. An application called on time the
> > method log.info("Test..") but the rate can easily be 2 instead of 1.
> >
> > I tried to implement a solution but still not correct.
> >
> > Now I am wondering if Filter still feasible for this use case, I am quite
> > convinced that will be not possible to use Filter to solve this.
> >
> > So, now my question is: Is there another way to get the number calls for
> > each logging level? Or is there a workaround that can be implemented on the
> > Filter implementation to do the correct count?
> >
> > Regards,
> > Dennys Fredericci
> >
> >
> >
>
>
>
Re: [log4cxx] Status update
For signing the release, just make sure we add your signing key to the
KEYS file. For uploading it, as long as you include the .asc files
with the artifacts, you can upload them _anywhere_, and one of the PMC
members can download them, verify they're signed correctly, then copy
those files to the svn repo for you. Realistically, we only _need_ to
commit the release artifact, not the release candidate. Out of
convenience, we have a separate dist-dev svn repo where we typically
upload release candidates, but for committers, you can upload the RC
artifacts wherever.
Footnote: this whole explanation wouldn't apply that well if you also
needed access to upload to repository.apache.org for Java artifacts.
Since that doesn't seem to be the case, that's one less thing for a
PMC member to upload for you after the vote passes.
On Thu, 6 Aug 2020 at 04:51, Tobias Frost wrote:
>
> On Wed, Aug 05, 2020 at 06:08:48PM -0700, Ralph Goers wrote:
> > Remember, releases don’t have to be perfect. In practice, you just want
> > them to hopefully be better than the prior release.
>
> this SO-NAME bug can create some havoc down the road, especially at
> distributions… So I have some interest in getting that fixed so
> here's a patch as basis for discussion:
> It makes cmake produces also the same SO-version. (Tested on Linux only,
> sorry;
> do not own a windows box)
>
> (Patch also available as PR https://github.com/apache/logging-log4cxx/pull/32)
>
> Alternatively, log4cxx could change its versioning to match the so name
> versioning…
> (IOW that would mean it would go to version 11.0.0 with the next release)
> That of course means retiring autotools or fixing it… (IMHO retiring would be
> ok)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 2757cfe7..09254859 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -3,6 +3,11 @@ include(src/cmake/projectVersionDetails.cmake)
> project(log4cxx VERSION ${log4cxx_VER} LANGUAGES CXX)
> include(CTest)
>
> +# define the SO Version of the library. Version of the log4cxx project is
> subtly different than the version of the library
> +# (at least in the past it was project vesion: 0.a.b.c and the library so
> vesion a.b.c.0
> +set(LIBLOG4CXX_LIB_VERSION
> ${log4cxx_VERSION_MINOR}.${log4cxx_VERSION_PATCH}.${log4cxx_VERSION_TWEAK})
> +set(LIBLOG4CXX_LIB_SOVERSION ${log4cxx_VERSION_MINOR})
> +
> # FindAPR and FindAPR-util are not provided by APR and APR-Util so source
> them locally
> list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/src/cmake")
>
> diff --git a/src/main/cpp/CMakeLists.txt b/src/main/cpp/CMakeLists.txt
> index 8f7d6090..213ece5a 100644
> --- a/src/main/cpp/CMakeLists.txt
> +++ b/src/main/cpp/CMakeLists.txt
> @@ -165,6 +165,6 @@ target_sources(log4cxx
>zipcompressaction.cpp
> )
> set_target_properties(log4cxx PROPERTIES
> - VERSION
> ${log4cxx_VERSION_MAJOR}.${log4cxx_VERSION_MINOR}.${log4cxx_VERSION_PATCH}
> - SOVERSION ${log4cxx_VERSION_MAJOR}
> + VERSION ${LIBLOG4CXX_LIB_VERSION}
> + SOVERSION ${LIBLOG4CXX_LIB_SOVERSION}
> )
>
> Cheers,
> --
> tobi
>
> (For avoidance of doubt, patch is licensed Apache 2.0 as the liblog4cxx
> project as well)
>
>
> > Ralph
> >
> > > On Aug 5, 2020, at 5:00 PM, Robert Middleton wrote:
> > >
> > > 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
> > >
> >
> >
--
Matt Sicker
Re: [log4cxx] Status update
On Wed, Aug 05, 2020 at 06:08:48PM -0700, Ralph Goers wrote:
> Remember, releases don’t have to be perfect. In practice, you just want them
> to hopefully be better than the prior release.
this SO-NAME bug can create some havoc down the road, especially at
distributions… So I have some interest in getting that fixed so
here's a patch as basis for discussion:
It makes cmake produces also the same SO-version. (Tested on Linux only, sorry;
do not own a windows box)
(Patch also available as PR https://github.com/apache/logging-log4cxx/pull/32)
Alternatively, log4cxx could change its versioning to match the so name
versioning…
(IOW that would mean it would go to version 11.0.0 with the next release)
That of course means retiring autotools or fixing it… (IMHO retiring would be
ok)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 2757cfe7..09254859 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -3,6 +3,11 @@ include(src/cmake/projectVersionDetails.cmake)
project(log4cxx VERSION ${log4cxx_VER} LANGUAGES CXX)
include(CTest)
+# define the SO Version of the library. Version of the log4cxx project is
subtly different than the version of the library
+# (at least in the past it was project vesion: 0.a.b.c and the library so
vesion a.b.c.0
+set(LIBLOG4CXX_LIB_VERSION
${log4cxx_VERSION_MINOR}.${log4cxx_VERSION_PATCH}.${log4cxx_VERSION_TWEAK})
+set(LIBLOG4CXX_LIB_SOVERSION ${log4cxx_VERSION_MINOR})
+
# FindAPR and FindAPR-util are not provided by APR and APR-Util so source them
locally
list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/src/cmake")
diff --git a/src/main/cpp/CMakeLists.txt b/src/main/cpp/CMakeLists.txt
index 8f7d6090..213ece5a 100644
--- a/src/main/cpp/CMakeLists.txt
+++ b/src/main/cpp/CMakeLists.txt
@@ -165,6 +165,6 @@ target_sources(log4cxx
zipcompressaction.cpp
)
set_target_properties(log4cxx PROPERTIES
- VERSION
${log4cxx_VERSION_MAJOR}.${log4cxx_VERSION_MINOR}.${log4cxx_VERSION_PATCH}
- SOVERSION ${log4cxx_VERSION_MAJOR}
+ VERSION ${LIBLOG4CXX_LIB_VERSION}
+ SOVERSION ${LIBLOG4CXX_LIB_SOVERSION}
)
Cheers,
--
tobi
(For avoidance of doubt, patch is licensed Apache 2.0 as the liblog4cxx project
as well)
> Ralph
>
> > On Aug 5, 2020, at 5:00 PM, Robert Middleton wrote:
> >
> > 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
> >
>
>
signature.asc
Description: PGP signature
Re: [log4cxx] Status update
Guten Tag Robert Middleton, am Donnerstag, 6. August 2020 um 02:00 schrieben Sie: > 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. So you have a plan what to do? Because "official release" means by a PMC, signed archives with a key available in the dist-repo beforehand etc. Do you plan to rework things? If the release-scripts I've added somewhat work, which they seem to do according your own tests, mainly three problems were left in the past: My signing key was not added to the dist-repo, I didn't know how to get things from the dist-dev-repo to the dist-repo and a vote needed to be done without introducing too much work again to redo the release entirely. My signing key has been added to the dist-repo in January. If we agree to simply release as is, because all tests pass for you on Linux and for me on Windows, a vote should easily pass without changes. This leaves the question how those things uploaded to dist-dev by the release-scripts are actually published in the dist-repo. Some PMC needs to do that? > 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? Yes, e.g. the threading related ones, but I as well would simply ignore those in favour of a release. > 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. I hope to have a closer look as well before, your mail sits on my TODO-list. 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
