Re: [log4cxx] Board report entry

[Stephen Webb]

To make it a positive statement, I would report

As a result of the result of work since the 1.2 release in January,
benchmark performance measurements show upto 60% reduction in overhead
in Log4cxx internals.


On Wed, May 1, 2024 at 1:06 AM Robert Middleton 
wrote:

> There's nothing major going on at the moment, just some various
> improvements to the code to make it more efficient.  I'm not sure if
> Stephen has anything else to add.
>
> -Robert Middleton
>
> On Tue, Apr 30, 2024 at 10:21 AM Volkan Yazıcı  wrote:
> >
> > Can a Log4cxx maintainer share what is getting cooked since March 20,
> > please? A short summary of 3-4 sentences would suffice. See the past
> reports
> >  for
> > inspiration.
>

Re: [DOC] Make use of "common" logging website pages (security, downloads etc. pp)

[Stephen Webb]

Could you explain what is meant by " standard websites"?

Is it possible/advisable to mandate "only one page to maintain" given the
different types of user (e.g. digital infrastructure maintainer, developer,
etc) and the diverse ecosystems that C++/JVM/DotNet have created?

Do a few static pages constitute a significant maintenance burden?

Is this the first step in a trend to corporatization of Apache Logging
Services away from a community of maintainers?

Thanks


On Thu, Apr 25, 2024 at 10:06 PM Apache  wrote:

> +1
>
> Ralph
>
> > On Apr 25, 2024, at 5:00 AM, Christian Grobmeier 
> wrote:
> >
> > Hi,
> >
> > By accident, I stumbled across this issue today:
> > https://github.com/apache/logging-log4cxx/issues/370
> >
> > We think we should use the standard websites across all our repositories
> as suggested.
> > This includes pages like "security", "downloads", "team" etc pp.
> >
> > I am speaking of experience by rolling out the ASF privacy policy. While
> not all projects use the foundation-wide, it has proven beneficial since
> there is only one page to maintain.
> >
> > Can we agree on this move? I think it's really important and lifts some
> maintenance burden on the sub-components.
> >
> > Btw, I also think it highlights the fact that we are indeed only ONE
> project :-)
> >
> > If there are other pages than the ones mentioned, please bring them up
> so we can unify them too.
> >
> > Regards,
> > Christian
> >
> >
> >
> > --
> > The Apache Software Foundation
> > V.P., Data Privacy
>
>

Re: [log4cxx] Release review kit

[Stephen Webb]

+1

I have:
- checked the SHA512 checksums
- checked for unexpected changes in the list of files in the 1.2.0.tar.gz
archive compared to the 1.1.0.tar.gz release archive
- built on Windows using each compressed archive (using two conan recipes)
- built and tested a suite of applications using log4cxx 1.2.0 release

.


Virus-free.www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sat, Dec 30, 2023 at 9:36 AM Volkan Yazıcı  wrote:

> Thanks for the prompt response Robert. Appreciated the pointers. Log4cxx
> docs are indeed helpful. But a little bit more guidance in the vote email
> could be helpful.
>
> See that two other people (Piotr and Matt) quickly reviewed the release
> after my email sharing the steps I followed
> . I
> think
> this vividly demonstrates my case.
>
> On Fri, Dec 29, 2023 at 4:20 PM Robert Middleton 
> wrote:
>
> > 1. staging website was in the email
> > 2/3: I use this script to verify things.  Feel free to adapt for your
> > own purposes:
> > https://gist.github.com/rm5248/b2abba4bb4f1d9cf518be49d064a0be1
> > 4. Build instructions are on the website:
> > https://logging.staged.apache.org/log4cxx/latest_stable/build-cmake.html
> >
> > Let me know if you want help on doing the build/test.  Linux is the
> > easiest, OSX should be pretty easy, and Windows can be difficult.  The
> > Github actions do a build and test for all 3 of those platforms.
> >
> > -Robert Middleton
> >
> > On Fri, Dec 29, 2023 at 4:04 AM Volkan Yazıcı  wrote:
> > >
> > > I would really appreciate a "review kit" for voting on log4cxx
> releases:
> > >
> > >1. Where is the staging website?
> > >2. How can I verify the checksum?
> > >3. How can I verify the signatures?
> > >4. How can I build and test the sources?
> > >
> > > (For inspiration, you can check out the review kit we use for
> Java-based
> > > projects
> > > <
> >
> https://github.com/apache/logging-parent/blob/main/.github/release-review-kit.txt
> > >
> > > .)
> > >
> > > Maybe there are more things I should be reviewing, but I simply don't
> > know.
> > > Hence, making your expectations clear from a review would not only help
> > > reviewers, but, IMHO, improve the engagement.
> > >
> > > -- Forwarded message -
> > > From: Robert Middleton 
> > > Date: Fri, Dec 29, 2023 at 1:01 AM
> > > Subject: [VOTE] Release log4cxx 1.2.0-RC1
> > > To: 
> > >
> > >
> > > This is a vote to release log4cxx 1.2.0-RC1.
> > >
> > > Please download, test, and cast your votes on the log4j developers
> list.
> > > [] +1, release the artifacts
> > > [] -1, don't release because...
> > >
> > > This vote will remain open for 72 hours(or more if required).
> > >
> > > All votes are welcome and we encourage everyone to test the release,
> > > but only Logging PMC votes are “officially” counted. As always, at
> > > least 3 +1 votes and more positive than negative votes are required.
> > >
> > > A quick changelog is below:
> > > * Various build failures have been fixed
> > > * Added a new Hexdump utility method to dump arbitrary memory
> > > * Fixed a segfault when shutting down and not stopping the library
> > > * QStrings may now be logged directly
> > > * The main namespace is now configurable from log4cxx to any value
> > > that is desired
> > >
> > > Tag:
> > > For a new copy do "git clone
> > > https://github.com/apache/logging-log4cxx.git; and then "git checkout
> > > tags/v1.2.0-RC1"
> > > For an existing working copy, do "git pull" and then "git checkout
> > > tags/v1.2.0-RC1"
> > >
> > > Web site: https://logging.staged.apache.org/log4cxx/latest_stable/
> > >
> > > Distribution archives:
> > > https://dist.apache.org/repos/dist/dev/logging/log4cxx/
> > >
> > > Building directions are on the website(under 'Development').  Note
> > > that APR is required to build(as well as boost if your compiler does
> > > not support C++17).
> > >
> > > -Robert Middleton
> >
>

Re: Staging website (was: [VOTE] Release Apache Log4j 2.21.0)

[Stephen Webb]

Hi Piotr,

The Log4cxx staging website URL
https://logging.staged.apache.org/log4cxx/latest_stable/usage-overview.html
now reports a 404.

The .asf.yaml contains:

staging:
  profile: ~
  whoami: asf-staging
  subdir: content/log4cxx


Do you have a suggestion as to where I can find it now?

Thanks
Stephen Webb

On Sat, Oct 14, 2023 at 1:35 AM Piotr P. Karwasz 
wrote:

> Hi Christian,
>
> On Fri, 13 Oct 2023 at 13:46, Christian Grobmeier 
> wrote:
> > Why is content not causing this issue?
> > For me both is possible, just trying to understand the best way.
>
> From what I understand, if a branch (in any repo) has a configuration:
>
> staging:
>   whoami: name_of_the_branch
>   profile: 
>   subdir: 
>
> INFRA copies the content of the branch into  of a directory
> served by Apache HTTPD. Our current merged site should look like:
>
> content/log4jphp/...Log4j PHP stuff...
> output/...Jekyll stuff...
>
> When this is done a script determines which folder is the document
> root for the server. Since we have both `content` and `output` the
> script probably fails (I don't see neither Log4PHP nor your Jekyll
> stuff).
>
> Piotr
>

Re: Apache Log4cxx 1.1.0

[Stephen Webb]

Yes, 32-bit builds should be OK. The code at line 64 should be

AppenderSkeleton(const LayoutPtr& layout);

The code at line 44 should be:

AppenderSkeleton(LOG4CXX_PRIVATE_PTR(AppenderSkeletonPrivate) priv);


Asif, is your AppenderSkeleton.h different?

On Wed, Jun 21, 2023 at 7:25 AM Gary Gregory  wrote:

> Do we even still support 32-bit builds?
>
> Gary
>
> On Tue, Jun 20, 2023, 17:09 Ghori, Asif [US] (AS) 
> wrote:
>
> > Hi
> >
> > I downloaded the Apache Log4cxx 1.1.0 and tried to compile using the
> > instructions of cmake/make file for 32 bit build.
> > I get the following error:
> >
> > Call of overloaded
> >
> 'AppenderSkeleton(std::unique_ptr > std::default_delete) is ambiguous
> >
> >
> > And than candidate listed are appenderskeleton.h line  44  and line 64.
> >
> > I searched the google and your website .. no one has mentioned this
> error.
> >
> > Please advise, Is there some flag that I am suppose to set or use. I used
> > -m32 cmake/gcc flag for 32 bit compilation on linux redhat rhel-9.0
> >
> > Thanks
> > Asif ghori
> >
>

Re: [VOTE] Release log4cxx 1.1.0-RC2

[Stephen Webb]

+1 - Built and tested using Visual Studio 2019

On Wed, May 3, 2023 at 11:43 PM Volkan Yazıcı  wrote:

