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 <rm...@apache.org> on 2021/04/13 02:09:22 UTC

[log4cxx] Release Prep

Before I go and do a release of log4cxx, are there any issues that may
need to be taken care of before the next release?  Otherwise, if there
are no objections, I'll call for a release vote here shortly for
version 0.12.0.

-Robert Middleton

Re: [log4cxx] Release Prep

Posted by Robert Middleton <rm...@apache.org>.
As long as the classes that you are trying to cast to/from descend from
log4cxx::Object, the cast should work fine.

The aliasing constructor for std::shared_ptr means that both shared_ptrs
point at the same control block for the shared pointer, so the object is
the same; I'll add some notes about that.

-Robert Middleton

On Thu, Apr 22, 2021 at 3:46 AM Stephen Webb <sw...@gmail.com> wrote:

> Yes, your fancy new cast function looks like a better approach.
>
> Should the note mention it uses the aliasing constructor std::shared_ptr or
> is it always going to be safe with log4cxx::Object pointers?
>
> On Thu, Apr 22, 2021 at 7:54 AM Robert Middleton <os...@gmail.com>
> 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 <sw...@gmail.com>
> 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<log4cxx::FileAppender*>(appender.get()))
> > >         result = fileAppender->getFile();
> > >
> > >
> > > On Tue, Apr 13, 2021 at 12:09 PM Robert Middleton <
> rmiddleton@apache.org
> > >
> > > wrote:
> > >
> > > > Before I go and do a release of log4cxx, are there any issues that
> may
> > > > need to be taken care of before the next release?  Otherwise, if
> there
> > > > are no objections, I'll call for a release vote here shortly for
> > > > version 0.12.0.
> > > >
> > > > -Robert Middleton
> > > >
> > >
> >
>

Re: [log4cxx] Release Prep

Posted by Stephen Webb <sw...@gmail.com>.
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 <os...@gmail.com>
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 <sw...@gmail.com> 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<log4cxx::FileAppender*>(appender.get()))
> >         result = fileAppender->getFile();
> >
> >
> > On Tue, Apr 13, 2021 at 12:09 PM Robert Middleton <rmiddleton@apache.org
> >
> > wrote:
> >
> > > Before I go and do a release of log4cxx, are there any issues that may
> > > need to be taken care of before the next release?  Otherwise, if there
> > > are no objections, I'll call for a release vote here shortly for
> > > version 0.12.0.
> > >
> > > -Robert Middleton
> > >
> >
>

Re: [log4cxx] Release Prep

Posted by Robert Middleton <os...@gmail.com>.
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 <sw...@gmail.com> 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<log4cxx::FileAppender*>(appender.get()))
>         result = fileAppender->getFile();
>
>
> On Tue, Apr 13, 2021 at 12:09 PM Robert Middleton <rm...@apache.org>
> wrote:
>
> > Before I go and do a release of log4cxx, are there any issues that may
> > need to be taken care of before the next release?  Otherwise, if there
> > are no objections, I'll call for a release vote here shortly for
> > version 0.12.0.
> >
> > -Robert Middleton
> >
>

Re: [log4cxx] Release Prep

Posted by Stephen Webb <sw...@gmail.com>.
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<log4cxx::FileAppender*>(appender.get()))
        result = fileAppender->getFile();


On Tue, Apr 13, 2021 at 12:09 PM Robert Middleton <rm...@apache.org>
wrote:

> Before I go and do a release of log4cxx, are there any issues that may
> need to be taken care of before the next release?  Otherwise, if there
> are no objections, I'll call for a release vote here shortly for
> version 0.12.0.
>
> -Robert Middleton
>

Re: [log4cxx] Release Prep

Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Robert Middleton,
am Samstag, 17. April 2021 um 02:09 schrieben Sie:

> If you're able to test the PR that I just did, that would be helpful:
> https://github.com/apache/logging-log4cxx/pull/63

Stephen, you can't be chosen for review in GitHub, the dialog simply
doesnm't find you, even though your account seems to be there. There's
probably something wrong with your association to the project in your
apache profile or alike, which you might want to check.

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.Schoening@AM-SoFT.de
Web:    http://www.AM-SoFT.de/

Tel:   05151-  9468- 0
Tel:   05151-  9468-55
Fax:   05151-  9468-88
Mobil:  0178-8 9468-04

