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/08/03 00:17:37 UTC
[log4cxx] Feature Proposals
Hey all,
I'd like to propose some new features/updates for log4cxx, if there's
interest. A number of these are rather large changes, so it probably
doesn't make sense to work on them until there's a known-good release, as
they would likely break both API and ABI compatibility.
Big Changes:
1. Using std::shared_ptr(LOG4CXX-486). I did a proof-of-concept about
three years ago at this point, but I never did a patch/pull request as this
would change quite a lot. I think as a result of this I also removed the
mutex implementation and replaced with std::mutex.
2. Removal of most APR usage. Since C++11 we have mutexes, threads,
condition_variable, time functions, atomic functions, etc. There's still
some things beyond what I've mentioned that APR provides, but I could see a
potential use-case where the core library doesn't depend on APR, although
it would have limited functionality at that point.
3. Removal of maven for site generation. While it does provide a
consistent feel with log4j2, it seems like it is the source of a large
number of problems(releasing, building, etc.). It seems to me that the
best way would be to use doxygen to generate the site instead; we can use
markdown to create documentation pages instead of the doxia apt format.
The other advantage to this would be that it also means that only one site
is generated that contains both normal documentation as well as the API
documentation at the same time.
4. ABI compatibility. It would be good to keep all instance variables
in a private data member, so that they can be added/removed without
breaking the ABI. This may require some other changes to the API though,
as it would probably break some inline methods(this pattern is commonly
called a pimpl).
Medium changes:
1. Adding in libfmt to format arguments[1]. I did a proof-of-concept
earlier today by adding a new macro earlier today that looks like the
following: LOG4CXX_ERROR_F( logger, "hi {}", "Robert" ); Since this
library provides a bunch of nice formatting functions it should make
logging much clearer and more like log4j2.
2. Remove the autotools build - it seems to me that the CMake tooling
has successfully worked, and is fully cross-platform at this point. Is
there a particular reason to keep it around still?
3. Support for log4j2-style XML/JSON/YAML documents. The information
for log4j(1) style documents is harder to find now, so it seems to me that
having commonality with log4j2 moving forward would be a good idea for
consistency.
4. Add a new library to allow logging from Qt-based applications, e.g.
log4cxx-qt. I've done this before using qInstallMessageHandler[2], so it's
not too difficult to do. Also having some default appenders for e.g.
QString is useful, so that when I'm logging I don't need to do
.toStdString() all the time on the QStrings.
Going through the currently open issues in JIRA, there's also a large
number that are either so old that they don't make much sense, or may have
been fixed already. Would it make sense to go through them at some point?
That's probably not something that I can do alone, but I can help to go
through them.
-Robert Middleton
[1]: https://fmt.dev/latest/index.html
[2]: https://doc.qt.io/qt-5/qtglobal.html#qInstallMessageHandler
Re: [log4cxx] Feature Proposals
Posted by Matt Sicker <bo...@gmail.com>.
I think a more specific problem was that nobody on the PMC knows much about
this component. The active developers are committers and contributors
currently.
On Tue, Aug 4, 2020 at 01:01 Tobias Frost <to...@debian.org> wrote:
> On Mon, Aug 03, 2020 at 07:34:15PM -0500, Matt Sicker wrote:
> > Very well said! It helps get user feedback quicker, too.
>
> +1!
>
> Also, the current "stable" has some many bugs (I carry 13 non
> Debian-specific
> patches in the current Debian package…) and a new release would also fix
> some open
> Bugs on the Debian BTS…
> I really would appreciate a new release…
>
> However, wasn't the problem in earlier tries to get log4cxx11 out of the
> door
> that noone remembered how a release is done for this project? (At least,
> /me as
> an outsider had that impression but I could have gotten this wrong).
>
> --
> tobi
>
> > On Mon, Aug 3, 2020 at 19:03 Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > > Here are my thoughts after working on several ASF projects for over 15
> > > years.
> > >
> > > Theoretically logging projects should follow the “release early,
> release
> > > often” philosophy. There are a few good reasons why it should be that
> way.
> > > However, when you have a project with very few committers with limited
> time
> > > following that can be easier said than done. Personally, I like to
> set a
> > > goal for what I would like to see in a next release and try to meet
> that.
> > > However, it is more important to have semi-frequent releases than to
> get
> > > everything you wanted in.
> > >
> > > Longer release cycles typically make people try to cram more in at the
> end
> > > because they know it will be a long time until the next one. This can
> lead
> > > to bugs being introduced or designs not being well thought out.
> Releasing
> > > frequently avoids this and also provides immediate feedback on whether
> you
> > > are going down the right path with a new feature.
> > >
> > > Ralph
> > >
> > >
> > > > On Aug 3, 2020, at 4:49 PM, Robert Middleton <os...@gmail.com>
> > > wrote:
> > > >
> > > > Thorsten,
> > > >
> > > >>> A number of these are rather large changes, so it probably
> > > >>> doesn't make sense to work on them until there's a known-good
> release,
> > > as
> > > >>> they would likely break both API and ABI compatibility.
> > > >>
> > > >> Does it really matter much if things are broken now vs. with 0.12.0
> or
> > > >> alike? Backwards compatibility was somewhat broken already when
> > > >> changing how the macros are implemented, when returning new
> LevelPtrs
> > > >> to fix threading-issues and with introducing CMAKE in favor of
> > > >> building with Maven+ANT.
> > > >>
> > > >
> > > > I have a few thoughts on that:
> > > > 1. Having a known-good release means that there should be more users,
> > > > helping to better test the library.
> > > > 2. It depends on the level of backwards-compatability breakage that
> > > > there is. For people like you who have a limited environment, having
> > > > a version that does not depend on new C++ features allows for a
> > > > 'legacy' version and a 'modern' version.
> > > > 3. Adopting a semver[1] versioning at some point would probably make
> > > > sense. If there's an API breakage that should be properly documented
> > > > as part of the versioning. Arguably since this is technically 0.11.0
> > > > version it doesn't really matter, since major version 0 allows major
> > > > API breakage.
> > > >
> > > >> Would be enough already if you would go through them and provide a
> > > >> second opinion about which of those could easily be closed. I would
> > > >> close ideas like APR database layer, CI-related stuff etc. most
> > > >> likely. Additionally some very old 0.9.7-related issues. But that
> > > >> keeps lots of other errors and improvements like new appenders.
> > > >>
> > > >
> > > > Here's my quick run-through of issues currently in JIRA:
> > > > LOG4CXX-490 - Should be easily fixable, but do we care about VS2015?
> > > > LOG4CXX-483 - Issue was resolved; I will create some documentation if
> > > > this comes up again though.
> > > > LOG4CXX-481 - I'm not sure who is the responsible member for this.
> > > > LOG4CXX-455 - This looks to still be an issue, although I'm not sure
> > > > what the correct way to do it would be. Maybe we add a new check to
> > > > also suppress exceptions?
> > > > LOG4CXX-454 - VS2013 issue, can probably be closed at the moment.
> > > > LOG4CXX-439 - Very old, not sure if still relevant at this point
> > > > LOG4CXX-438 - Very old, not sure if still relevant at this point
> > > > LOG4CXX-431 - Probably still an issue, but I think the best solution
> > > > here is to document and have a callback function that gets called
> > > > whenever a new thread starts, allowing the user to do their own
> signal
> > > > handling(a default implementation would be good too). e.g.
> > > > log4cxx::thread::setThreadStartFn --> called in new thread.
> > > > LOG4CXX-398 - It looks like this has already been fixed?
> > > > LOG4CXX-396 - Probably no longer relevant with CMAKE
> > > > LOG4CXX-389 - Very old and not enough information
> > > > LOG4CXX-384 - Very old and not enough information
> > > > LOG4CXX-377 - Very old and not enough information
> > > > LOG4CXX-374 - Very old and not correct usage of the library(using
> > > > std::endl in logging operation)
> > > > LOG4CXX-352 - Probably not an actual bug according to the comments
> > > > LOG4CXX-345 - Very old and not enough information
> > > > LOG4CXX-343 - Very old and not enough information
> > > > LOG4CXX-341 - Very old and not enough information
> > > > LOG4CXX-338 - Very old and not much activity, probably not an issue
> > > anymore
> > > > LOG4CXX-335 - Who uses sun studio anymore?
> > > > LOG4CXX-333 - Very old and likely not an issue
> > > > LOG4CXX-309 - Very old, probably not a bug in log4cxx
> > > > LOG4CXX-301 - Very old, probably best to close it out
> > > > LOG4CXX-289 - Very old, who uses Solaris anymore?
> > > > LOG4CXX-276 - Looks to be fixed
> > > > LOG4CXX-274 - very old at this point, may no longer be an issue
> > > > LOG4CXX-261 - Very old, who uses Solaris anymore?
> > > > LOG4CXX-260 - should be fixed as of LOG4CXX-457
> > > > LOG4CXX-244 - Very old versions here, I don't see the point in
> keeping
> > > > this open.
> > > > LOG4CXX-205 - Very old issue, maynot be a problem
> > > > LOG4CXX-101 - Very old issue, unless somebody has a specific need to
> > > > use mysql this is almost certainly too old to be useful.
> > > > LOG4CXX-61 - Unless APR has database support(it doesn't seem too)
> this
> > > > should probably be closed
> > > > LOG4CXX-1 - I would say we should close this; any SMTP support may or
> > > > may not even work anymore
> > > >
> > > > There are a bunch of other old issues as well, but some of them at
> > > > least have potentially enough information to do something with.
> > > >
> > > > -Robert Middleton
> > > >
> > > > [1]: https://semver.org/
> > > >
> > >
> > >
> > > --
> > Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: [log4cxx] Feature Proposals
Posted by Tobias Frost <to...@debian.org>.
On Mon, Aug 03, 2020 at 07:34:15PM -0500, Matt Sicker wrote:
> Very well said! It helps get user feedback quicker, too.
+1!
Also, the current "stable" has some many bugs (I carry 13 non Debian-specific
patches in the current Debian package…) and a new release would also fix some open
Bugs on the Debian BTS…
I really would appreciate a new release…
However, wasn't the problem in earlier tries to get log4cxx11 out of the door
that noone remembered how a release is done for this project? (At least, /me as
an outsider had that impression but I could have gotten this wrong).
--
tobi
> On Mon, Aug 3, 2020 at 19:03 Ralph Goers <ra...@dslextreme.com> wrote:
>
> > Here are my thoughts after working on several ASF projects for over 15
> > years.
> >
> > Theoretically logging projects should follow the “release early, release
> > often” philosophy. There are a few good reasons why it should be that way.
> > However, when you have a project with very few committers with limited time
> > following that can be easier said than done. Personally, I like to set a
> > goal for what I would like to see in a next release and try to meet that.
> > However, it is more important to have semi-frequent releases than to get
> > everything you wanted in.
> >
> > Longer release cycles typically make people try to cram more in at the end
> > because they know it will be a long time until the next one. This can lead
> > to bugs being introduced or designs not being well thought out. Releasing
> > frequently avoids this and also provides immediate feedback on whether you
> > are going down the right path with a new feature.
> >
> > Ralph
> >
> >
> > > On Aug 3, 2020, at 4:49 PM, Robert Middleton <os...@gmail.com>
> > wrote:
> > >
> > > Thorsten,
> > >
> > >>> A number of these are rather large changes, so it probably
> > >>> doesn't make sense to work on them until there's a known-good release,
> > as
> > >>> they would likely break both API and ABI compatibility.
> > >>
> > >> Does it really matter much if things are broken now vs. with 0.12.0 or
> > >> alike? Backwards compatibility was somewhat broken already when
> > >> changing how the macros are implemented, when returning new LevelPtrs
> > >> to fix threading-issues and with introducing CMAKE in favor of
> > >> building with Maven+ANT.
> > >>
> > >
> > > I have a few thoughts on that:
> > > 1. Having a known-good release means that there should be more users,
> > > helping to better test the library.
> > > 2. It depends on the level of backwards-compatability breakage that
> > > there is. For people like you who have a limited environment, having
> > > a version that does not depend on new C++ features allows for a
> > > 'legacy' version and a 'modern' version.
> > > 3. Adopting a semver[1] versioning at some point would probably make
> > > sense. If there's an API breakage that should be properly documented
> > > as part of the versioning. Arguably since this is technically 0.11.0
> > > version it doesn't really matter, since major version 0 allows major
> > > API breakage.
> > >
> > >> Would be enough already if you would go through them and provide a
> > >> second opinion about which of those could easily be closed. I would
> > >> close ideas like APR database layer, CI-related stuff etc. most
> > >> likely. Additionally some very old 0.9.7-related issues. But that
> > >> keeps lots of other errors and improvements like new appenders.
> > >>
> > >
> > > Here's my quick run-through of issues currently in JIRA:
> > > LOG4CXX-490 - Should be easily fixable, but do we care about VS2015?
> > > LOG4CXX-483 - Issue was resolved; I will create some documentation if
> > > this comes up again though.
> > > LOG4CXX-481 - I'm not sure who is the responsible member for this.
> > > LOG4CXX-455 - This looks to still be an issue, although I'm not sure
> > > what the correct way to do it would be. Maybe we add a new check to
> > > also suppress exceptions?
> > > LOG4CXX-454 - VS2013 issue, can probably be closed at the moment.
> > > LOG4CXX-439 - Very old, not sure if still relevant at this point
> > > LOG4CXX-438 - Very old, not sure if still relevant at this point
> > > LOG4CXX-431 - Probably still an issue, but I think the best solution
> > > here is to document and have a callback function that gets called
> > > whenever a new thread starts, allowing the user to do their own signal
> > > handling(a default implementation would be good too). e.g.
> > > log4cxx::thread::setThreadStartFn --> called in new thread.
> > > LOG4CXX-398 - It looks like this has already been fixed?
> > > LOG4CXX-396 - Probably no longer relevant with CMAKE
> > > LOG4CXX-389 - Very old and not enough information
> > > LOG4CXX-384 - Very old and not enough information
> > > LOG4CXX-377 - Very old and not enough information
> > > LOG4CXX-374 - Very old and not correct usage of the library(using
> > > std::endl in logging operation)
> > > LOG4CXX-352 - Probably not an actual bug according to the comments
> > > LOG4CXX-345 - Very old and not enough information
> > > LOG4CXX-343 - Very old and not enough information
> > > LOG4CXX-341 - Very old and not enough information
> > > LOG4CXX-338 - Very old and not much activity, probably not an issue
> > anymore
> > > LOG4CXX-335 - Who uses sun studio anymore?
> > > LOG4CXX-333 - Very old and likely not an issue
> > > LOG4CXX-309 - Very old, probably not a bug in log4cxx
> > > LOG4CXX-301 - Very old, probably best to close it out
> > > LOG4CXX-289 - Very old, who uses Solaris anymore?
> > > LOG4CXX-276 - Looks to be fixed
> > > LOG4CXX-274 - very old at this point, may no longer be an issue
> > > LOG4CXX-261 - Very old, who uses Solaris anymore?
> > > LOG4CXX-260 - should be fixed as of LOG4CXX-457
> > > LOG4CXX-244 - Very old versions here, I don't see the point in keeping
> > > this open.
> > > LOG4CXX-205 - Very old issue, maynot be a problem
> > > LOG4CXX-101 - Very old issue, unless somebody has a specific need to
> > > use mysql this is almost certainly too old to be useful.
> > > LOG4CXX-61 - Unless APR has database support(it doesn't seem too) this
> > > should probably be closed
> > > LOG4CXX-1 - I would say we should close this; any SMTP support may or
> > > may not even work anymore
> > >
> > > There are a bunch of other old issues as well, but some of them at
> > > least have potentially enough information to do something with.
> > >
> > > -Robert Middleton
> > >
> > > [1]: https://semver.org/
> > >
> >
> >
> > --
> Matt Sicker <bo...@gmail.com>
Re: [log4cxx] Feature Proposals
Posted by Matt Sicker <bo...@gmail.com>.
Very well said! It helps get user feedback quicker, too.
On Mon, Aug 3, 2020 at 19:03 Ralph Goers <ra...@dslextreme.com> wrote:
> Here are my thoughts after working on several ASF projects for over 15
> years.
>
> Theoretically logging projects should follow the “release early, release
> often” philosophy. There are a few good reasons why it should be that way.
> However, when you have a project with very few committers with limited time
> following that can be easier said than done. Personally, I like to set a
> goal for what I would like to see in a next release and try to meet that.
> However, it is more important to have semi-frequent releases than to get
> everything you wanted in.
>
> Longer release cycles typically make people try to cram more in at the end
> because they know it will be a long time until the next one. This can lead
> to bugs being introduced or designs not being well thought out. Releasing
> frequently avoids this and also provides immediate feedback on whether you
> are going down the right path with a new feature.
>
> Ralph
>
>
> > On Aug 3, 2020, at 4:49 PM, Robert Middleton <os...@gmail.com>
> wrote:
> >
> > Thorsten,
> >
> >>> A number of these are rather large changes, so it probably
> >>> doesn't make sense to work on them until there's a known-good release,
> as
> >>> they would likely break both API and ABI compatibility.
> >>
> >> Does it really matter much if things are broken now vs. with 0.12.0 or
> >> alike? Backwards compatibility was somewhat broken already when
> >> changing how the macros are implemented, when returning new LevelPtrs
> >> to fix threading-issues and with introducing CMAKE in favor of
> >> building with Maven+ANT.
> >>
> >
> > I have a few thoughts on that:
> > 1. Having a known-good release means that there should be more users,
> > helping to better test the library.
> > 2. It depends on the level of backwards-compatability breakage that
> > there is. For people like you who have a limited environment, having
> > a version that does not depend on new C++ features allows for a
> > 'legacy' version and a 'modern' version.
> > 3. Adopting a semver[1] versioning at some point would probably make
> > sense. If there's an API breakage that should be properly documented
> > as part of the versioning. Arguably since this is technically 0.11.0
> > version it doesn't really matter, since major version 0 allows major
> > API breakage.
> >
> >> Would be enough already if you would go through them and provide a
> >> second opinion about which of those could easily be closed. I would
> >> close ideas like APR database layer, CI-related stuff etc. most
> >> likely. Additionally some very old 0.9.7-related issues. But that
> >> keeps lots of other errors and improvements like new appenders.
> >>
> >
> > Here's my quick run-through of issues currently in JIRA:
> > LOG4CXX-490 - Should be easily fixable, but do we care about VS2015?
> > LOG4CXX-483 - Issue was resolved; I will create some documentation if
> > this comes up again though.
> > LOG4CXX-481 - I'm not sure who is the responsible member for this.
> > LOG4CXX-455 - This looks to still be an issue, although I'm not sure
> > what the correct way to do it would be. Maybe we add a new check to
> > also suppress exceptions?
> > LOG4CXX-454 - VS2013 issue, can probably be closed at the moment.
> > LOG4CXX-439 - Very old, not sure if still relevant at this point
> > LOG4CXX-438 - Very old, not sure if still relevant at this point
> > LOG4CXX-431 - Probably still an issue, but I think the best solution
> > here is to document and have a callback function that gets called
> > whenever a new thread starts, allowing the user to do their own signal
> > handling(a default implementation would be good too). e.g.
> > log4cxx::thread::setThreadStartFn --> called in new thread.
> > LOG4CXX-398 - It looks like this has already been fixed?
> > LOG4CXX-396 - Probably no longer relevant with CMAKE
> > LOG4CXX-389 - Very old and not enough information
> > LOG4CXX-384 - Very old and not enough information
> > LOG4CXX-377 - Very old and not enough information
> > LOG4CXX-374 - Very old and not correct usage of the library(using
> > std::endl in logging operation)
> > LOG4CXX-352 - Probably not an actual bug according to the comments
> > LOG4CXX-345 - Very old and not enough information
> > LOG4CXX-343 - Very old and not enough information
> > LOG4CXX-341 - Very old and not enough information
> > LOG4CXX-338 - Very old and not much activity, probably not an issue
> anymore
> > LOG4CXX-335 - Who uses sun studio anymore?
> > LOG4CXX-333 - Very old and likely not an issue
> > LOG4CXX-309 - Very old, probably not a bug in log4cxx
> > LOG4CXX-301 - Very old, probably best to close it out
> > LOG4CXX-289 - Very old, who uses Solaris anymore?
> > LOG4CXX-276 - Looks to be fixed
> > LOG4CXX-274 - very old at this point, may no longer be an issue
> > LOG4CXX-261 - Very old, who uses Solaris anymore?
> > LOG4CXX-260 - should be fixed as of LOG4CXX-457
> > LOG4CXX-244 - Very old versions here, I don't see the point in keeping
> > this open.
> > LOG4CXX-205 - Very old issue, maynot be a problem
> > LOG4CXX-101 - Very old issue, unless somebody has a specific need to
> > use mysql this is almost certainly too old to be useful.
> > LOG4CXX-61 - Unless APR has database support(it doesn't seem too) this
> > should probably be closed
> > LOG4CXX-1 - I would say we should close this; any SMTP support may or
> > may not even work anymore
> >
> > There are a bunch of other old issues as well, but some of them at
> > least have potentially enough information to do something with.
> >
> > -Robert Middleton
> >
> > [1]: https://semver.org/
> >
>
>
> --
Matt Sicker <bo...@gmail.com>
Re: [log4cxx] Feature Proposals
Posted by Ralph Goers <ra...@dslextreme.com>.
Here are my thoughts after working on several ASF projects for over 15 years.
Theoretically logging projects should follow the “release early, release often” philosophy. There are a few good reasons why it should be that way. However, when you have a project with very few committers with limited time following that can be easier said than done. Personally, I like to set a goal for what I would like to see in a next release and try to meet that. However, it is more important to have semi-frequent releases than to get everything you wanted in.
Longer release cycles typically make people try to cram more in at the end because they know it will be a long time until the next one. This can lead to bugs being introduced or designs not being well thought out. Releasing frequently avoids this and also provides immediate feedback on whether you are going down the right path with a new feature.
Ralph
> On Aug 3, 2020, at 4:49 PM, Robert Middleton <os...@gmail.com> wrote:
>
> Thorsten,
>
>>> A number of these are rather large changes, so it probably
>>> doesn't make sense to work on them until there's a known-good release, as
>>> they would likely break both API and ABI compatibility.
>>
>> Does it really matter much if things are broken now vs. with 0.12.0 or
>> alike? Backwards compatibility was somewhat broken already when
>> changing how the macros are implemented, when returning new LevelPtrs
>> to fix threading-issues and with introducing CMAKE in favor of
>> building with Maven+ANT.
>>
>
> I have a few thoughts on that:
> 1. Having a known-good release means that there should be more users,
> helping to better test the library.
> 2. It depends on the level of backwards-compatability breakage that
> there is. For people like you who have a limited environment, having
> a version that does not depend on new C++ features allows for a
> 'legacy' version and a 'modern' version.
> 3. Adopting a semver[1] versioning at some point would probably make
> sense. If there's an API breakage that should be properly documented
> as part of the versioning. Arguably since this is technically 0.11.0
> version it doesn't really matter, since major version 0 allows major
> API breakage.
>
>> Would be enough already if you would go through them and provide a
>> second opinion about which of those could easily be closed. I would
>> close ideas like APR database layer, CI-related stuff etc. most
>> likely. Additionally some very old 0.9.7-related issues. But that
>> keeps lots of other errors and improvements like new appenders.
>>
>
> Here's my quick run-through of issues currently in JIRA:
> LOG4CXX-490 - Should be easily fixable, but do we care about VS2015?
> LOG4CXX-483 - Issue was resolved; I will create some documentation if
> this comes up again though.
> LOG4CXX-481 - I'm not sure who is the responsible member for this.
> LOG4CXX-455 - This looks to still be an issue, although I'm not sure
> what the correct way to do it would be. Maybe we add a new check to
> also suppress exceptions?
> LOG4CXX-454 - VS2013 issue, can probably be closed at the moment.
> LOG4CXX-439 - Very old, not sure if still relevant at this point
> LOG4CXX-438 - Very old, not sure if still relevant at this point
> LOG4CXX-431 - Probably still an issue, but I think the best solution
> here is to document and have a callback function that gets called
> whenever a new thread starts, allowing the user to do their own signal
> handling(a default implementation would be good too). e.g.
> log4cxx::thread::setThreadStartFn --> called in new thread.
> LOG4CXX-398 - It looks like this has already been fixed?
> LOG4CXX-396 - Probably no longer relevant with CMAKE
> LOG4CXX-389 - Very old and not enough information
> LOG4CXX-384 - Very old and not enough information
> LOG4CXX-377 - Very old and not enough information
> LOG4CXX-374 - Very old and not correct usage of the library(using
> std::endl in logging operation)
> LOG4CXX-352 - Probably not an actual bug according to the comments
> LOG4CXX-345 - Very old and not enough information
> LOG4CXX-343 - Very old and not enough information
> LOG4CXX-341 - Very old and not enough information
> LOG4CXX-338 - Very old and not much activity, probably not an issue anymore
> LOG4CXX-335 - Who uses sun studio anymore?
> LOG4CXX-333 - Very old and likely not an issue
> LOG4CXX-309 - Very old, probably not a bug in log4cxx
> LOG4CXX-301 - Very old, probably best to close it out
> LOG4CXX-289 - Very old, who uses Solaris anymore?
> LOG4CXX-276 - Looks to be fixed
> LOG4CXX-274 - very old at this point, may no longer be an issue
> LOG4CXX-261 - Very old, who uses Solaris anymore?
> LOG4CXX-260 - should be fixed as of LOG4CXX-457
> LOG4CXX-244 - Very old versions here, I don't see the point in keeping
> this open.
> LOG4CXX-205 - Very old issue, maynot be a problem
> LOG4CXX-101 - Very old issue, unless somebody has a specific need to
> use mysql this is almost certainly too old to be useful.
> LOG4CXX-61 - Unless APR has database support(it doesn't seem too) this
> should probably be closed
> LOG4CXX-1 - I would say we should close this; any SMTP support may or
> may not even work anymore
>
> There are a bunch of other old issues as well, but some of them at
> least have potentially enough information to do something with.
>
> -Robert Middleton
>
> [1]: https://semver.org/
>
Re: [log4cxx] Feature Proposals
Posted by Tobias Frost <to...@debian.org>.
On Mon, Aug 03, 2020 at 07:49:14PM -0400, Robert Middleton wrote:
> Thorsten,
>
> > > A number of these are rather large changes, so it probably
> > > doesn't make sense to work on them until there's a known-good release, as
> > > they would likely break both API and ABI compatibility.
> >
> > Does it really matter much if things are broken now vs. with 0.12.0 or
> > alike? Backwards compatibility was somewhat broken already when
> > changing how the macros are implemented, when returning new LevelPtrs
> > to fix threading-issues and with introducing CMAKE in favor of
> > building with Maven+ANT.
> >
>
> I have a few thoughts on that:
> 1. Having a known-good release means that there should be more users,
> helping to better test the library.
> 2. It depends on the level of backwards-compatability breakage that
> there is. For people like you who have a limited environment, having
> a version that does not depend on new C++ features allows for a
> 'legacy' version and a 'modern' version.
> 3. Adopting a semver[1] versioning at some point would probably make
> sense. If there's an API breakage that should be properly documented
> as part of the versioning. Arguably since this is technically 0.11.0
> version it doesn't really matter, since major version 0 allows major
> API breakage.
While the version is at 0.x.x, the at least the old auttools based build
system declares SONAME to be 10 [1], so log4cxx is declaring a stable ABI/API.
However, as said in an earlier thread, this is not a problem for a distribution
(like Debian) as this is usual business to cope with ABI/API changes. (if it
does not happen too ofthen, as a library transition means some work.)
[1] The version currently in Debian:
$objdump -p liblog4cxx.so | grep SONAME
SONAME liblog4cxx.so.10
--
tobi
Re: [log4cxx] Feature Proposals
Posted by Robert Middleton <os...@gmail.com>.
Thorsten,
> > A number of these are rather large changes, so it probably
> > doesn't make sense to work on them until there's a known-good release, as
> > they would likely break both API and ABI compatibility.
>
> Does it really matter much if things are broken now vs. with 0.12.0 or
> alike? Backwards compatibility was somewhat broken already when
> changing how the macros are implemented, when returning new LevelPtrs
> to fix threading-issues and with introducing CMAKE in favor of
> building with Maven+ANT.
>
I have a few thoughts on that:
1. Having a known-good release means that there should be more users,
helping to better test the library.
2. It depends on the level of backwards-compatability breakage that
there is. For people like you who have a limited environment, having
a version that does not depend on new C++ features allows for a
'legacy' version and a 'modern' version.
3. Adopting a semver[1] versioning at some point would probably make
sense. If there's an API breakage that should be properly documented
as part of the versioning. Arguably since this is technically 0.11.0
version it doesn't really matter, since major version 0 allows major
API breakage.
> Would be enough already if you would go through them and provide a
> second opinion about which of those could easily be closed. I would
> close ideas like APR database layer, CI-related stuff etc. most
> likely. Additionally some very old 0.9.7-related issues. But that
> keeps lots of other errors and improvements like new appenders.
>
Here's my quick run-through of issues currently in JIRA:
LOG4CXX-490 - Should be easily fixable, but do we care about VS2015?
LOG4CXX-483 - Issue was resolved; I will create some documentation if
this comes up again though.
LOG4CXX-481 - I'm not sure who is the responsible member for this.
LOG4CXX-455 - This looks to still be an issue, although I'm not sure
what the correct way to do it would be. Maybe we add a new check to
also suppress exceptions?
LOG4CXX-454 - VS2013 issue, can probably be closed at the moment.
LOG4CXX-439 - Very old, not sure if still relevant at this point
LOG4CXX-438 - Very old, not sure if still relevant at this point
LOG4CXX-431 - Probably still an issue, but I think the best solution
here is to document and have a callback function that gets called
whenever a new thread starts, allowing the user to do their own signal
handling(a default implementation would be good too). e.g.
log4cxx::thread::setThreadStartFn --> called in new thread.
LOG4CXX-398 - It looks like this has already been fixed?
LOG4CXX-396 - Probably no longer relevant with CMAKE
LOG4CXX-389 - Very old and not enough information
LOG4CXX-384 - Very old and not enough information
LOG4CXX-377 - Very old and not enough information
LOG4CXX-374 - Very old and not correct usage of the library(using
std::endl in logging operation)
LOG4CXX-352 - Probably not an actual bug according to the comments
LOG4CXX-345 - Very old and not enough information
LOG4CXX-343 - Very old and not enough information
LOG4CXX-341 - Very old and not enough information
LOG4CXX-338 - Very old and not much activity, probably not an issue anymore
LOG4CXX-335 - Who uses sun studio anymore?
LOG4CXX-333 - Very old and likely not an issue
LOG4CXX-309 - Very old, probably not a bug in log4cxx
LOG4CXX-301 - Very old, probably best to close it out
LOG4CXX-289 - Very old, who uses Solaris anymore?
LOG4CXX-276 - Looks to be fixed
LOG4CXX-274 - very old at this point, may no longer be an issue
LOG4CXX-261 - Very old, who uses Solaris anymore?
LOG4CXX-260 - should be fixed as of LOG4CXX-457
LOG4CXX-244 - Very old versions here, I don't see the point in keeping
this open.
LOG4CXX-205 - Very old issue, maynot be a problem
LOG4CXX-101 - Very old issue, unless somebody has a specific need to
use mysql this is almost certainly too old to be useful.
LOG4CXX-61 - Unless APR has database support(it doesn't seem too) this
should probably be closed
LOG4CXX-1 - I would say we should close this; any SMTP support may or
may not even work anymore
There are a bunch of other old issues as well, but some of them at
least have potentially enough information to do something with.
-Robert Middleton
[1]: https://semver.org/
Re: [log4cxx] Feature Proposals
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Robert Middleton,
am Montag, 3. August 2020 um 02:17 schrieben Sie:
> I'd like to propose some new features/updates for log4cxx, if there's
> interest.
Things mostly read good and interesting to me. Even though I would
suffer myself a lot most likely, as my currently used compiler/IDE is
mostly not even compatible with C++11. :-)
> A number of these are rather large changes, so it probably
> doesn't make sense to work on them until there's a known-good release, as
> they would likely break both API and ABI compatibility.
Does it really matter much if things are broken now vs. with 0.12.0 or
alike? Backwards compatibility was somewhat broken already when
changing how the macros are implemented, when returning new LevelPtrs
to fix threading-issues and with introducing CMAKE in favor of
building with Maven+ANT.
We might not need to care too much in favor of implementing changes
users benefit from.
> 3. Removal of maven for site generation.[...]
The good thing about the current approach is that Maven does some
things automatically, which would otherwise not be available or need
to be maintained manually. Think of the changes-report, providing
mailing list info, linking to issue tracker, even dependencies could
be enhanced. Additionally, ANT is used to simply automate somewhat
cross-platform things which would need to be implemented otherwise.
Maven shouldn't be used for building anymore and not using it for
releasing would simply require another implementation. Even though
things seemed to have somewhat worked for you. So this doesn't read
too important to me and things can be changed step-by-step: Change
usage of ANT, using Doxygen at least as PoC for some sites can simply
be added as Doxygen is already needed anyway etc.
> 4. ABI compatibility.[...]
In general I prefer more straightforward class declarations and
wouldn't care too much about changing each and every class to pimpl.
> 2. Remove the autotools build[...]Is
> there a particular reason to keep it around still?
AFAIK only backwards compatibility.
> 3. Support for log4j2-style XML/JSON/YAML documents.[...]
For the time being, it might be far easier to document more on our own
instead. Might be a good chance to add Doxygen-based content like you
proposed.
> Going through the currently open issues in JIRA, there's also a large
> number that are either so old that they don't make much sense, or may have
> been fixed already. Would it make sense to go through them at some point?
> That's probably not something that I can do alone, but I can help to go
> through them.
Would be enough already if you would go through them and provide a
second opinion about which of those could easily be closed. I would
close ideas like APR database layer, CI-related stuff etc. most
likely. Additionally some very old 0.9.7-related issues. But that
keeps lots of other errors and improvements like new appenders.
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