> +1
>
> Verified signatures, checksums, and LICENSE/NOTICE files.
>
> On Wed, May 3, 2023 at 12:38 PM Robert Middleton 
> wrote:
>
> > This is a vote to release log4cxx 1.1.0-RC2.  The old vote is canceled.
> >
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...
> >
> > This vote will remain open for 72 hours(or more if required).
> >
> > All votes are welcome and we encourage everyone to test the release,
> > but only Logging PMC votes are “officially” counted. As always, at
> > least 3 +1 votes and more positive than negative votes are required.
> >
> > A quick changelog is below:
> > * Fix to build on Windows Server 2016
> > * Fix compiling errors with older compilers
> > * Make ODBC and SMTP opt-in instead of automatic
> > * Parameterize statements for ODBC inserts.  Add new generic
> > DBAppender class that uses APR for database support
> > * Fix Qt support
> >
> > Tag:
> > For a new copy do "git clone
> > https://github.com/apache/logging-log4cxx.git; and then "git checkout
> > tags/v1.1.0-RC2"
> > For an existing working copy, do "git pull" and then "git checkout
> > tags/v1.1.0-RC2"
> >
> > Web site: https://logging.staged.apache.org/log4cxx/next_stable/
> >
> > Distribution archives:
> > https://dist.apache.org/repos/dist/dev/logging/log4cxx/
> >
> > Building directions are on the website(under 'Development').  Note
> > that APR is required to build(as well as boost if your compiler does
> > not support C++17).
> >
> > -Robert Middleton
> >
>

Re: [VOTE] Release log4cxx 1.1.0

[Stephen Webb]

-1 I believe a bad security vulnerability was introduced by a recent commit

On Wed, 3 May 2023, 6:02 am Remko Popma,  wrote:

> +1 Remko
>
> On Wed, May 3, 2023 at 2:34 AM Thorsten Schöning 
> wrote:
>
> > Guten Tag Robert Middleton,
> > am Dienstag, 2. Mai 2023 um 13:47 schrieben Sie:
> >
> > > Please download, test, and cast your votes on the log4j developers
> list.
> > > [] +1, release the artifacts
> > > [] -1, don't release because...
> >
> > +1
> >
> > I've successfully compiled and ran tests using MS Visual Studio 17.5.5
> > 64 Bit under Windows 10 22H2 19045.2846 64 Bit.
> >
> > 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:   +49 5151-  9468- 0
> > Tel:   +49 5151-  9468-55
> > Mobil: +49  178-8 9468-04
> >
> > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789
> > Hameln
> > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
> >
> >
> > Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung.
> >
> > Mit freundlichen Grüßen,
> >
> > Thorsten Schöning
> >
> >
> > Telefon: +49 5151 9468-55
> > Fax:
> > E-Mail: tschoen...@am-soft.de
> >
> > AM-Soft IT-Service - Bitstore Hameln GmbH
> > Brandenburger Straße 7c
> > 31789 Hameln
> >
> > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> > Informationen und ist ausschliesslich für den Adressaten bestimmt.
> > Jeglicher Zugriff auf diese E-Mail durch andere Personen als den
> Adressaten
> > ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese
> E-Mail
> > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> > vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail
> > bestimmte Adressat sein, ist Ihnen jede Veröffentlichung,
> Vervielfältigung
> > oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im
> > Vertrauen auf erlangte Information untersagt.
> >
> > This e-mail may contain confidential and/or privileged information and is
> > intended solely for the addressee. Access to this email by anyone else is
> > unauthorized. If you are not the intended recipient (or have received
> this
> > e-mail in error) please notify the sender immediately and destroy this
> > e-mail. If you are not the intended recipient, any disclosure, copying,
> > distribution or any action taken or omitted to be taken in reliance on
> it,
> > is prohibited and may be unlawful.
> >
> > Hinweise zum Datenschutz: bitstore.group/datenschutz
> >
> >
> >
> >
>

Re: [VOTE] Release log4cxx 1.0.0

[Stephen Webb]

+1

I have built and tested the .zip archive using Visual Studio 2019.

I tested the .taz.gz archive with gcc 9.4 on Ubuntu

On Tue, Jan 3, 2023 at 7:37 PM Remko Popma  wrote:

> +1 Remko
>
> On Tue, Jan 3, 2023 at 4:57 PM Thorsten Schöning 
> wrote:
>
> > Guten Tag Robert Middleton,
> > am Sonntag, 1. Januar 2023 um 19:06 schrieben Sie:
> >
> > > Please download, test, and cast your votes on the log4j developers
> list.
> > > [] +1, release the artifacts
> > > [] -1, don't release because...
> >
> > +1
> >
> > I've successfully compiled and ran all tests using MS Visual Studio
> > 17.4.3 64 Bit under Windows 10 22H2 19045.2364 64 Bit.
> >
> > 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:   +49 5151-  9468- 0
> > Tel:   +49 5151-  9468-55
> > Mobil: +49  178-8 9468-04
> >
> > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789
> > Hameln
> > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
> >
> >
> > Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung.
> >
> > Mit freundlichen Grüßen,
> >
> > Thorsten Schöning
> >
> >
> > Telefon: +49 5151 9468-55
> > Fax:
> > E-Mail: tschoen...@am-soft.de
> >
> > AM-Soft IT-Service - Bitstore Hameln GmbH
> > Brandenburger Straße 7c
> > 31789 Hameln
> >
> > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> > Informationen und ist ausschliesslich für den Adressaten bestimmt.
> > Jeglicher Zugriff auf diese E-Mail durch andere Personen als den
> Adressaten
> > ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese
> E-Mail
> > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> > vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail
> > bestimmte Adressat sein, ist Ihnen jede Veröffentlichung,
> Vervielfältigung
> > oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im
> > Vertrauen auf erlangte Information untersagt.
> >
> > This e-mail may contain confidential and/or privileged information and is
> > intended solely for the addressee. Access to this email by anyone else is
> > unauthorized. If you are not the intended recipient (or have received
> this
> > e-mail in error) please notify the sender immediately and destroy this
> > e-mail. If you are not the intended recipient, any disclosure, copying,
> > distribution or any action taken or omitted to be taken in reliance on
> it,
> > is prohibited and may be unlawful.
> >
> > Hinweise zum Datenschutz: bitstore.group/datenschutz
> >
> >
> >
> >
>

Re: [log4cxx] Next steps / release?

[Stephen Webb]

I think the next_stable branch should be released now.

I am not aware of any issue that would prevent a release.

I will do some more tests with production code this weekend to ensure there
is no anything I have missed.

On Fri, Dec 30, 2022 at 9:21 AM Robert Middleton 
wrote:

> With some fixes that have been accomplished over the past few weeks,
> we now have only 1-2 issues in JIRA that would need to be finished for
> a release, and I think both of those are effectively done at this
> point.
>
> I'm pretty happy with where things are at the moment - there's always
> more tweaking that can be done, but I can't think of anything major
> that needs to be done that could be done within a reasonable
> timeframe.  The major thing that was done for the next release was to
> make things ABI stable, so as long as we commit to that going
> forward(and only breaking it with proper versioning) we should be
> good.
>
> The last time we talked about this Tobias Frost said that the
> soft-freeze for Debian is the 12th of January[1], so after that point
> an updated library wouldn't make it into Debian.  I would like to get
> this version into Debian if possible(as that is the distribution I
> use), but that depends on Tobias' availability.
>
> With that in mind, should we do a release in the immediate
> future(within the next ~7 days), or should we wait a bit for some more
> tweaking and/or features?
>
> -Robert Middleton
>
> [1]: https://lists.apache.org/thread/zg150rbkdkzgog1bnd403052818nncs7
>

Re: [log4cxx] Stacktrace support

[Stephen Webb]

I am not able to think of any use-case where filtering the stacktrace data
would be useful.

It is already possible to put the stacktrace into the log using C++ streams
- boost stacktrace provides

std::basic_ostream< CharT, TraitsT > &
  operator<<(std::basic_ostream< CharT, TraitsT > & os,
 const basic_stacktrace
<
Allocator > & bt);


On Fri, Dec 16, 2022 at 2:39 PM Robert Middleton 
wrote:

> I've been working on adding in stacktrace support to Log4cxx using
> Boost stacktrace.  One of my objectives with this is to make this
> entirely optional, such that both Log4cxx needs to have support for
> Boost stacktrace and the client code needs to enable it, so by default
> a stacktrace is not collected.
>
> In order to do this, I've somewhat simplified the logger methods, so
> where it was two methods:
> void forcedLog(const LevelPtr& level,
> const std::string& message,
> const log4cxx::spi::LocationInfo& location);
> void forcedLog(const LevelPtr& level,
> const std::string& message);
>
> I've converted it into one method:
> void forcedLog(const LevelPtr& level,
> const std::string& message,
> const log4cxx::spi::LocationInfo& location =
> log4cxx::spi::LocationInfo::getLocationUnavailable(),
> const log4cxx::OptionalLogParams& optionalParams =
> log4cxx::OptionalLogParams()) const;
>
> The 'optional params' here being effectively just a map that we can
> throw more pointers into if we need to add more information at a later
> point.
>
> This seems like the most reasonable way to prevent a method
> explosion(adding more method overloads).
>
> I'm not sure if this is the best way to go though and was wondering if
> anybody had any better ideas.  There are a few options that I was
> thinking of:
> 1. Throw the stacktrace string into the (already-existing) MDC and
> letting users do something like %X{stacktrace}  to print the value
> 2. Add more method overloads to the Logger class to take in the
> stacktrace(when available) so the logging event has a copy of the
> stacktrace
> 3. Use a map to pass optional void* pointers to the Logger, so that we
> avoid an explosion of overridden methods while still keeping a copy of
> the stacktrace
>
> I'm wondering if I'm overthinking this - my original concern was to
> have a copy of the stacktrace so that you could eventually do some
> kind of filtering with the stacktrace data, but upon thinking about it
> more I don't know when you would ever have to do that, especially
> since the stacktrace is really only useful if you have a debug build.
> Am I right in overthinking this?  Is there something much simpler that
> I'm missing?
>
> -Robert Middleton
>