AM-SoFT IT-Service - Bitstore Hameln GmbH i.G., Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB neu - Geschäftsführer: Janine Galonska


Für Rückfragen stehe ich Ihnen sehr gerne zur Verfügung.

Mit freundlichen Grüßen

Thorsten Schöning


Tel: 05151 9468 0
Fax: 05151 9468 88
Mobil: 
Webseite: https://www.am-soft.de 

AM-Soft IT-Service - Bitstore Hameln GmbH i.G. ist ein Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK

AM-Soft IT-Service - Bitstore Hameln GmbH i.G.
Brandenburger Str. 7c
31789 Hameln
Tel: 05151 9468 0

Bitstore IT-Consulting GmbH
Zentrale - Berlin Lichtenberg
Frankfurter Allee 285
10317 Berlin
Tel: 030 453 087 80

CBS IT-Service - Bitstore Kaulsdorf UG
Tel: 030 453 087 880 1

Büro Dallgow-Döberitz
Tel: 03322 507 020

Büro Kloster Lehnin
Tel: 033207 566 530

PCE IT-Service - Bitstore Darmstadt UG
Darmstadt
Tel: 06151 392 973 0

Büro Neuruppin
Tel: 033932 606 090

ACI EDV Systemhaus - Bitstore Dresden GmbH
Dresden
Tel: 0351 254 410

Das Systemhaus - Bitstore Magdeburg GmbH
Magdeburg
Tel: 0391 636 651 0

Allerdata.IT - Bitstore Wittenberg GmbH
Wittenberg
Tel: 03491 876 735 7

Büro Liebenwalde
Tel: 033054 810 00

HSA - das Büro - Bitstore Altenburg UG
Altenburg
Tel: 0344 784 390 97

Bitstore IT – Consulting GmbH
NL Piesteritz 
Piesteritz
Tel: 03491 644 868 6

Solltec IT-Services - Bitstore Braunschweig UG
Braunschweig
Tel: 0531 206 068 0

MF Computer Service - Bitstore Gütersloh GmbH
Gütersloh
Tel: 05245 920 809 3

Firmensitz: AM-Soft IT-Service - Bitstore Hameln GmbH i.G. , Brandenburger Str. 7c , 31789 Hameln
Geschäftsführer Janine Galonska







Re: [log4cxx] Release Prep

Posted by Robert Middleton <ro...@rm5248.com>.
If you're able to test the PR that I just did, that would be helpful:
https://github.com/apache/logging-log4cxx/pull/63

All of the tests pass so it's probably good, but an extra set of eyes
is helpful.

-Robert Middleton

On Thu, Apr 15, 2021 at 4:32 AM Stephen Webb <sw...@gmail.com> wrote:
>
> > Or maybe we just need something like LOG4CXX_SOURCE_DIR?
>
> yes, I like that idea - something we control.
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Thu, Apr 15, 2021 at 11:28 AM Robert Middleton <
> robert.middleton@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

Posted by Stephen Webb <sw...@gmail.com>.
> Or maybe we just need something like LOG4CXX_SOURCE_DIR?

yes, I like that idea - something we control.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Apr 15, 2021 at 11:28 AM Robert Middleton <
robert.middleton@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

Posted by Robert Middleton <ro...@rm5248.com>.
Also, question for Thorsten: are you comfortable closing PR #22 at
this point?  There's been no activity on it for a year at this point,
and it seems like the resolution we came up with was "don't do
anything".

-Robert Middleton

On Wed, Apr 14, 2021 at 9:27 PM Robert Middleton
<ro...@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

Posted by Robert Middleton <ro...@rm5248.com>.
> 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

Posted by Stephen Webb <sw...@gmail.com>.
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 <rm...@apache.org>
wrote:

> Before I go and do a release of log4cxx, are there any issues that may
> need to be taken care of before the next release?  Otherwise, if there
> are no objections, I'll call for a release vote here shortly for
> version 0.12.0.
>
> -Robert Middleton
>

Re: [log4cxx] Release Prep

Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Robert Middleton,
am Dienstag, 13. April 2021 um 04:09 schrieben Sie:

> 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?[...]

Including the latest PR makes sense, the more docs the better. :-)

https://github.com/apache/logging-log4cxx/pull/61

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