You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@logging.apache.org by Robert Middleton <os...@gmail.com> on 2020/07/15 02:16:55 UTC

[log4cxx] Release Testing

I went and tested the current version of log4cxx, and at least on Linux I
don't have any failures.  There are a bunch of failures on the Windows
side, but I don't know enough about windows to know where to start to debug
those.

The tests that failed:

90% tests passed, 6 tests failed out of 60
Total Test time (real) = 528.17 sec
The following tests FAILED:
14 - minimumtestcase (Failed)
16 - patternlayouttest (Failed)
54 - sizebasedrollingtest (Failed)
55 - timebasedrollingtest (Failed)
57 - errorhandlertestcase (Failed)
60 - xmltests (Failed)

Regardless, I've uploaded the zip and tar.gz here:
https://rm5248.com/log4cxx/

As of this point, do the zip/tar.gz files contain everything required for
release?  Is there anything that needs to be added?  I want to try and help
if there's something that's missing.

-Robert Middleton

Re: [log4cxx] Release Testing

Posted by Robert Middleton <os...@gmail.com>.

I guess I'm viewing this as an "optional" test - we know that the test
is going to fail(because e.g. we don't have gzip installed), so
there's no reason to run the test.  If gzip is installed, then the
test should run and pass appropriately.

I definitely agree that developers should have all tests working.  My
thought is more the case of somebody who simply downloads log4cxx and
wants to use it.  They may be confused by the failing tests, even
though they're not critical, but they don't want/need to setup a
system that will cause 100% of the tests to pass.

Does anything similar happen with log4j2?

-Robert Middleton

On Fri, Jul 17, 2020 at 6:57 AM Thorsten Schöning <ts...@am-soft.de> 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.Schoening@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

Posted by Stephen Webb <sw...@gmail.com>.

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 <ts...@am-soft.de>
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.Schoening@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

Posted by Thorsten Schöning <ts...@am-soft.de>.

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.Schoening@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

Posted by Robert Middleton <os...@gmail.com>.

On Thu, Jul 16, 2020 at 2:24 AM Thorsten Schöning <ts...@am-soft.de> wrote:
> Am I correct that you are using JDK 11 already? Because I'm running
> into problems when executing Maven in my UB 16.04 with JDK 8 setup a
> while ago.
>

Correct, Java 11 and Maven 3.6.3 for me.  I'm on Debian 10, so Java 11
is readily available and I simply downloaded the latest version of
maven and put it on my $PATH to execute.

> > I'm not sure if the autotools still work at this point; I haven't
> > tested with them in a while.
>
> I just did and they compiled the project fine, the only test failing
> is most likely related to my setup:
>
> > log4cxx: Cannot get information about host: unknown.invalid
> > log4cxx: Could not find unknown.invalid. All logging will FAIL.
> > log4cxx: Cannot get information about host: unknown.invalid
>
> I have a proper name in /etc/hostname, so does anyone have an idea?
>
> >         apr_sockaddr_t* address = 0;
> >         apr_status_t status =
> >                 apr_sockaddr_info_get(&address, encodedHost.c_str(),
> >                         APR_INET, 0, 0, addrPool.getAPRPool());
> >
> >         if (status != APR_SUCCESS)
> >         {
> >                 LogString msg(LOG4CXX_STR("Cannot get information about host: "));
> >                 msg.append(host);
> >                 LogLog::error(msg);
> >                 throw UnknownHostException(msg);
> >         }
>
> > ping ub-16-04-lts-server-x64
> > PING ub-16-04-lts-server-x64 (127.0.1.1) 56(84) bytes of data.
> > 64 bytes from ub-16-04-lts-server-x64 (127.0.1.1): icmp_seq=1 ttl=64 time=0.017 ms
>
> > ping 0.0.0.0
> > PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
> > 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.017 ms
>
> > ping unknown.invalid
> > ping: unknown host unknown.invalid
>
> Not sure when I executed tests the last time, might be with UB 14.04.
>

Which test is this?


> > I guess that's one way of thinking about it.  However, if you do that
> > it seems like you should always run all tests, while (for example) the
> > NT Event Logger appender test is only run on Windows; this would
> > always fail on Linux/OSX.
>
> Running only those tests which are designed for some platform at all
> and most likely to succeed with somewhat easy setup does read like a
> good compromise to me. SED and Co. are really easy to provide on
> Windows, for many users of GIT or WSL already available.
>

So perhaps the best solution is based a little bit off of Stephen's
earlier PR(#18[1]), but instead of compiling out the code that depends
on gzip we make the test more granular(one test for rolling zip, one
test for rolling gz, etc) and disable[2] the test if the appropriate
executable is not found.

-Robert Middleton

[1]: https://github.com/apache/logging-log4cxx/pull/18
[2]: https://cmake.org/cmake/help/latest/prop_test/DISABLED.html

Re: [log4cxx] Release Testing

Posted by Thorsten Schöning <ts...@am-soft.de>.

Guten Tag Robert Middleton,
am Mittwoch, 15. Juli 2020 um 23:44 schrieben Sie:

> No, I used the release_prepare.sh to generate it, since it's my
> understanding that is the script that should do that.

It is, that means the site is not part of the release anymore after
removing the ANT-parts and introducing CMAKE. Not sure if that makes
sense, but could easily live with that.

Am I correct that you are using JDK 11 already? Because I'm running
into problems when executing Maven in my UB 16.04 with JDK 8 setup a
while ago.

> I'm not sure if the autotools still work at this point; I haven't
> tested with them in a while.

I just did and they compiled the project fine, the only test failing
is most likely related to my setup:

> log4cxx: Cannot get information about host: unknown.invalid
> log4cxx: Could not find unknown.invalid. All logging will FAIL.
> log4cxx: Cannot get information about host: unknown.invalid

I have a proper name in /etc/hostname, so does anyone have an idea?

>         apr_sockaddr_t* address = 0;
>         apr_status_t status =
>                 apr_sockaddr_info_get(&address, encodedHost.c_str(),
>                         APR_INET, 0, 0, addrPool.getAPRPool());
>
>         if (status != APR_SUCCESS)
>         {
>                 LogString msg(LOG4CXX_STR("Cannot get information about host: "));
>                 msg.append(host);
>                 LogLog::error(msg);
>                 throw UnknownHostException(msg);
>         }

> ping ub-16-04-lts-server-x64
> PING ub-16-04-lts-server-x64 (127.0.1.1) 56(84) bytes of data.
> 64 bytes from ub-16-04-lts-server-x64 (127.0.1.1): icmp_seq=1 ttl=64 time=0.017 ms

> ping 0.0.0.0
> PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.017 ms

> ping unknown.invalid
> ping: unknown host unknown.invalid

Not sure when I executed tests the last time, might be with UB 14.04.

> I guess that's one way of thinking about it.  However, if you do that
> it seems like you should always run all tests, while (for example) the
> NT Event Logger appender test is only run on Windows; this would
> always fail on Linux/OSX.

Running only those tests which are designed for some platform at all
and most likely to succeed with somewhat easy setup does read like a
good compromise to me. SED and Co. are really easy to provide on
Windows, for many users of GIT or WSL already available.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail: Thorsten.Schoening@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

Posted by Robert Middleton <os...@gmail.com>.

> How did you create those archives? I guess you didn't use the created
> release_*-scripts, but "make dist dist-zip" again?

No, I used the release_prepare.sh to generate it, since it's my
understanding that is the script that should do that.

I'm not sure if the autotools still work at this point; I haven't
tested with them in a while.

> Everyone is free to ignore failing tests anyway. Not running many of
> those and not notifying the user about that OTOH provides a wrong
> feeling that everything's OK, while things might fail at runtime.

I guess that's one way of thinking about it.  However, if you do that
it seems like you should always run all tests, while (for example) the
NT Event Logger appender test is only run on Windows; this would
always fail on Linux/OSX.

As per Ralph's comment:
> That said, I don’t see anyplace on the log4cxx web site that even states what platforms it supports.

It /should/ work wherever APR works, although for some parts of the
code log4cxx relies on external applications being present(see [1] for
example code, and [2] for the test).  There's also support for
uncommon character encodings like EBCDIC, which I have no idea if it
still works.

I would like to create a minimal library that depends solely on the
C++ standard library, but that would probably be easier with more
modern versions of C++(C++17 has filesystem library, C++20 introduces
formatting[3], which is possibly libfmt[4] on the backend, I'm not
sure).

-Robert Middleton

[1]: https://github.com/apache/logging-log4cxx/blob/229106fd7ce99452501bd8406bd653793c756f69/src/main/cpp/gzcompressaction.cpp#L110
[2]: https://github.com/apache/logging-log4cxx/blob/229106fd7ce99452501bd8406bd653793c756f69/src/test/cpp/rolling/sizebasedrollingtest.cpp#L188
[3]: https://en.cppreference.com/w/cpp/utility/format
[4]: https://fmt.dev/latest/index.html

Re: [log4cxx] Release Testing

Posted by Thorsten Schöning <ts...@am-soft.de>.

Guten Tag Robert Middleton,
am Mittwoch, 15. Juli 2020 um 04:16 schrieben Sie:

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

How did you create those archives? I guess you didn't use the created
release_*-scripts, but "make dist dist-zip" again?

The archives don't seem to contain some IDE-projects, the site and are
missing some autotools-related files available in the src-tree. All of
those have been available in the past releases:

https://www.apache.org/dyn/closer.cgi/logging/log4cxx/0.10.0/apache-log4cxx-0.10.0.zip

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail: Thorsten.Schoening@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

Posted by Thorsten Schöning <ts...@am-soft.de>.

Guten Tag Stephen Webb,
am Mittwoch, 15. Juli 2020 um 05:54 schrieben Sie:

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

And I still won't, the necessary tools to make them succeed can easily
be provided for Windows as well:

> C:\Program Files (x86)\UnxUtils\usr\local\wbin
> https://sourceforge.net/projects/unxutils/

Even the Java-part is not too difficult. I've attached my example
script running the tests in a directory layout like the following:

> Documents\Svn\Src\Libs\trunk\C++\Logging\log4cxx\0.11.0-SNAPSHOT\build\RAD 10.2\tests\test_all
> Documents\Svn\Src\Libs\trunk\C++\Logging\log4cxx\0.11.0-SNAPSHOT\build\RAD 10.2\tests\test_all\Win32\Debug\out
> Documents\Svn\Src\Libs\trunk\C++\Logging\log4cxx\0.11.0-SNAPSHOT\dist
> Documents\Svn\Src\Libs\trunk\C++\Logging\log4cxx\0.11.0-SNAPSHOT\dist-dev
> Documents\Svn\Src\Libs\trunk\C++\Logging\log4cxx\0.11.0-SNAPSHOT\src
> Documents\Svn\Src\Libs\trunk\C++\Logging\log4cxx\0.11.0-SNAPSHOT\web

https://mvnrepository.com/artifact/log4j/log4j/1.2.17
https://repo1.maven.org/maven2/log4j/log4j/1.2.17/log4j-1.2.17.jar

Everyone is free to ignore failing tests anyway. Not running many of
those and not notifying the user about that OTOH provides a wrong
feeling that everything's OK, while things might fail at runtime.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail: Thorsten.Schoening@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

Posted by Stephen Webb <sw...@gmail.com>.

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 <os...@gmail.com>
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

Posted by Stephen Webb <sw...@gmail.com>.

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 <ra...@dslextreme.com>
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 <sw...@gmail.com> 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 <ra...@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 <os...@gmail.com>
> >> 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
> >>
> >>
> >>
>
>
>