Re: [log4cxx] fmt compiling/linking issue

[Stephen Webb]

Fmt seems to have a formatter for std::chrono::time_point templated by
std::chrono::system_clock and (optionally) std::chrono::utc_clock if my
interpretation of the fmt/chrono.h code in the https://github.com/fmtlib
master branch is correct.

Quoting from https://en.cppreference.com/w/cpp/chrono/high_resolution_clock
>
> It may be an alias of std::chrono::system_clock
> <https://en.cppreference.com/w/cpp/chrono/system_clock> or
> std::chrono::steady_clock
> <https://en.cppreference.com/w/cpp/chrono/steady_clock>, or a third,
> independent clock.


On Sun, Nov 27, 2022 at 2:14 AM Robert Middleton 
wrote:

> Odd.  How would we format the timestamp in that case?  According to
> the documentation, fmt has formatters for std::chrono::time_point
> already.
>
> Is this some sort of difference between MSVC and gcc?  It should be
> trying to format
> std::chrono::time_point, which I
> thought was std::chrono::system_clock instead of steady_clock.
>
> -Robert Middleton
>
>
> On Fri, Nov 25, 2022 at 11:03 PM Stephen Webb  wrote:
> >
> >  In Visual studio 2019 the line
> >
> > fmt::arg("d", event->getChronoTimeStamp()),
> >
> >
> > causes the compile time error:
> >
> > error C2338: Cannot format an argument. To make type T formattable
> provide
> > a formatter specialization: https://fmt.dev/latest/api.html#udt
> >
> >
> > It seems to need a formatter  specialization for
> > std::chrono::steady_clock::time_point.
> >
> > The branch build OK with the above line commented out.
> >
> > On Sat, Nov 26, 2022 at 2:13 AM Robert Middleton 
> > wrote:
> >
> > > I've been working on LOGCXX-514(using fmt as an alternative layout to
> > > the PatternLayout) and I've got a working implementation on Linux.
> > > However, the Windows build currently fails with some sort of symbol or
> > > linking error.  Since I'm not all that familiar with Windows, would
> > > somebody with more experience on the Windows side be able to take a
> > > look at it?
> > >
> > > I suspect that this could also be something to do with the wchar on
> > > Windows, but it is not clear to me if that is the case or not.
> > >
> > > -Robert Middleton
> > >
>

Re: [log4cxx] fmt compiling/linking issue

[Stephen Webb]

 In Visual studio 2019 the line

fmt::arg("d", event->getChronoTimeStamp()),


causes the compile time error:

error C2338: Cannot format an argument. To make type T formattable provide
a formatter specialization: https://fmt.dev/latest/api.html#udt


It seems to need a formatter  specialization for
std::chrono::steady_clock::time_point.

The branch build OK with the above line commented out.

On Sat, Nov 26, 2022 at 2:13 AM Robert Middleton 
wrote:

> I've been working on LOGCXX-514(using fmt as an alternative layout to
> the PatternLayout) and I've got a working implementation on Linux.
> However, the Windows build currently fails with some sort of symbol or
> linking error.  Since I'm not all that familiar with Windows, would
> somebody with more experience on the Windows side be able to take a
> look at it?
>
> I suspect that this could also be something to do with the wchar on
> Windows, but it is not clear to me if that is the case or not.
>
> -Robert Middleton
>

Re: [log4cxx] Github windows builds

[Stephen Webb]

There are 3(logchar type) x 4(charset type) x 2(unichar?) x 2(wchar_t?) x
2(prefer_boost?) x 2(qt_support?) =192 combinations of build options
log4cxx provides of which only one is being tested.

What should we do with those?


On Fri, Oct 28, 2022 at 12:23 PM Robert Middleton 
wrote:

> Upon further investigation, it appears as though it was the cache
> functionality that broke. Updating from v2 to v3 seems to have fixed
> the problem.  It looks like when you updated vcpkg to the latest
> version that fixed it for one build, probably because the yml file
> changed or something?
>
> Anyway, it's fixed now.  Are there any other configurations that we
> should test for while I'm making updates?
>
> -Robert Middleton
>
> On Thu, Oct 27, 2022 at 1:37 AM Stephen Webb  wrote:
> >
> > It works using a more recent version of vcpkg - not sure what the issue
> > with the old version is.
> >
> > On Thu, Oct 27, 2022 at 1:41 PM Robert Middleton 
> > wrote:
> >
> > > I've been adding some more builds for log4cxx(to test more
> > > combinations of features and stuff) but I seem to have broken the
> > > windows build - cmake can't find APR with the .pc file.  It seems that
> > > whatever we had before cached had the .pc files in it, but trying to
> > > rebuild clean(no cache) does not have .pc files in it to find the
> > > library.
> > >
> > > I'm thinking that this may have had something to do with the recent
> > > changes to how we find APR, but I'm not much of a Windows guy so it
> > > could take me a while to figure out what exactly is broken.  I know
> > > that Steven Webb uses vcpkg, would you be able to take a look at it
> > > and figure out why it might be failing?
> > >
> > > The branch in question:
> > > https://github.com/apache/logging-log4cxx/tree/LOGCXX-562
> > >
> > > -Robert Middleton
> > >
>

Re: [log4cxx] Github windows builds

[Stephen Webb]

It works using a more recent version of vcpkg - not sure what the issue
with the old version is.

On Thu, Oct 27, 2022 at 1:41 PM Robert Middleton 
wrote:

> I've been adding some more builds for log4cxx(to test more
> combinations of features and stuff) but I seem to have broken the
> windows build - cmake can't find APR with the .pc file.  It seems that
> whatever we had before cached had the .pc files in it, but trying to
> rebuild clean(no cache) does not have .pc files in it to find the
> library.
>
> I'm thinking that this may have had something to do with the recent
> changes to how we find APR, but I'm not much of a Windows guy so it
> could take me a while to figure out what exactly is broken.  I know
> that Steven Webb uses vcpkg, would you be able to take a look at it
> and figure out why it might be failing?
>
> The branch in question:
> https://github.com/apache/logging-log4cxx/tree/LOGCXX-562
>
> -Robert Middleton
>

Re: [log4cxx] JIRA Updates and next release?

[Stephen Webb]

I just went through the differences between master and rel/v0.13.0 and the
only significant fix I saw in master was the crash in a statically linked
log4cxx library.

While I am not familiar with the amount of work required to create a
release (it looks like a lot), I wonder if there are enough changes in
master to justify the work of creating a release.

On Tue, Sep 27, 2022 at 11:02 AM Robert Middleton 
wrote:

> On Mon, Sep 26, 2022 at 5:09 AM Thorsten Schöning 
> wrote:
> > > * Having better error reporting - many exceptions that are thrown are
> > > basically swallowed and just print out to stderr at the moment.  Come
> > > to think of it, do we even want exceptions?  It seems like a bad idea
> > > for the logging framework to throw exceptions
> >
> > What else do you have in mind, some error handlers and callbacks?
> > Throwing and swallowing at some point doesn't sound that bad, as long
> > as the problem is visible somewhere. Logback pretty mich logs on
> > STDERR or STDOUT only as well.
> >
>
> Yes, error handling and/or callbacks to notify the user.  There are
> certain situations where there isn't much useful information available
> unless you're looking at STDERR, and even sometimes that information
> is pretty useless.  For example, if you try to use the DOMConfigurator
> and the file isn't found, the only way for you to tell that something
> went wrong is to view the output of the process; this should probably
> return a bool or something to indicate that the configuration was
> successful or not.
>
> And then there's the incredibly unhelpful error message of "please
> initialize the log4cxx system properly" which should probably print
> out a bit more as to what it tried to do and why it failed.
>
> -Robert Middleton
>

Re: [log4j] Default configuration for 3.x

[Stephen Webb]

I recall my difficulties (many years ago), when first incorporating
logging, working out what was a "good" logging configuration. I would have
really appreciated a good out-of the box default.

Now I think that the out-of-the box default should be
* A root logger set to INFO
* A rolling appender logged to a file in the working directory
* Some examples of how to configure named loggers in comments

On Tue, Jun 14, 2022 at 4:55 AM Matt Sicker  wrote:

> Structured logging can look like syslog, JSON, or even like a properties
> file (for each event). The idea being that instead of merely a log string,
> there are key/value pairs to better detail the state being logged.
>
> —
> Matt Sicker
>
> > On Jun 13, 2022, at 13:20, Gary Gregory  wrote:
> >
> > Let me relate the path we took with some of our products. Ages ago, we
> > started by logging just to the console, then customers would ask for help
> > and we'd ask for logs, sometimes we got back a copy-paste, other times a
> > screenshot, nothing helpful, so we then gave the users steps to enable
> file
> > logging and they would send us that. These days, most of our products are
> > configured out of the box with console and rolling file logging, and the
> > only reason we loop with a customer is to get more with debug or trace
> > level logging for some loggers.
> >
> > All of that to say that for us, a sensible default, is a configuration
> that
> > let's users send us a file or a zipped folder of log files.
> >
> > I'm worried that something "structured" beyond text or a CSV would be an
> > extra complication for support or development to easily "see" what is
> > going on
> >
> > Gary
> >
> >> On Mon, Jun 13, 2022, 12:57 Matt Sicker  wrote:
> >>
> >> Hey all, I was thinking we should figure out a more appropriate default
> >> configuration for 3.0. One idea I have would be to use a structured
> format
> >> by default along with more emphasis on using either audit events or
> >> messages to log structured data more directly.
> >>
> >> Besides that, there are other options we could enable by default that
> were
> >> added after 2.0 that increase performance. I’d almost be inclined to
> >> default to async logging, too, but that might be surprising behavior if
> we
> >> have to do that based on an optional module at runtime.
> >>
> >> We could investigate the various best practices everyone has developed
> >> over time for parsing and searching logs to use a default layout that
> works
> >> most efficiently there. For example, timestamps would use a fairly fixed
> >> width format (one of the full ISO 8601 formats that doesn’t use the
> month
> >> name, day name, or time zone name, as those are all varying width),
> sorting
> >> fields if needed, etc.
> >>
> >> As a bonus idea, we could also define some useful “standard” keys for
> >> ThreadContext like TraceId, SpanId, RequestId, etc. Basically, make it
> more
> >> obvious that you can enable distributed trace logging without a gigantic
> >> OpenTelemetry or Zipkin dependency stack (on the producing side; feel
> free
> >> to use whatever for collecting the spans).
> >>
> >> —
> >> Matt Sicker
>

Re: [General] What is logging?

[Stephen Webb]

Good job Robert. It frustrates me that the (essential) importance of
logging is not emphasised sufficiently in introductory software
engineering. This is a help towards getting the message out.

My suggestion would be to mention runtime configuration of filtering and
enabling of loggers earlier in the explanation. This is the essential
element that distinguishes a logging framework from printf etc.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Jun 12, 2022 at 2:43 AM Robert Middleton 
wrote:

> Since I have encountered a few people people before who have asked
> questions along the lines of "why do we need good logging? and what is
> logging?" I figured it would be good to make a general overview guide
> that is not specific to log4j/log4cxx/log4net, but may still touch on
> concepts of these libraries that make them good.
>
> Some of the terminology here could probably be better standardized, so
> any suggestions are welcome!  I may turn this into a presentation to
> break it up as well, I haven't decided yet.
>
> Github PR: https://github.com/apache/logging-site/pull/1
>
> -Robert Middleton
>

Re: [VOTE] Release log4cxx 0.13.0

[Stephen Webb]

+1

I tested 0.13.0 on Ubuntu and Windows - all OK

On Sat, Apr 16, 2022 at 7:47 PM Thorsten Schöning 
wrote:

> Guten Tag Robert Middleton,
> am Samstag, 16. April 2022 um 03:00 schrieben Sie:
>
> > This is a vote to release log4cxx 0.13.0.
>
> +1
>
> Mit freundlichen Grüßen
>
> Thorsten Schöning
>
> --
> AM-SoFT IT-Service - Bitstore Hameln GmbH
> Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK
>
> E-Mail: thorsten.schoen...@am-soft.de
> Web:http://www.AM-SoFT.de/
>
> Tel:   05151-  9468- 0
> Tel:   05151-  9468-55
> Fax:   05151-  9468-88
> Mobil:  0178-8 9468-04
>
> AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789
> Hameln
> AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
>
>
> Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
>
> Telefon: +49 (0)515 94 68 - 0
> Fax:
> E-Mail: tschoen...@am-soft.de
>
> AM-Soft IT-Service - Bitstore Hameln GmbH
> Brandenburger Straße 7c
> 31789 Hameln
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen und ist ausschliesslich für den Adressaten bestimmt.
> Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten
> ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail
> bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung
> oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im
> Vertrauen auf erlangte Information untersagt.
>
> This e-mail may contain confidential and/or privileged information and is
> intended solely for the addressee. Access to this email by anyone else is
> unauthorized. If you are not the intended recipient (or have received this
> e-mail in error) please notify the sender immediately and destroy this
> e-mail. If you are not the intended recipient, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance on it,
> is prohibited and may be unlawful.
>
> Hinweise zum Datenschutz: bitstore.group/datenschutz
>
>
>
>

Re: [log4cxx] next_stable and other fixes

[Stephen Webb]

Once the branches diverge, git cherry-pick is the better merge process.

On Tue, Jan 4, 2022 at 11:06 AM Robert Middleton 
wrote:

> Just as a note to all, what I've been doing with next_stable is to
> periodically merge master back in once I make fixes on master(assuming
> that those fixes are common to both).  Unfortunately with the
> multithreaded speed fix this has resulted in a moderately sized merge
> conflict.  I think I've fixed everything to work properly at this
> point.
>
> What should our workflow be?  Is there a better way?  Obviously there
> are certain things that would only target next_stable and not master,
> so I'm not thinking about those cases for this.
>
> -Robert Middleton
>

Re: [log4cxx] Short filename options

[Stephen Webb]

This is already provided by
```
#define LOG4CXX_LOCATION ::log4cxx::spi::LocationInfo()
#include 
```

On Sun, Jan 2, 2022 at 12:38 PM Robert Middleton 
wrote:

> The full path is already in the compiled code anyway, this would
> simply add the ability to get the filename from the full path(so
> another member to the LocationInfo class).  I can see certain
> circumstances where it is useful to have the full path, for example
> when you have two files named the same(please don't do this).
>
> That does bring up a good point though, is that if you don't want
> location info compiled in, we should have a preprocessor macro that
> will compile out all of the location info data.  We can already
> compile out log messages of certain levels, so hiding the location is
> just a natural extension of that.
>
> -Robert Middleton
>
> On Sat, Jan 1, 2022 at 7:50 PM Stephen Webb  wrote:
> >
> > I prefer option 2 if it is possible.
> >
> > I do not think it is useful to have the full path name (of the build
> > directory) in shipped binaries.
> >
> > On Sun, Jan 2, 2022 at 7:11 AM Robert Middleton 
> > wrote:
> >
> > > PR #75 adds a new option for displaying the short filename of the log
> > > location, which is probably a good idea to have, as in my experience,
> > > the whole path of the file is not that useful, especially when the
> > > binary is from a build server where the path is something like
> > > /var/lib/jenkins/project-name/src/main/directory/foo.cpp.
> > >
> > > The current PR does this with some string manipulation at runtime, and
> > > is different from the const char* that is currently used, so it
> > > doesn't fit that well with the rest of the class.  Since C++11 we can
> > > now do constexpr functions, so we should be able to do this at compile
> > > time(assuming you have optimizations turned on of course).
> > >
> > > We can do this one of several ways:
> > > 1. Take the PR as is(use strings and calculate at runtime)
> > > 2. Create a constexpr function that we control to calculate the
> > > filename at compile time as either an offset into the filename or a
> > > separate const char*.  The advantage to this is that it doesn't
> > > require any other libraries for pre-C++17 compilers.
> > > 3. Use std::string_view(for C++17) or boost::string_view(pre-c++17).
> > > The following would work for this solution:
> > > std::string_view str{"/foo/bar/what.cpp"};
> > > const int location = str.find_last_of( '/' ) + 1;
> > > printf( "fullPath: %s\n", str.data() );
> > > printf( "fileName: %s\n", [location] );
> > >
> > > Does anybody have a preference or a better way to do it?  I'm inclined
> > > to go with (3), since that does provide a good fallback for compilers
> > > that don't support C++17, and only requires boost for older compilers.
> > >
> > > -Robert Middleton
> > >
>

Re: [log4cxx] Short filename options

[Stephen Webb]

I prefer option 2 if it is possible.

I do not think it is useful to have the full path name (of the build
directory) in shipped binaries.

On Sun, Jan 2, 2022 at 7:11 AM Robert Middleton 
wrote:

> PR #75 adds a new option for displaying the short filename of the log
> location, which is probably a good idea to have, as in my experience,
> the whole path of the file is not that useful, especially when the
> binary is from a build server where the path is something like
> /var/lib/jenkins/project-name/src/main/directory/foo.cpp.
>
> The current PR does this with some string manipulation at runtime, and
> is different from the const char* that is currently used, so it
> doesn't fit that well with the rest of the class.  Since C++11 we can
> now do constexpr functions, so we should be able to do this at compile
> time(assuming you have optimizations turned on of course).
>
> We can do this one of several ways:
> 1. Take the PR as is(use strings and calculate at runtime)
> 2. Create a constexpr function that we control to calculate the
> filename at compile time as either an offset into the filename or a
> separate const char*.  The advantage to this is that it doesn't
> require any other libraries for pre-C++17 compilers.
> 3. Use std::string_view(for C++17) or boost::string_view(pre-c++17).
> The following would work for this solution:
> std::string_view str{"/foo/bar/what.cpp"};
> const int location = str.find_last_of( '/' ) + 1;
> printf( "fullPath: %s\n", str.data() );
> printf( "fileName: %s\n", [location] );
>
> Does anybody have a preference or a better way to do it?  I'm inclined
> to go with (3), since that does provide a good fallback for compilers
> that don't support C++17, and only requires boost for older compilers.
>
> -Robert Middleton
>

Re: [log4cxx] How to run the throughput test?

[Stephen Webb]

On Windows, I manually copied troughputtests.exe to the installation
directory (so log4cxx.dll is in the same directory).

Perhaps it should be installed by cmake when BUILD_THROUGHPUT_TESTS is on.

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Dec 30, 2021 at 10:25 AM Robert Middleton 
wrote:

> After taking a look at this, maybe the best option is to add the
> throughput as a unit test so that we can set the path the same as the
> other unit tests?  If it is not added as a unit test it won't be
> run(which is good), but if we enable the option it will run.  You can
> also run individual tests through visual studio, so that might solve
> the problem.  Looking at the CMakeLists.txt, it doesn't actually do
> anything with the path that it calculates, it's only building the exe.
>
> I did try to add a custom target, but that does not let you set the
> environment(which needs to be set for us to load the required DLLs
> from the PATH).
>
> -Robert Middleton
>
> On Wed, Dec 29, 2021 at 5:27 PM Stephen Webb  wrote:
> >
> > That looks like a cmake issue - could you try cmake version 3.22?
> >
> > I am still using Visual Studio 2019 Community Edition.
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > Virus-free.
> > www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > On Thu, Dec 30, 2021 at 4:30 AM Robert Middleton 
> > wrote:
> >
> > > Perhaps we need to add a custom target to CMake to make it runnable?
> > > I think that would then hook into visual studio to make it easy to
> > > run; I'll try to take a look at it tonight.
> > >
> > > The part of the CMakeLists.txt file that does that was copy
> > > from one directory up, so it could be a directory level issue that I
> > > missed.
> > >
> > > -Robert Middleton
> > >
> > > On Wed, Dec 29, 2021 at 7:15 AM Thorsten Schöning <
> tschoen...@am-soft.de>
> > > wrote:
> > > >
> > > > Hi everyone,
> > > >
> > > > I just tried to run the throughput test: Installed FMT using VCPKG,
> > > > changed CMAKE to option that test ON and things built successfully.
> > > > Though, running fails because log4cxx.dll can't be found. In theory
> > > > CMAKE should already handle that using the following line:
> > > >
> > > > > set(LOG4CXX_DLL_DIR "$>;")
> > > >
> > > > Though, doesn't seem to work for my Windows and Visual Studio 2022.
> > > > The actual path of that DLL is the following:
> > > >
> > > > > [...]\master\src\out\build\x64-Debug\src\main\cpp\log4cxx.dll
> > > >
> > > > Using PROCMON I can see that the test tries to load the file from the
> > > > following LOG4CXX-specific directories instead:
> > > >
> > > > >
> > >
> [...]\master\src\out\build\x64-Debug\src\test\cpp\throughput\log4cxx.dll
> > > > >
> [...]\master\src\out\build\x64-Debug\src\test\cpp\helpers\log4cxx.dll
> > > >
> > > > Looking at the CMAKE file this somewhat makes sense, because at least
> > > > the first line is the target directory of the throughput test.
> > > >
> > > > How is your setup? Do you manually copy the DLL or are executing the
> > > > throughput test differently and Visual Studio makes a difference
> here?
> > > >
> > > > Mit freundlichen Grüßen
> > > >
> > > > Thorsten Schöning
> > > >
> > > > --
> > > > AM-SoFT IT-Service - Bitstore Hameln GmbH
> > > > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT
> und
> > > TK
> > > >
> > > > E-Mail: thorsten.schoen...@am-soft.de
> > > > Web:http://www.AM-SoFT.de/
> > > >
> > > > Tel:   05151-  9468- 0
> > > > Tel:   05151-  9468-55
> > > > Fax:   05151-  9468-88
> > > > Mobil:  0178-8 9468-04
> > > >
> > > > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c,
> 31789
> > > Hameln
> > > > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
> > > >
> > > >
> > > >
> > > >
> > >
>

Re: [log4cxx] How to run the throughput test?

[Stephen Webb]

That looks like a cmake issue - could you try cmake version 3.22?

I am still using Visual Studio 2019 Community Edition.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Dec 30, 2021 at 4:30 AM Robert Middleton 
wrote:

> Perhaps we need to add a custom target to CMake to make it runnable?
> I think that would then hook into visual studio to make it easy to
> run; I'll try to take a look at it tonight.
>
> The part of the CMakeLists.txt file that does that was copy
> from one directory up, so it could be a directory level issue that I
> missed.
>
> -Robert Middleton
>
> On Wed, Dec 29, 2021 at 7:15 AM Thorsten Schöning 
> wrote:
> >
> > Hi everyone,
> >
> > I just tried to run the throughput test: Installed FMT using VCPKG,
> > changed CMAKE to option that test ON and things built successfully.
> > Though, running fails because log4cxx.dll can't be found. In theory
> > CMAKE should already handle that using the following line:
> >
> > > set(LOG4CXX_DLL_DIR "$>;")
> >
> > Though, doesn't seem to work for my Windows and Visual Studio 2022.
> > The actual path of that DLL is the following:
> >
> > > [...]\master\src\out\build\x64-Debug\src\main\cpp\log4cxx.dll
> >
> > Using PROCMON I can see that the test tries to load the file from the
> > following LOG4CXX-specific directories instead:
> >
> > >
> [...]\master\src\out\build\x64-Debug\src\test\cpp\throughput\log4cxx.dll
> > > [...]\master\src\out\build\x64-Debug\src\test\cpp\helpers\log4cxx.dll
> >
> > Looking at the CMAKE file this somewhat makes sense, because at least
> > the first line is the target directory of the throughput test.
> >
> > How is your setup? Do you manually copy the DLL or are executing the
> > throughput test differently and Visual Studio makes a difference here?
> >
> > Mit freundlichen Grüßen
> >
> > Thorsten Schöning
> >
> > --
> > AM-SoFT IT-Service - Bitstore Hameln GmbH
> > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und
> TK
> >
> > E-Mail: thorsten.schoen...@am-soft.de
> > Web:http://www.AM-SoFT.de/
> >
> > Tel:   05151-  9468- 0
> > Tel:   05151-  9468-55
> > Fax:   05151-  9468-88
> > Mobil:  0178-8 9468-04
> >
> > AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789
> Hameln
> > AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
> >
> >
> >
> >
>

Re: [log4cxx] CI Benchmarking

[Stephen Webb]

It occurs to me that a better approach might be to run two benchmark
versions in the same job and compare the results.

A 'good' reference version artifact could be downloaded and compared with
the new version.

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Dec 29, 2021 at 6:42 AM Matt Sicker  wrote:

> I think the action approach is sufficient for now. If we can get a
> dedicated GHA runner or similar, we can eventually move the benchmarks to a
> dedicated machine and still use the same API.
> --
> Matt Sicker
>
> > On Dec 28, 2021, at 13:39, Robert Middleton 
> wrote:
> >
> > I think adding it to github actions(while certainly not ideal) is at
> > least a step in the right direction.  If/when we have dedicated
> > hardware to test it properly, we can then migrate it over.  At least
> > having it setup to start with should make migration easier, plus even
> > if it's not super consistent we should at least be able to get a rough
> > order of magnitude over dozens of builds.
> >
> > -Robert Middleton
> >
> > On Tue, Dec 28, 2021 at 7:30 AM Volkan Yazıcı  wrote:
> >>
> >> Agreed with your remarks regarding the unreliability of benchmark
> results
> >> in the cloud. See my proposal in private@ to get some machines for
> >> continuous benchmarks.
> >>
> >> On Tue, Dec 28, 2021 at 10:17 AM Dominik Psenner 
> wrote:
> >>
> >>> Hi Stephen,
> >>>
> >>> The trouble with benchmarks in CI is that the numbers may be largely
> >>> unreliable, depending mostly on the hardware where it runs and in
> general
> >>> the surrounding environment. Chances are high that the benchmarks will
> not
> >>> produce comparable results.
> >>>
> >>> It would however be good to provide some tools to run the (same)
> benchmarks
> >>> manually.
> >>>
> >>> When run on the same hardware with different codebases or on different
> >>> hardware with the same codebase, the outcome may provide interesting
> and
> >>> comparable insights.
> >>>
> >>> Warm regards
> >>> --
> >>> Sent from my phone. Typos are a kind gift to anyone who happens to find
> >>> them.
> >>>
> >>> On Tue, Dec 28, 2021, 07:46 Stephen Webb  wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Robert has created a benchmark that I thought would be nice to
> integrate
> >>>> into CI.
> >>>>
> >>>> I see the Log4J has some benchmarks actions which are currently run
> >>>> manually with results posted to github pages.
> >>>>
> >>>> Do you consider this a useful/optimal approach?
> >>>>
> >>>> Would an threshold which an action could check for each PR be useful?
> >>>>
> >>>> Regards
> >>>> Stephen Webb
> >>>>
> >>>> <
> >>>>
> >>>
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >>>>>
> >>>> Virus-free.
> >>>> www.avast.com
> >>>> <
> >>>>
> >>>
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >>>>>
> >>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >>>>
> >>>
>
>

[log4cxx] CI Benchmarking

[Stephen Webb]

Hi,

Robert has created a benchmark that I thought would be nice to integrate
into CI.

I see the Log4J has some benchmarks actions which are currently run
manually with results posted to github pages.

Do you consider this a useful/optimal approach?

Would an threshold which an action could check for each PR be useful?

Regards
Stephen Webb

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: [VOTE] Release log4cxx 0.12.0-RC2

[Stephen Webb]

+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 
> 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

[Stephen Webb]

+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
>

Re: [log4cxx] Release Prep

[Stephen Webb]

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  >
> > 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

[Stephen Webb]

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

[Stephen Webb]

> Or maybe we just need something like LOG4CXX_SOURCE_DIR?

yes, I like that idea - something we control.


Virus-free.
www.avast.com

<#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
>

Re: [log4cxx] Release Prep

[Stephen Webb]

Hi Robert,

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.

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] Site / Release?

[Stephen Webb]

The doxygen style is looking a bit old now - could we move to Doxygen +
Breath + Sphinx?

Here is a old resource walking through the process of integrating into
CMake:
https://devblogs.microsoft.com/cppblog/clear-functional-c-documentation-with-sphinx-breathe-doxygen-cmake/



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Dec 27, 2020 at 5:11 AM Robert Middleton 
wrote:

> 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 version

[Stephen Webb]

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

[Stephen Webb]

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] Release Testing

[Stephen Webb]

Hi Thorsten,

Would you consider a PR that updated the failing tests with code to check
for the required programmes?

We could then output a failure message that informed the user why the test
does not work.

On Fri, Jul 17, 2020 at 8:57 PM 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
>
>

Re: [log4cxx] Release Testing

[Stephen Webb]

Hi Ralph,

Change your current directory to the cmake build directory (the directory
with CMakeCache.txt) before running ctest.

On Thu, Jul 16, 2020 at 1:33 AM Ralph Goers 
wrote:

> I found ctest at target/dependency/cmake/bin but when I run it I get
>
> No tests were found!!!
>
> I don’t see a directory named “package” so I am assuming you meant
> something else.
>
> Ralph
>
> > On Jul 14, 2020, at 11:56 PM, Stephen Webb  wrote:
> >
> > Could you re-run that test by typing
> >
> > ctest -R streamtestcase --output-on-failure
> >
> > in the build directory (in package if you used maven to build)
> >
> > On Wed, Jul 15, 2020 at 4:37 PM Ralph Goers 
> > wrote:
> >
> >> I should add that the while there is nothing that mandates the PMC
> require
> >> builds to pass to approve a release, it would be unusual to approve one
> >> where building on supported platforms fail without understanding whether
> >> the test failures are critical or not. That said, I don’t see anyplace
> on
> >> the log4cxx web site that even states what platforms it supports. I
> guess I
> >> would assume it would be expected to run any place apr is supported?
> >>
> >> Ralph
> >>
> >>> On Jul 14, 2020, at 11:31 PM, Ralph Goers 
> >> wrote:
> >>>
> >>> After adding that directory to the path as well as the corresponding
> >> apr-util directory I was able to get the build to run. Everything
> >> successfully compiled but I got 1 test failure.
> >>>
> >>> Start 19: streamtestcase
> >>> 19/60 Test #19: streamtestcase .........***Exception:
> >> SegFault  2.00 sec
> >>>
> >>>
> >>> Ralph
> >>>
> >>>> On Jul 14, 2020, at 11:22 PM, Ralph Goers  >
> >> wrote:
> >>>>
> >>>> Yes, it is at /usr/local/Cellar/apr/1.7.0/libexec/bin/.
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On Jul 14, 2020, at 11:14 PM, Stephen Webb 
> >> wrote:
> >>>>>
> >>>>> Hi Ralph,
> >>>>>
> >>>>> Could you tell me if your Mac has the script "apr-1-config"
> installed?
> >>>>>
> >>>>> The src/cmake/FindApr.cmake in log4cxx expects the apr installation
> to
> >>>>> create that script and it calls it (passing --includedir) to
> >>>>> set APR_INCLUDE_DIR with the output
> >>>>>
> >>>>> On Wed, Jul 15, 2020 at 3:57 PM Ralph Goers <
> >> ralph.go...@dslextreme.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I don’t see anything wrong with those files. They are the same two
> >>>>>> archives provided in the last release.
> >>>>>>
> >>>>>> I tried building them on my Mac but it gets an error
> >>>>>>
> >>>>>> CMake Error at
> >>>>>>
> >>
> target/dependency/cmake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146
> >>>>>> (message):
> >>>>>> APR_INCLUDE_DIR (missing: APR_LIBRARIES)
> >>>>>>
> >>>>>> I have previous done a brew install apr and brew install apr-util
> but
> >> I
> >>>>>> don’t have an APR_INCLUDE_DIR environment variable set and I
> wouldn’t
> >> know
> >>>>>> where to point it to.
> >>>>>>
> >>>>>> Ralph
> >>>>>>
> >>>>>>> On Jul 14, 2020, at 7:16 PM, Robert Middleton  >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> 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

[Stephen Webb]

Could you re-run that test by typing

ctest -R streamtestcase --output-on-failure

in the build directory (in package if you used maven to build)

On Wed, Jul 15, 2020 at 4:37 PM Ralph Goers 
wrote:

> I should add that the while there is nothing that mandates the PMC require
> builds to pass to approve a release, it would be unusual to approve one
> where building on supported platforms fail without understanding whether
> the test failures are critical or not. That said, I don’t see anyplace on
> the log4cxx web site that even states what platforms it supports. I guess I
> would assume it would be expected to run any place apr is supported?
>
> Ralph
>
> > On Jul 14, 2020, at 11:31 PM, Ralph Goers 
> wrote:
> >
> > After adding that directory to the path as well as the corresponding
> apr-util directory I was able to get the build to run. Everything
> successfully compiled but I got 1 test failure.
> >
> >  Start 19: streamtestcase
> > 19/60 Test #19: streamtestcase .***Exception:
> SegFault  2.00 sec
> >
> >
> > Ralph
> >
> >> On Jul 14, 2020, at 11:22 PM, Ralph Goers 
> wrote:
> >>
> >> Yes, it is at /usr/local/Cellar/apr/1.7.0/libexec/bin/.
> >>
> >> Ralph
> >>
> >>> On Jul 14, 2020, at 11:14 PM, Stephen Webb 
> wrote:
> >>>
> >>> Hi Ralph,
> >>>
> >>> Could you tell me if your Mac has the script "apr-1-config" installed?
> >>>
> >>> The src/cmake/FindApr.cmake in log4cxx expects the apr installation to
> >>> create that script and it calls it (passing --includedir) to
> >>> set APR_INCLUDE_DIR with the output
> >>>
> >>> On Wed, Jul 15, 2020 at 3:57 PM Ralph Goers <
> ralph.go...@dslextreme.com>
> >>> wrote:
> >>>
> >>>> I don’t see anything wrong with those files. They are the same two
> >>>> archives provided in the last release.
> >>>>
> >>>> I tried building them on my Mac but it gets an error
> >>>>
> >>>> CMake Error at
> >>>>
> target/dependency/cmake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146
> >>>> (message):
> >>>> APR_INCLUDE_DIR (missing: APR_LIBRARIES)
> >>>>
> >>>> I have previous done a brew install apr and brew install apr-util but
> I
> >>>> don’t have an APR_INCLUDE_DIR environment variable set and I wouldn’t
> know
> >>>> where to point it to.
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On Jul 14, 2020, at 7:16 PM, Robert Middleton 
> >>>> wrote:
> >>>>>
> >>>>> 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

[Stephen Webb]

If 'brew install apr' does not put a link to that  apr-1-config in a
directory on your path,  src/cmake/Find*.cmake should be made to use 'brew
--prefix'.

Could you raise an issue please?

On Wed, Jul 15, 2020 at 4:22 PM Ralph Goers 
wrote:

> Yes, it is at /usr/local/Cellar/apr/1.7.0/libexec/bin/.
>
> Ralph
>
> > On Jul 14, 2020, at 11:14 PM, Stephen Webb  wrote:
> >
> > Hi Ralph,
> >
> > Could you tell me if your Mac has the script "apr-1-config" installed?
> >
> > The src/cmake/FindApr.cmake in log4cxx expects the apr installation to
> > create that script and it calls it (passing --includedir) to
> > set APR_INCLUDE_DIR with the output
> >
> > On Wed, Jul 15, 2020 at 3:57 PM Ralph Goers 
> > wrote:
> >
> >> I don’t see anything wrong with those files. They are the same two
> >> archives provided in the last release.
> >>
> >> I tried building them on my Mac but it gets an error
> >>
> >> CMake Error at
> >>
> target/dependency/cmake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146
> >> (message):
> >>  APR_INCLUDE_DIR (missing: APR_LIBRARIES)
> >>
> >> I have previous done a brew install apr and brew install apr-util but I
> >> don’t have an APR_INCLUDE_DIR environment variable set and I wouldn’t
> know
> >> where to point it to.
> >>
> >> Ralph
> >>
> >>> On Jul 14, 2020, at 7:16 PM, Robert Middleton 
> >> wrote:
> >>>
> >>> 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

[Stephen Webb]

Hi Ralph,

Could you tell me if your Mac has the script "apr-1-config" installed?

The src/cmake/FindApr.cmake in log4cxx expects the apr installation to
create that script and it calls it (passing --includedir) to
set APR_INCLUDE_DIR with the output

On Wed, Jul 15, 2020 at 3:57 PM Ralph Goers 
wrote:

> I don’t see anything wrong with those files. They are the same two
> archives provided in the last release.
>
> I tried building them on my Mac but it gets an error
>
> CMake Error at
> target/dependency/cmake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146
> (message):
>   APR_INCLUDE_DIR (missing: APR_LIBRARIES)
>
> I have previous done a brew install apr and brew install apr-util but I
> don’t have an APR_INCLUDE_DIR environment variable set and I wouldn’t know
> where to point it to.
>
> Ralph
>
> > On Jul 14, 2020, at 7:16 PM, Robert Middleton 
> wrote:
> >
> > 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

[Stephen Webb]

Hi Robert,

I believe the failures are due to gzip,sed and zip programs not being
available.

My preference was to exclude those tests when the program was not available
to prevent exactly the problem you encountered.

Thorsten did not accept my pull request.
https://github.com/apache/logging-log4cxx/pull/18

Perhaps you could help convince Thorsten.





On Wed, Jul 15, 2020 at 12:17 PM Robert Middleton 
wrote:

> 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] Towards a release

[Stephen Webb]

I see no question at that link, only the commit diff.

On Mon, Mar 30, 2020 at 5:36 PM Thorsten Schöning 
wrote:

> Guten Tag Stephen Webb,
> am Montag, 30. März 2020 um 04:19 schrieben Sie:
>
> > My PR#21 (https://github.com/apache/logging-log4cxx/pull/21) remains
> > un-reviewed.
>
> It's not, I already asked questions weeks ago:
>
>
> https://github.com/apache/logging-log4cxx/pull/21/files/63a6fd31ddf27ba05c76bc3e6b1506e28f55b7c0..1190a41281e4f925341a0c4120f34b69f13ce43a#diff-06a664097df306d4e6937bbe0d30b4f1
>
> Didn't you get any notification or can't see it?
>
> 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: [log4cxx] Towards a release

[Stephen Webb]

At least one log4cxx user has been using my fork of log4cxx (which includes
PR#21) to build on Windows (see
https://github.com/microsoft/vcpkg/issues/6125)


On Mon, Mar 30, 2020 at 2:35 PM Ralph Goers 
wrote:

> I’d be happy to merge it if someone involved with the project (even a
> non-committer) can look at it. I don’t normally work on Windows so trying
> to run a build with it is a bit more than I would like to do.
>
> Ralph
>
> > On Mar 29, 2020, at 7:19 PM, Stephen Webb  wrote:
> >
> > Is there anyway I can to help move this forward (I do not have an Apache
> > account)?
> >
> > My PR#21 (https://github.com/apache/logging-log4cxx/pull/21) remains
> > un-reviewed.
> >
> > I have created a migration tool
> > https://github.com/stephen-webb/log4cxx_10_to_11 for anyone who has the
> > same migration issues as I.
> >
> > Regards
> > Stephen Webb
> >
> >
> >
> > On Wed, Mar 4, 2020 at 3:16 AM Tobias Frost  wrote:
> >
> >> On Tue, Mar 03, 2020 at 04:51:28PM +1100, Stephen Webb wrote:
> >>
> >>> I would be surprised if any unix distribution would change to 0.11
> >> log4cxx
> >>> if its API is incompatible with 0.10.
> >>
> >> With my Debian maintainer hat on:
> >> This is nothing special and day to day businesss with distos:
> >>
> >> It will "just" invoke a library transition [1], and the new binary
> >> packages will be named according to the new SONAME, e.g liblog4cxx11
> >> After the transition the old library version will be removed from
> >> Debian.
> >>
> >> Frankly, I'm really looking forward to have a new liblog4cxx for
> >> Debian, and now (as we are still some time away from the next Debian
> >> release) would be absolutly the best time for a new release.
> >> The new version just fixes so many issues that it really pays off the
> >> extra work for packaging and the transtion, introduced by the SONAME
> >> bump. (my 2cent…)
> >>
> >> --
> >> Cheers,
> >> tobi
> >>
> >> [1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> >>
> >>> Regards
> >>> Stephen Webb
> >>>
> >>>
> >>>
> >>> On Tue, Mar 3, 2020 at 4:28 AM Thorsten Schöning <
> tschoen...@am-soft.de>
> >>> wrote:
> >>>
> >>>> Guten Tag Ralph Goers,
> >>>> am Montag, 2. März 2020 um 16:34 schrieben Sie:
> >>>>
> >>>>> There is a difference between a user’s compile failing vs the build
> >>>>> having changed.
> >>>>
> >>>> And which? Things don't work in the worst case either way and need to
> >>>> be adopted. Why exactly is getting rid of build support by ANT
> >>>> acceptable for users relying on that, but applying LOGCXX-319 might(!)
> >>>> not be?
> >>>>
> >>>> If I remember correctly, the concrete changes could even be adopted
> >>>> using automatic search
> >>>>
> >>>>> Given how old log4cxx is I would expect it to be
> >>>>> used in a fair number of places despite its version number.
> >>>>
> >>>> And a fair number of users applied either the available patches
> >>>> already since the last release or simply work with master already
> >>>> anyway. I can't remember anyone complaining about the changes
> >>>> introcuded by that concrete issue in the last years as well.
> >>>>
> >>>>> I
> >>>>> haven’t looked at the code myself but is there no way to keep it
> >>>>> backward compatible while also keeping the new changes?
> >>>>
> >>>> In my opinion this is an unnecessary meta-discussion until a concrete
> >>>> problem has been described introduced by LOGCXX-319 or other changes.
> >>>> So at least I won't reconsider each and every change since the last
> >>>> release.
> >>>>
> >>>> 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: [log4cxx] Towards a release

[Stephen Webb]

Is there anyway I can to help move this forward (I do not have an Apache
account)?

My PR#21 (https://github.com/apache/logging-log4cxx/pull/21) remains
un-reviewed.

I have created a migration tool
https://github.com/stephen-webb/log4cxx_10_to_11 for anyone who has the
same migration issues as I.

Regards
Stephen Webb



On Wed, Mar 4, 2020 at 3:16 AM Tobias Frost  wrote:

> On Tue, Mar 03, 2020 at 04:51:28PM +1100, Stephen Webb wrote:
>
> > I would be surprised if any unix distribution would change to 0.11
> log4cxx
> > if its API is incompatible with 0.10.
>
> With my Debian maintainer hat on:
> This is nothing special and day to day businesss with distos:
>
> It will "just" invoke a library transition [1], and the new binary
> packages will be named according to the new SONAME, e.g liblog4cxx11
> After the transition the old library version will be removed from
> Debian.
>
> Frankly, I'm really looking forward to have a new liblog4cxx for
> Debian, and now (as we are still some time away from the next Debian
> release) would be absolutly the best time for a new release.
> The new version just fixes so many issues that it really pays off the
> extra work for packaging and the transtion, introduced by the SONAME
> bump. (my 2cent…)
>
> --
> Cheers,
> tobi
>
> [1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions
>
> > Regards
> > Stephen Webb
> >
> >
> >
> > On Tue, Mar 3, 2020 at 4:28 AM Thorsten Schöning 
> > wrote:
> >
> > > Guten Tag Ralph Goers,
> > > am Montag, 2. März 2020 um 16:34 schrieben Sie:
> > >
> > > > There is a difference between a user’s compile failing vs the build
> > > > having changed.
> > >
> > > And which? Things don't work in the worst case either way and need to
> > > be adopted. Why exactly is getting rid of build support by ANT
> > > acceptable for users relying on that, but applying LOGCXX-319 might(!)
> > > not be?
> > >
> > > If I remember correctly, the concrete changes could even be adopted
> > > using automatic search
> > >
> > > > Given how old log4cxx is I would expect it to be
> > > > used in a fair number of places despite its version number.
> > >
> > > And a fair number of users applied either the available patches
> > > already since the last release or simply work with master already
> > > anyway. I can't remember anyone complaining about the changes
> > > introcuded by that concrete issue in the last years as well.
> > >
> > > > I
> > > > haven’t looked at the code myself but is there no way to keep it
> > > > backward compatible while also keeping the new changes?
> > >
> > > In my opinion this is an unnecessary meta-discussion until a concrete
> > > problem has been described introduced by LOGCXX-319 or other changes.
> > > So at least I won't reconsider each and every change since the last
> > > release.
> > >
> > > 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: [log4cxx] Towards a release

[Stephen Webb]

I can describe the concrete problem I will have with LOGCXX-319 given that
all the code for which I am responsible has been written using log4cxx 0.10

In 0.10, you have to know the macros are "blocks" not "statements" as any
conditional logging macro has to be written without a trailing semicolon.
For example:
if (someCondition)
  LOG4CXX_INFO(m_log, "Condition 1 message") // Note a semicolon here will
cause a compile error
else
  LOG4CXX_INFO(m_log, "Alternate message)

As a result of knowing the macros are "blocks", most LOG4CXX_ XXX() code
does not have a trailing semicolon.

I would like to be able to compile my systems with both 0.10 and 0.11 for a
transitional period (i.e. to avoid a 'big bang' switch over).

If I was forced to use a 'big bang' change, I would probably just change to
log4cpp which is already supported by package managers (conan.io and vcpkg).

I would be surprised if any unix distribution would change to 0.11 log4cxx
if its API is incompatible with 0.10.

Regards
Stephen Webb



On Tue, Mar 3, 2020 at 4:28 AM Thorsten Schöning 
wrote:

> Guten Tag Ralph Goers,
> am Montag, 2. März 2020 um 16:34 schrieben Sie:
>
> > There is a difference between a user’s compile failing vs the build
> > having changed.
>
> And which? Things don't work in the worst case either way and need to
> be adopted. Why exactly is getting rid of build support by ANT
> acceptable for users relying on that, but applying LOGCXX-319 might(!)
> not be?
>
> If I remember correctly, the concrete changes could even be adopted
> using automatic search
>
> > Given how old log4cxx is I would expect it to be
> > used in a fair number of places despite its version number.
>
> And a fair number of users applied either the available patches
> already since the last release or simply work with master already
> anyway. I can't remember anyone complaining about the changes
> introcuded by that concrete issue in the last years as well.
>
> > I
> > haven’t looked at the code myself but is there no way to keep it
> > backward compatible while also keeping the new changes?
>
> In my opinion this is an unnecessary meta-discussion until a concrete
> problem has been described introduced by LOGCXX-319 or other changes.
> So at least I won't reconsider each and every change since the last
> release.
>
> 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: [log4cxx] Towards a release

[Stephen Webb]

The issue is it has changed to core log4cxx api so that existing 0.10 code
may not compile.
The macros are the core log4cxx api.


On Mon, Mar 2, 2020, 9:32 PM Thorsten Schöning 
wrote:

> Guten Tag Stephen Webb,
> am Montag, 2. März 2020 um 11:05 schrieben Sie:
>
> > In my review I did encounter an item of concern to me. I see that 0.11
> > cannot be used in place of 0.10 due to LOG4CXX-319. I personally am
> > responsible for hundreds of thousands of lines of code that will not work
> > with this change.
>
> What's the exact problem? I suggest reopneing the issue and discussing
> details there. That change even worked for a pretty old, non-standard
> Borland compiler I was using back then.
>
>
> https://issues.apache.org/jira/projects/LOGCXX/issues/LOGCXX-319?filter=allissues
>
> 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: [log4cxx] Towards a release

[Stephen Webb]

I have not changed anything. Just used 'mvn post-site'.
It is simply an attempt to see if there is anyone interested in log4cxx.
In my review I did encounter an item of concern to me. I see that 0.11
cannot be used in place of 0.10 due to LOG4CXX-319. I personally am
responsible for hundreds of thousands of lines of code that will not work
with this change.
I would suggest we need a configure option to use the 0.10 macros instead
of the new ones. The new macros can be the default.
Regards
Stephen Webb

On Mon, Mar 2, 2020, 7:50 PM Thorsten Schöning 
wrote:

> Guten Tag Stephen Webb,
> am Sonntag, 1. März 2020 um 07:19 schrieben Sie:
>
> > I have posted the result of "mvn post-site" to
> > https://stephen-webb.github.io/
>
> Looks the same like what is published already to me:
>
> https://logging.apache.org/log4cxx/next_stable/index.html
>
> Shouldn't it be more of interest to review what you have changed to
> get that result instead of the result itself? Did you replace more ANT
> with MVN or ...?
>
> 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] Towards a release

[Stephen Webb]

I have posted the result of "mvn post-site" to
https://stephen-webb.github.io/

Please review.

Fwd: [apache/logging-log4cxx] Replace ant build with cmake (#14)

[Stephen Webb]

Hi All,

I have done everything I can think of prepare
https://github.com/apache/logging-log4cxx/pull/14 for inclusion in the
repository.

Please review.

On Sat, Feb 8, 2020 at 3:33 AM Matt Sicker  wrote:

> *@jvz* commented on this pull request.
> --
>
> In src/site/apt/building/cmake.apt
> :
>
> > + --
> + --
> +
> +Building Apache log4cxx with cmake
> +
> +* Quick start:
> +
> +  Make sure cmake 3.13+, g++ and make are available, install or
> +  build apr 1.x, apr-util 1.x, gzip and zip.
> +
> +++
> +$ apt-get install build-essential libapr1-dev libaprutil1-dev gzip zip
> +$ cd apache-log4cxx-x.x.x
> +$ mkdir build
> +$ cd build
> +$ ccmake ..
>
> If there's any differences in the commands, go ahead.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> ,
> or unsubscribe
> 
> .
>

Re: [jira] [Commented] (LOGCXX-494) Provide a windows build environment for the project

[Stephen Webb]

Hi Ralph,

Can someone tell me how I get an Apache account to able to commit to
https://gitbox.apache.org.

I have replaced the ant build in log4cxx with the CMake build. All changes
are shown https://github.com/apache/logging-log4cxx/pull/14/files

Here is the tail of "mvn release:prepare":
[INFO] 88% tests passed, 7 tests failed out of 60
[INFO]
[INFO] Total Test time (real) =  29.86 sec
[INFO]
[INFO] The following tests FAILED:
[INFO] 14 - ndctestcase (Failed)
[INFO] 15 - patternlayouttest (Failed)
[INFO] 29 - optionconvertertestcase (Failed)
[INFO] 39 - defaultinittestcase (Failed)
[INFO] 41 - smtpappendertestcase (Failed)
[INFO] 44 - socketservertestcase (Failed)
[INFO] 49 - filenamepatterntestcase (Failed)
[INFO] Errors while running CTest
[INFO] [INFO]
[INFO] [INFO] --- maven-antrun-plugin:1.7:run (autogen) @ apache-log4cxx ---
[INFO] [INFO] Executing tasks
[INFO]
[INFO] main:
[INFO]
[INFO] autogen:
[INFO] [INFO] Executed tasks
[INFO] [INFO]

[INFO] [INFO] BUILD SUCCESS
[INFO] [INFO]

[INFO] [INFO] Total time:  03:21 min
[INFO] [INFO] Finished at: 2020-01-31T17:01:15+11:00
[INFO] [INFO]

[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /home/stephen/logging-log4cxx && git add --
pom.xml
[INFO] Working directory: /home/stephen/logging-log4cxx
[INFO] Executing: /bin/sh -c cd /home/stephen/logging-log4cxx && git status
[INFO] Working directory: /home/stephen/logging-log4cxx
[INFO] Tagging release with the label v0.11.0-RC3...
[INFO] Executing: /bin/sh -c cd /home/stephen/logging-log4cxx && git tag -F
/tmp/maven-scm-1228479721.commit v0.11.0-RC3
[INFO] Working directory: /home/stephen/logging-log4cxx
[INFO] Executing: /bin/sh -c cd /home/stephen/logging-log4cxx && git push
https://gitbox.apache.org/repos/asf/logging-log4cxx.git v0.11.0-RC3
[INFO] Working directory: /home/stephen/logging-log4cxx
Username for 'https://gitbox.apache.org': stephen-webb
Password for 'https://stephen-w...@gitbox.apache.org':
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time:  05:47 min
[INFO] Finished at: 2020-01-31T17:03:37+11:00
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3:prepare (default-cli) on
project apache-log4cxx: Unable to tag SCM
[ERROR] Provider message:
[ERROR] The git-push command failed.
[ERROR] Command output:
[ERROR] fatal: Authentication failed for '
https://gitbox.apache.org/repos/asf/logging-log4cxx.git/'

On Fri, Jan 24, 2020 at 12:41 PM Ralph Goers 
wrote:

> I am all for anything that can get a release out.
>
> Ralph
>
> > On Jan 23, 2020, at 6:26 PM, Stephen Webb  wrote:
> >
> > Am I correct in thinking the ant build is very broken as 'find-apr.xml'
> > does not make use of 'apr-1-config' like 'find_apr.m4' does? (The same
> > applies to 'find-apr-util.xml' etc.)
> >
> > Am I missing something or is log4cxx the only Apache Portable Runtime
> user
> > that provides an ant build (I looked at Apache HTTP Server, Flood load
> > tester and FreeSwitch and they do not provide an ant build).
> >
> > If I am not mistaken in the above assumptions, it would seem to me
> > changing the pom.xml to provide a CMake build (using
> > https://github.com/cmake-maven-project/cmake-maven-project and
> > https://github.com/apache/logging-log4cxx/pull/12) instead of ant would
> be
> > a much quicker solution than rewriting all the ant build scripts.
> >
> > What do you think?
>
>
>

[jira] [Commented] (LOGCXX-494) Provide a windows build environment for the project

[Stephen Webb]

Am I correct in thinking the ant build is very broken as 'find-apr.xml'
does not make use of 'apr-1-config' like 'find_apr.m4' does? (The same
applies to 'find-apr-util.xml' etc.)

Am I missing something or is log4cxx the only Apache Portable Runtime user
that provides an ant build (I looked at Apache HTTP Server, Flood load
tester and FreeSwitch and they do not provide an ant build).

If I am not mistaken in the above assumptions, it would seem to me
changing the pom.xml to provide a CMake build (using
https://github.com/cmake-maven-project/cmake-maven-project and
https://github.com/apache/logging-log4cxx/pull/12) instead of ant would be
a much quicker solution than rewriting all the ant build scripts.

What do you think?

Re: [log4cxx] Contributing a CMkae build system

[Stephen Webb]

Hi Thorsten,

I saw in the mailing lists you have previously (July 2017, January 2018)
attempted to get a release done, but I did not see any vote being taken.

Could you tell us why the vote did not happen on these occasions?

Also, who is the current PMC chair?

Regards
Stephen Webb

On Tue, Jan 7, 2020 at 7:17 PM Thorsten Schöning 
wrote:

> Guten Tag Stephen Webb,
> am Dienstag, 7. Januar 2020 um 03:33 schrieben Sie:
>
> > I am prepared to commit time to helping progress log4cxx to a release.
>
> If you want to get a release done, you should first focus on that
> instead of adding another build system necessary to maintain, which
> might even break existing functionality and stuff. Releasing is
> non-trivial in my opinion, took me a lot of time already and its not
> done yet.
>
> Make yourself familiar with how to tag things, where you need to
> change version numbers, how to generate sites, where to upload what,
> what to sign, where to put keys and stuff first. That's a lot of work
> involving Maven, shell scripts and stuff. Afterwards you can change
> the build system.
>
> http://www.apache.org/dev/release-publishing.html
> http://www.apache.org/legal/release-policy.html
>
> 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] Contributing a CMkae build system

[Stephen Webb]

Hi All,
I am prepared to commit time to helping progress log4cxx to a release.

I would like to add a modern CMake build option to log4cxx and then create
a port in vcpkg (see https://github.com/microsoft/vcpkg/issues/6125). I
have sent a signed ICLA to the secretary.

Does anyone have any comments?

Regrads
Stephen Webb