Re: [log4php]

[Christian Grobmeier]

Hi,

On Thu, May 17, 2018, at 00:20, Rocska Ádám wrote:
> I have just recently joined, and I plan to do my first contributions on 
> log4php.

Welcome!

> For my next iteration I would like to focus on the following :
> I'd like to have a full namespace coverage throughout the repo. 

+1
We have a branch for that already, please check if you can find it. There is 
some work done already

> I'd like to do a small test namespace refactor, to open the opportunity 
> for separation of tests into unit, component, integration, and system 
> level tests 

I don't understand this, can you explain?

> I'd like to increase unit test coverage in the library 

always +1

> I'd like to introduce docbook, or any other oldie but goodie manual 
> generator to the repo 

I hope Ivan joins in here as well. I am OK with docbook but I would like to 
explore other opportunities too. In example Ivan had brought up sphinx doc at 
some point. Personally I do like Jekyll. So let us discuss this.

> If these suggestions are fine for the v3 branch, please let me know, and 
> I’ll start working on them. 

If you can start with namespaces first I am sure nobody is opposed :)

> I plan to perform the changes via a github fork, and pull request 
> submission against the v3 branch.

Sounds awesome.

> Any help in terms of rules, guidelines, any apache specific whatsoever 
> will be highly appreciated.

Start contributing, we will all be here to help you with formalites. Basically 
everybody "grows into" apache.
I have seen your contributor agreement is on file, I don't see any blockers for 
you.

Again, welcome and have fun!

Christian

> 
> Thank you for the opportunity to contribute,
> Adam

Re: [LOG4PHP] Abandoned? Contributing?

[Christian Grobmeier]

Hello Kate,

On Sun, Oct 27, 2019, at 06:46, Kate Gray wrote:
> As I said, I'd be glad to.   I started working on getting log4php 
> working properly for PHP 7, as PHP5 is end of life, and no longer 
> updated.

I am one of the original developers of Log4php (at Apache). Unfortunately, I 
had not time to keep on going with Log4php development in the past time. Same 
goes for Ivan, who did a lot of work with Log4php as well.

I would love to assist you as much as I can and maybe I am able to flesh out 
some time too.

Please note that we have started two efforts before we run out of time.

First, we have been starting to add namespaces for preparing a v3:
https://github.com/apache/logging-log4php/tree/v3

Second, we have discussed to support the Logging PSR:
https://www.php-fig.org/psr/psr-3/

If you are up for it, I think we should look at the v3 specically and try to 
update it to run with php7.
Also maybe add the PSR support there.

What do you think? I will follow any discussions dev@ more closely not, looking 
for log4php tags.

Thanks for stepping in!

Kind regards,
Christian

> 
> Where would the best place to submit code be?  I've started with a pull 
> request on the GitHub mirror (which is what packagist seems to use).  
> The docs suggest adding patches to issues, but nobody seems to manage 
> those.
> 
> Do I need to sign the Apache Contributor agreement?  I usually release 
> my code as public domain or WTFPL, but I have no issue with keeping the 
> license the same on contributed code.
> 
> I have no ability to clean up docs, or close issues, so I'm limited in 
> what I can do there.
> 
> Kate
> 
> From: Ralph Goers 
> Sent: Sunday, October 27, 2019 12:26:14 AM
> To: dev@logging.apache.org 
> Subject: Re: [LOG4PHP] Abandoned? Contributing?
> 
> Several of the logging services projects are in need of attention and 
> need more volunteers to help maintain them. Log4PHP is one of those.
> 
> Any help you can provide would be most welcome!
> 
> Ralph
> 
> > On Oct 26, 2019, at 2:36 PM, Kate Gray  wrote:
> >
> > Hello,
> >
> > Has log4php been abandoned?
> >
> > Looking at the log4php site, I can see that there's a lot of outdated 
> > information.
> >
> > Installation suggests using the PEAR channel, but that was shut down:
> >
> > https://logging.apache.org/log4php/install.html
> > http://apache-logging.6191.n7.nabble.com/NOTICE-pear-apache-org-is-being-shut-down-April-20th-2017-td75208.html
> >
> > An issue about this has been open for over two years.
> >
> > I tried to subscribe to the mailing list for log4php using the information 
> > provided, but that informs me that the list is shut down and migrated to 
> > this one.
> >
> > I'm going through the issues and going to comment where I can - I have time 
> > and am willing to help.  If there's anything I can do to help keep this 
> > component (and the documentation) updated, I'd be glad to help where I can.
> >
> > Kate Gray
> > [NOTICE] pear.apache.org is being shut down, April 20th 
> > 2017.
> > [NOTICE] pear.apache.org is being shut down, April 20th 2017. Hi folks, as 
> > the subject says, we'll be shutting down pear.apache.org in about 30 days 
> > from now. There is no immediate replacement...
> > apache-logging.6191.n7.nabble.com
> >
> 
> 
>

Re: log4php update

[Christian Grobmeier]

I think we once had a release guide, but I also think it was on a wiki which 
was removed?
https://cwiki.apache.org/confluence/display/logging-log4php

Guess we have to renew it

-- 
  Christian Grobmeier
  grobme...@gmail.com

On Thu, Sep 12, 2019, at 17:48, Matt Sicker wrote:
> Do we have a release guide for this component? I don't think a new
> release has been done in a few years at least.
> 
> On Thu, 12 Sep 2019 at 03:23, Daniil Skomarovskyi <0xbad0c...@gmail.com> 
> wrote:
> >
> > Hi guys! I've made a merge request to the log4php repository and it's
> > merged already. Could someone update the package on
> > https://packagist.org/packages/apache/log4php, please!
> 
> 
> 
> -- 
> Matt Sicker 
>

Re: log4php update

[Christian Grobmeier]

Hi


On Tue, Oct 29, 2019, at 22:31, Kate Gray wrote:
> Whoops, sent that to you, not the list.
> 
> Is this what you're looking for?
> 
> https://cwiki.apache.org/confluence/display/LOGGINGLOG4PHP/ReleaseProcedure
> 
> It looks like the URL of the project has been changed from 
> "logging-log4php" to "LOGGINGLOG4PHP".

oh cool, you found it. Yes, that's it. Unfortunately it's a bit dated. It's 
stil l using SVN. We also discussed if we could replace Maven with something 
else, but haven't found a solution (if I remember correctly)

Christian

> 
> Kate
> ____
> From: Kate Gray 
> Sent: Tuesday, October 29, 2019 4:30 PM
> To: Christian Grobmeier 
> Subject: Re: log4php update
> 
> Is this it?
> 
> https://cwiki.apache.org/confluence/display/LOGGINGLOG4PHP/ReleaseProcedure
> 
> From: Christian Grobmeier 
> Sent: Tuesday, October 29, 2019 3:07 PM
> To: dev@logging.apache.org 
> Subject: Re: log4php update
> 
> I think we once had a release guide, but I also think it was on a wiki 
> which was removed?
> https://cwiki.apache.org/confluence/display/logging-log4php
> 
> Guess we have to renew it
> 
> --
>   Christian Grobmeier
>   grobme...@gmail.com
> 
> On Thu, Sep 12, 2019, at 17:48, Matt Sicker wrote:
> > Do we have a release guide for this component? I don't think a new
> > release has been done in a few years at least.
> >
> > On Thu, 12 Sep 2019 at 03:23, Daniil Skomarovskyi <0xbad0c...@gmail.com> 
> > wrote:
> > >
> > > Hi guys! I've made a merge request to the log4php repository and it's
> > > merged already. Could someone update the package on
> > > https://packagist.org/packages/apache/log4php, please!
> >
> >
> >
> > --
> > Matt Sicker 
> >
>

Re: [LOG4PHP] Site Generation

[Christian Grobmeier]

I would love if we could separate the logging pages from the release cycle.
There was once a blocker using Phing, I think it had something to do with not 
supporting UTF-8 correclty. Most likely this is gone by now and I would be fine 
to move on.


-- 
  Christian Grobmeier
  grobme...@gmail.com

On Wed, Oct 30, 2019, at 05:04, Ralph Goers wrote:
> FWIW,  
> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site
>  
> <https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site>
>  discusses how the logging services web site and the individual logging 
> projects are built.  I’ve heard rumblings that the ASF CMS is being or has 
> been replaced or that you can at least use git but I haven’t investigated 
> that. I can tell you I have a love/hate relationship with how the Log4j 
> documentation is created. For Java it makes more sense since it generates 
> some neat stuff automatically but I am not sure what added value it would 
> bring to a project like log4php.
> 
> So as far as that goes, the only thing that matters is that the source 
> for the site is in source control - we could even request a GitHub 
> project to host all the logging subproject web sites if we want - and 
> that the generated site(s) are checked in to match ASF Infra’s 
> expectations. You can read about the ASF CMS at 
> https://www.apache.org/dev/cms <https://www.apache.org/dev/cms>, The 
> only documentation on using git for the rendered site that I could find 
> is at https://blogs.apache.org/infra/entry/git_based_websites_available 
> <https://blogs.apache.org/infra/entry/git_based_websites_available>.
> 
> Ralph
> 
> > On Oct 29, 2019, at 8:35 PM, Kate Gray  wrote:
> > 
> > I've updated some of the source documents.  It looks like it's pretty 
> > broken - apigen, for example, isn't stable above PHP5.The Release 
> > Candidate is really brittle, requiring specific commits of other libraries.
> > 
> > There's an issue, LOG4PHP-192, that mentions using phing.  As I mentioned 
> > in the issue, I'm personally in favor of using phing, as it would make it 
> > possible to build .phar (compiled archives) that are a bit easier to work 
> > with.  A lot of tools are distributed that way these days.
> > 
> > If we're just generating .html files, we could go the native PHP way and 
> > use Sculpin to generate the site.  It takes twig (a simple template 
> > engine), markdown and spits out static HTML.
> > 
> > API documentation could be done with phpDocumentor, phpDox, or doxygen.  
> > I'm a bit partial to phpDox personally.
> > 
> > What do people think?
> > 
> > Kate
> 
>

Re: [VOTE] [log4xx] Release log4cxx 0.11.0

[Christian Grobmeier]

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: Your project website

[Christian Grobmeier]

Hi,

I see there is some activity on the site - I discovered log4php and the audit 
component are currently 404.
the links look correct, it seems as the sites are not at their location.

Christian

On Tue, Sep 1, 2020, at 03:24, Robert Middleton wrote:
> Something is funny with logging.apache.org - the links for log4cxx and
> chainsaw lead to a 404 at the moment.  I'm not sure if that's because
> things are changing or if something else is messed up.
> 
> I assume this means now that the site will be committed to git instead of
> svn?
> 
> -Robert Middleton
> 
> On Mon, Aug 31, 2020 at 4:15 PM Ralph Goers 
> wrote:
> 
> > The download link for Log4net is wrong even for the live site. For some
> > reason it doesn’t seem it was updated during the release process.
> >
> > Ralph
> >
> > > On Aug 31, 2020, at 11:47 AM, Matt Sicker  wrote:
> > >
> > > Looks good to me. The download link on the log4net page is broken, but
> > > everything else looks good.
> > >
> > > On Mon, 31 Aug 2020 at 13:31, Ralph Goers  > > wrote:
> > >>
> > >> The logging site is now working properly.  Please look at
> > http://logging.staged.apache.org  <
> > http://logging.staged.apache.org/ >.
> > I will not work on documenting this in Confluence. I know that not all of
> > the past log4j releases are in git yet. I will be taking care of that soon.
> > Please let me know if you see any other problems.
> > >>
> > >> Ralph
> > >>
> > >>> On Aug 30, 2020, at 10:21 PM, Ralph Goers 
> > wrote:
> > >>>
> > >>> Another follow-up.  After a discussion on Slack with infra I
> > determined that using GitHub pages isn’t what we want to do. I then
> > modified the site to work with the normal “pub/sub” that infra supports via
> > the .asf.yaml files. The documentation for that says it supports having
> > sub-projects be hosted in separate repos so I followed those instructions.
> > Unfortunately, those sites are not deploying. I have opened
> > https://issues.apache.org/jira/browse/INFRA-20792 <
> > https://issues.apache.org/jira/browse/INFRA-20792> to try to get this
> > addressed but have not gotten a response to this yet nor to the questions I
> > asked on Slack. Not surprising since it was a Sunday afternoon.
> > >>>
> > >>> I have not documented the process yet since I am not sure I did
> > everything correctly.
> > >>>
> > >>> FWIW, I plan to hold off starting the log4j release process until this
> > is resolve since trying to commit a new Log4j web site using svn has been
> > taking at least 30 minutes. My experience in committing the preview site to
> > my personal GitHub site has shown that it is significantly faster.
> > >>>
> > >>> Ralph
> > >>>
> >  On Aug 30, 2020, at 11:29 AM, Ralph Goers 
> > wrote:
> > 
> >  I have created the logging site in git at
> > https://github.com/apache/logging-site <
> > https://github.com/apache/logging-site>.  I used jbake to generate the
> > CMS portion of the site. It is pretty easy. All you have to do is
> > 
> >  cd sources
> >  Make the required changes
> >  mvn install
> > 
> >  You will then have a viewable site in the /docs directory and can
> > view it by opening docs/index.html in the browser.
> > 
> >  I created a .asf.yaml file with the intention of having a preview
> > site on the asf-staging branch and the live site at master. However, the
> > instructions for the staging site seem to imply using pypubsub where I am
> > attempting to use GitHub Pages for the live site. These seem to conflict as
> > GitHub pages wants the site in the /docs directory while pypubsub seems to
> > imply it needs to be in the root directory.
> > 
> >  I am able to get a site up at https://apache.github.io/logging-site <
> > https://apache.github.io/logging-site> but it is not being reflected at
> > https://logging.apache.org .
> > 
> >  At this point without clearer instructions from infra I am not sure
> > where to go to make the site live.
> > 
> >  I have started a confluence page to document managing the site but it
> > seems much easier than using the CMS.
> > 
> >  Ralph
> > 
> > 
> > 
> > > On Aug 5, 2020, at 5:30 AM, Andrew Wetmore 
> > wrote:
> > >
> > > Hi:
> > >
> > > I am part of the Infrastructure team, and am writing to ask whether
> > your
> > > project is still using the Apache CMS for your project website. As
> > you
> > > know, the CMS is reaching end-of-life, and we need projects to move
> > their
> > > websites onto a different option within the next few weeks.
> > >
> > > There are several alternatives available, including those listed on
> > this
> > > page [1] on managing project websites. Infra is assembling a Wiki
> > page [2]
> > > on migrating a website from the CMS, and is looking forward to
> > helping
> > > projects

Re: [VOTE] Move Log4PHP to dormant status

[Christian Grobmeier]

Very sad, but +1.

Code base became very old and there is lots to do. 

--
The Apache Software Foundation
V.P., Data Privacy

On Wed, Dec 9, 2020, at 22:20, Ralph Goers wrote:
> I started a discussion several days ago regarding moving Log4PHP to 
> dormant status and have gotten no feedback. Given there has been no 
> development activity in years and there is no one actively working on 
> the project it seems it should be moved to dormant status.
> 
> This vote will be open for 72hrs.
> 
> Ralph
>

Re: Log4J 1.x progress, pull request(s), plans

[Christian Grobmeier]

Hello

I have been the person cutting the 1.2.17 release and what I remember was it 
was a super hard build. I had to install some VMs because there were weird 
dependencies to this build. Building it fully will not be easy, but I can also 
look into some mails whatever I found from that time. 
Here is some build info.:
https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
Some unit tests only run with a Windows VM

It would be easier to remove some components, but BC is broken then.

We told people in August 2015 this is EOL. I am honestly surprised that we 
discuss a new release after 7 years. To my understanding the JMSAppender issue 
is not as critical (just don't configure it). If a reconfiguration of system is 
not on the cards, I wonder if upgrading from 1.2.17 to 1.2.18 is.

That said i don't think we should resurrect it. 

If somebody really wants to work on, I also don't think we should go through 
the incubator. We can do this using the normal processes and apply patches, 
vote on new committers etc.

My 2 cents.

Christian


On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
> Improving legacy compatibility is what I've been pushing. I agree with
> Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial can of
> worms.
>
> Gary
>
> On Sun, Dec 19, 2021, 17:55 Matt Sicker  wrote:
>
>> The alternative is to polish the 1.x compatibility in 2.x which is both
>> actively maintained and much easier to get releases published. Then users
>> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
>> regardless of how many warnings we add to a potential 1.x release, we’ll
>> get inundated with CVE reports, bug reports, and email, all related solely
>> to 1.x which none of us wish to maintain (especially given most of us
>> weren’t even involved in 1.x back when it was in development).
>> --
>> Matt Sicker
>>
>> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
>> sitnikov.vladi...@gmail.com> wrote:
>> >
>> > Matt>but at least one release using the normal ASF release requirements
>> is
>> > required to graduate.
>> >
>> > Thanks for the reminder, and I am sure preparing the release won't be an
>> > issue. I refactored release scripts for both Calcite and JMeter, and I am
>> > sure log4j 1.x is doable.
>> >
>> >> compared to the alternatives discussed in this thread.
>> >
>> > I must be missing the alternarives.
>> > Can you please highlight them?
>> >
>> > There were multiple suggestions and various PRs from external
>> contributora,
>> > yet the committers respond with vaugue messages.
>> >
>> > The code must be buildable, so moving to Git, and adding GitHub CI is the
>> > mandatory step.
>> > Of course, the existing PMC members and committers might have opinions on
>> > the way to fix the issues, however I see no reasons for the team to deny
>> > Git.
>> >
>> > The migration to Git consumes absolutely no resources from committers,
>> > except a couple of +1 votes.
>> >
>> > Unfortunately, even a trivial improvement like Git is ignored by Logging
>> > PMC.
>> >
>> > So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x
>> > seriously.
>> >
>> > Vladimir
>>
>>

Re: New Log4j 1 repo

[Christian Grobmeier]

Hi,


On Thu, Dec 23, 2021, at 13:33, Vladimir Sitnikov wrote:
>>using maven toolchain feature
>
> Are toolchains really needed, especially, 1.6 and 1.7?
> I believe Java "target=1.4" + Java 1.8 would be good enough.
> If there are javadoc "warnings or errors", we could just suppress it.
> At the end of the day, making the build 100 times harder by requesting Java
> 1.6
> looks like an overkill.
>
> I think there's no way to install Java 1.6 on modern macOS.

Correct. I would suggest Docker, if there is a way to install it there.

Here is some more installation instructions:
https://github.com/apache/logging-log4j1/blob/trunk/INSTALL

For a complete build for a release, one needs to run tests using some DLLs 
which made it very hard back then.

Christian


>
> Vladimir

Re: Log4J 1.x progress, pull request(s), plans

[Christian Grobmeier]

On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
> One of the difficulties was likely related to building the Windows DLLs 
> for
> using the Windows Event Log Appender (
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html).
> I remember that being challenging. I can't recall if we signed the DLLs
> like we might do for Apache Commons Daemons Windows binaries. Another
> hurdle.

Correct, the DLL is even in the codebase.
https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll

If we would remove that Appender, it would be much easier to build, when I 
remember correctly. 
Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?

>
> FWIW, my opinion has been to NOT resurrect 1.x and put our energies into
> improving the 1.2 bridge and configuration file support we already have in
> 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
>
> No matter what, it needs to be a decision made carefully and not in haste.
>

+1

> Gary
>
> On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier 
> wrote:
>
>> Hello
>>
>> I have been the person cutting the 1.2.17 release and what I remember was
>> it was a super hard build. I had to install some VMs because there were
>> weird dependencies to this build. Building it fully will not be easy, but I
>> can also look into some mails whatever I found from that time.
>> Here is some build info.:
>> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
>> Some unit tests only run with a Windows VM
>>
>> It would be easier to remove some components, but BC is broken then.
>>
>> We told people in August 2015 this is EOL. I am honestly surprised that we
>> discuss a new release after 7 years. To my understanding the JMSAppender
>> issue is not as critical (just don't configure it). If a reconfiguration of
>> system is not on the cards, I wonder if upgrading from 1.2.17 to 1.2.18 is.
>>
>> That said i don't think we should resurrect it.
>>
>> If somebody really wants to work on, I also don't think we should go
>> through the incubator. We can do this using the normal processes and apply
>> patches, vote on new committers etc.
>>
>> My 2 cents.
>>
>> Christian
>>
>>
>> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote:
>> > Improving legacy compatibility is what I've been pushing. I agree with
>> > Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial can
>> of
>> > worms.
>> >
>> > Gary
>> >
>> > On Sun, Dec 19, 2021, 17:55 Matt Sicker  wrote:
>> >
>> >> The alternative is to polish the 1.x compatibility in 2.x which is both
>> >> actively maintained and much easier to get releases published. Then
>> users
>> >> on 1.x can more easily upgrade to 2.x. I can almost guarantee that
>> >> regardless of how many warnings we add to a potential 1.x release, we’ll
>> >> get inundated with CVE reports, bug reports, and email, all related
>> solely
>> >> to 1.x which none of us wish to maintain (especially given most of us
>> >> weren’t even involved in 1.x back when it was in development).
>> >> --
>> >> Matt Sicker
>> >>
>> >> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov <
>> >> sitnikov.vladi...@gmail.com> wrote:
>> >> >
>> >> > Matt>but at least one release using the normal ASF release
>> requirements
>> >> is
>> >> > required to graduate.
>> >> >
>> >> > Thanks for the reminder, and I am sure preparing the release won't be
>> an
>> >> > issue. I refactored release scripts for both Calcite and JMeter, and
>> I am
>> >> > sure log4j 1.x is doable.
>> >> >
>> >> >> compared to the alternatives discussed in this thread.
>> >> >
>> >> > I must be missing the alternarives.
>> >> > Can you please highlight them?
>> >> >
>> >> > There were multiple suggestions and various PRs from external
>> >> contributora,
>> >> > yet the committers respond with vaugue messages.
>> >> >
>> >> > The code must be buildable, so moving to Git, and adding GitHub CI is
>> the
>> >> > mandatory step.
>> >> > Of course, the existing PMC members and committers might have
>> opinions on
>> >> > the way to fix the issues, however I see no reasons for the team to
>> deny
>> >> > Git.
>> >> >
>> >> > The migration to Git consumes absolutely no resources from committers,
>> >> > except a couple of +1 votes.
>> >> >
>> >> > Unfortunately, even a trivial improvement like Git is ignored by
>> Logging
>> >> > PMC.
>> >> >
>> >> > So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x
>> >> > seriously.
>> >> >
>> >> > Vladimir
>> >>
>> >>
>>

Re: Log4J 1.x progress, pull request(s), plans

[Christian Grobmeier]

Hi

On Thu, Dec 23, 2021, at 14:51, Leo Simons wrote:
> Thanks for chipping in Christian! Your detailed notes from back then helped
> a ton figure basic things out.
>
> What I did for the PRs I made is to
>
> * also check in the 32 bit 1.2.17 dll from the binary release, like was
> already done for 64 bit,
> * have the maven build not auto-attempt to build it,
> * make its single unit test not even attempt to run except on windows,
> * add a matrix build that includes running on windows so that the
> windows-only test gets run frequently
> * did a little test on a windows machine with one of the DLLs
>
> Basically does for the 32 bit DLL what was already done for the 64 bit DLL.
>
> I think it’s good enough like that.
>
> Additional todo could be
> * add better INSTALL instructions for how to rebuild the dlls with ant

Definitely. It looked like a waste of time back then with 2.0 approaching.

Personally I have no access to a Windows machine. I cannot run the windows 
build part.

Apart from that, I am helping with the release of a 1.2.18, even if it hurts 
like hell

> * add another CI / GitHub action build that rebuilds the DLLs
>
> I think it is best to produce the DLLs on windows and the official release
> on linux, and to not attempt to have build orchestration to glue those
> together. It’s an exceptionally messy thing to rebuild from source without
> manual step, while the manual step is easy.

I think so. 

I didn't see the PRs though - are they still local on your box?

Kind regards,
Christian


>
> Cheers,
>
> Leo
>
>
> On Thu, 23 Dec 2021 at 14:34, Gary Gregory  wrote:
>
>> On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier 
>> wrote:
>>
>> >
>> > On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote:
>> > > One of the difficulties was likely related to building the Windows DLLs
>> > > for
>> > > using the Windows Event Log Appender (
>> > >
>> >
>> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html
>> > ).
>> > > I remember that being challenging. I can't recall if we signed the DLLs
>> > > like we might do for Apache Commons Daemons Windows binaries. Another
>> > > hurdle.
>> >
>> > Correct, the DLL is even in the codebase.
>> >
>> >
>> https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll
>> >
>> > If we would remove that Appender, it would be much easier to build, when
>> I
>> > remember correctly.
>> > Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK?
>> >
>>
>> Sadly, no. We cannot break binary compatibility, that would create a bigger
>> mess: Jar hell. Some folks would argue for breaking BC but that's a no-go
>> me.
>>
>> I feel like the projects I've worked on like Apache Commons and
>> HttpComponents have benefitted *massively* from providing binary
>> compatibility. Giving users drop-in replacements is a huge help.
>>
>> Recall that Apache officially *only releases source code*, and that source
>> code must be buildable, no matter how complex the instructions. Any
>> binaries are only provided as a convenience, that includes jar files and
>> DLLs.
>>
>> Gary
>>
>>
>> > >
>> > > FWIW, my opinion has been to NOT resurrect 1.x and put our energies
>> into
>> > > improving the 1.2 bridge and configuration file support we already have
>> > in
>> > > 2.x. That said, if we decides to move forward with 1.2.18, I'll help.
>> > >
>> > > No matter what, it needs to be a decision made carefully and not in
>> > haste.
>> > >
>> >
>> > +1
>> >
>> > > Gary
>> > >
>> > > On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier <
>> > grobme...@apache.org>
>> > > wrote:
>> > >
>> > >> Hello
>> > >>
>> > >> I have been the person cutting the 1.2.17 release and what I remember
>> > was
>> > >> it was a super hard build. I had to install some VMs because there
>> were
>> > >> weird dependencies to this build. Building it fully will not be easy,
>> > but I
>> > >> can also look into some mails whatever I found from that time.
>> > >> Here is some build info.:
>> > >> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL
>> > >> Some unit tests only run with a Windows VM
>> > >>
>

Re: Resurrecting log4j 1.x

[Christian Grobmeier]

Hello

On Thu, Dec 23, 2021, at 18:07, Vladimir Sitnikov wrote:
> Dominik> There are fixes for the flaws of log4j1 available: migrate to
> log4j2
>
> How does migration help me if I want to get 1.x fixed?
> log4j2 is a different product, created by a different team.
> Why should I migrate to log4j2 at all?

There is many reasons why we think log4j2 is better than log4j1 or forked 
products. To get the whole discussion, have a look at the mailing lists around 
2014 or something.

Different team - how does this affect the quality of a product? I remember the 
lengthy discussions about what is good and bad. I can tell that I feel that the 
original committers of log4j2 have spent many thoughts on how to improve 
things. 

Anyway, if you feel there is an urgent need to work on log4j1 then I think so 
be it. The ASF is meritocracy, when there are people around supporting code, 
this code can get released. Personally I don't see a reason to resurrect 
log4j1, but if you see a reason, go ahead.

> Dominik>Is there a concrete need for log4j1 to be patched
>
> 1. I request to get log4j 1.x patched. I can't show my code as it is under
> NDA, so you have to trust me here.

Trust with what exactly? Sorry if I missed something. 

> 2. Enrico Olivelli:
> https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4
> 3. 张铎(Duo Zhang):
> https://lists.apache.org/thread/j8dzoymo5z26sl08o3mvdf0353shcl2m
> 4. Andrew Purtell:
> https://lists.apache.org/thread/kv71f8vrqrhn6tlotqg76gz6khjs11vh

What I see here is basically the need to give better instructions on how to 
upgrade and improve the log4j1 bridge.
Why not working on that but going through the pain of an incubator again?
That said, I feel incubator is wrong, send in patches, become a committer here.

> Do you know migration to 2.x is not a drop-in replacement?
> It might require code or non-trivial configuration changes?
> For instance, if the application extends 1.x appenders, implements
> non-trivial re-configuration logic,
> then it can't upgrade to 2.x in a matter of days or weeks.

People had 7 years to do this. Any help for an upgrade from 1.x to 2.x is very 
welcome I think.

Anyway, despite I am not a big fan of resurrecting a buggy old software if you 
send in patches there are people who would apply them. If we feel there is 
community building around log4j1 we never had a problem with voting in new 
committers, pmc members etc.

You are welcome here, I am looking forward to patches and contributions to 
discuss.

Cheers
Christian

>
> Vladimir

Re: Resurrecting log4j 1.x

[Christian Grobmeier]

Hello Vladimir,

On Thu, Dec 23, 2021, at 20:58, Vladimir Sitnikov wrote:
> Christian>if you send in patches there are people who would apply them
>
> Thank you.
> Let us see what INFRA says regarding https://github.com/apache/log4j in
> https://issues.apache.org/jira/browse/INFRA-22654

This is not an infrastructure issue. As Chris (from Infra) explained, we, as a 
community, need to find consensus first.

In other words, we have to discuss all issues and problems and then make up a 
vote. Only PMC member votes are usually considered binding. Before we reach 
consensus, we should not create any issues - and extra work - for infra.

Here is some more information on how we develop software:
https://www.apache.org/theapacheway/index.html

kind regards,
Christian

>
> Vladimir

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Christian Grobmeier]

hi

at the moment I am -1 too, mostly for the reasons Gary mentioned.
Most important is that we don't have a clear goal on what we are trying to 
achieve here. We should be very explicit of why we are doing what.

Cheers,
Christian


On Thu, Dec 23, 2021, at 22:50, Gary Gregory wrote:
> -1
> We just created logging-log4j1 and converted the SVN repo into it, let's
> stick to that. I even made a commit ;-)
> I claim it is a good thing to start with a new repo because it creates a
> tiny bit of friction, for a project that is still End-of-Life after all.
> Even if it is a bit of friction to bring in old stuff from the old repo,
> this would provide a kind of effort/value filter.
> The concurrent consensus I see on the PMC is to fix the one listed CVE on
> our site plus other fixes in the style of the recent 2.x fixes.
> Bringing in all of the cruft from the old repo will give the wrong
> impression that we actually might be merging this or that random fix and
> feature. Which I claim is not the goal here.
>
> I feel we might need an addendum or a subsequent VOTE with a stated goal or
> charter for this repo to only provide CVE fixes (see above). Projects
> usually have a charter, not components I do not think, but I think we
> should have one here and put it in front and center in the README.md so we
> can manage expectations for people finding the repo on GitHub.
>
> Gary
>
> On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers 
> wrote:
>
>> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus has
>> recommended that we can divorce
>> the read-only SVN repo from https://github.com/apache/log4j. However, it
>> will not be able to keep the same
>> name as all Git repos owned by the logging project must start with
>> “logging-“.
>>
>> So this vote is to:
>> 1. Delete the apache/logging-log4j1 repo I created last night.
>> 2. Divorce the apache/log4j repo from SVN.
>> 3. Rename apache/log4j to apache/logging-log4j1.
>> 4. Create a branch named “main” from the v1_2_17 tag.
>> 5. Make main the default branch in GitHub.
>>
>> While all votes are welcome Infra needs consensus from the PMC on this
>> vote so the result will separate
>> binding from non-binding votes.
>>
>> Ralph
>>
>> PS - I’ve separated this from the previous vote thread since it was mostly
>> discussion. If you want to discuss
>> this please prefix the subject with [DISCUSS]

Re: Log4J 1.x progress, pull request(s), plans

[Christian Grobmeier]

On Thu, Dec 23, 2021, at 16:39, Leo Simons wrote:
> On Thu, 23 Dec 2021 at 15:43, Christian Grobmeier 
> wrote:
>
>> I didn't see the PRs though - are they still local on your box?
>
>
> On the wrong repo and lacking a target branch:
>
> https://github.com/apache/log4j/pull/17
> https://github.com/apache/log4j/pull/16
>
> From
> https://github.com/lsimons/log4j

Thanks for the pointer!

> For #17 I have it split across a couple branches in my forked repo, that
> could be their own PRs, but was waiting for feedback and a writeable repo.
>
> I am not near a laptop now so won’t contribute code until mid next week.
> Hope someone can pick up where I left off.

Don't worry, actually I am taking a few off days too. :-)

Kind regards,
Christian

>
> Cheers!
>
> Leo

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Christian Grobmeier]

Hi Vladimir,

On Fri, Dec 24, 2021, at 13:51, Vladimir Sitnikov wrote:
> Dominik,
>
> Are you willing to add committers and PMC members to the log4j 1.x
> community?

if we add people, then we add it to the logging project. There is no separate 
log4j/log4php whatever community. We are one community.

> If you forbid issues and pull requests, then it goes against the idea of
> adding new commuters and PMC members for 1.x.

That's why I think we should have voted on the goal first, and then discuss 
technical details.
At the moment I think the PMC is pretty much 1.x stays EOL at this point of 
time.

> How do you expect to nominate committers and PMC members if you
> forbid pull requests, forbid non-CVE changes, and so on?
>
> How do you expect to nominate committers and PMC members if you
> want to mention EOL all over the place?

It was already mentioned 2015. You can send patches, become a committer to ASF 
Logging and when everybody sees there is real interest and real developer 
capacity behind this idea, then maybe we as community decide to make a separate 
product.

Please use another email thread than the vote thread to discuss these things 
anyway, it makes it harder to count the votes.

Thank you.

Christian

> I would rather use "log4j 1.x is feature complete, so no new features are
> expected to appear"
> On the other hand, it should be perfectly fine to add new tests, fix
> security issues,
> fix other issues (e.g. NPEs).
>
> Vladimir

Re: Resurrecting log4j 1.x

[Christian Grobmeier]

Hi

On Fri, Dec 24, 2021, at 06:29, Vladimir Sitnikov wrote:
> Christian>Here is some more information on how we develop software:
>
> Christian, I'm a member of PMC in Apache JMeter and Apache Calcite, ok?

I was not aware of that, but the way you discussed looked like it was helpful 
to send that link.

> Could you please stop going in circles and just agree to open apache/log4j
> Git for writes?

No. We discuss, I listen to arguments and/or give mine and then we have a vote. 
A vote is already done and I can express my opinion as I wish too.

This is also not the tone of an email we send around to each other here.

> Are there another viable alternatives?

Yes.

> Note, that INFRA says they can easily reopen apache/log4j, and the only
> missing bit
> is exactly the one I asked 16 December.

if done wrong, we commit ourselves to maintain an EOL product and give wrong 
expectations. I want this PMC to be very sure about what we do and careful 
about how our actions look to the public.

I will not agree to anything just because you think it is right. We all need to 
think it is right. How can we know, you actually plan to work on it after we 
open it? Send in patches, we review, and then we can always make it up for 
writes and apply them. As an ASF fellow you know how this works.

Thanks,
Christian

>
> Vladimir

Re: [DISCUSS] The future of Log4j 1.x

[Christian Grobmeier]

On Fri, Dec 24, 2021, at 18:12, Carter Kozak wrote:
>> Sorry to be pedantic, but what Apache rules apply to the previous 
>> DISCUSS/VOTE thread?
>
> There's no need to apologize, the rules exist for a reason!
>
>> It should be telling, not ironic, that the last two contributors to Log4j 1 
>> that are still here voted -1
>
> This is a great point which I hadn't realized myself. For what it's 
> worth, I would consider _my_ vote with much less weight than those who 
> have actually contributed to and maintained the log4j-1 project.

There is no log4j1 or log4j2 community. There is only one ASF Logging 
community, which includes all committers from all the logging projects.

I have contributed to log4j1, but our votes weight the same. You are on the PMC 
because other PMC members trusted you, so do I. I trust you and believe your 
raise opinions to the best of the project.

We had this kind of discussion in our project history: "I had more commits, why 
doesn't it give me more weight in decisions". It almost killed this project 
years ago and led to many frustrations.

I hope I didn't sound like a teacher too much, but working here at that time 
made me very sensitive to this topic, so I had to write this.

Cheers!

>
> -ck
>
> On Fri, Dec 24, 2021, at 12:05, Gary Gregory wrote:
>> On Fri, Dec 24, 2021 at 11:47 AM Ralph Goers 
>> wrote:
>> 
>> > As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17
>> > was released on May 26, 2012. The last commit was to update the
>> > web site 7 years ago. The changes.xml file shows there were commits up to
>> > sometime in 2012, all of which were performed by Gary Gregory
>> > and Christian Grobmeier who ironically both voted no to opening the repo
>> > back up.
>> 
>> 
>> Note that the repo DISCUSS/VOTE thread seemed informal because it did
>> specify the rules for -1/+1: Is a -1 a VETO or does the VOTE follow RELEASE
>> rules? This is obviously not a RELEASE though. Sorry to be pedantic, but
>> what Apache rules apply to the previous DISCUSS/VOTE thread?
>> 
>> It should be telling, not ironic, that the last two contributors to Log4j 1
>> that are still here voted -1, but, if, big if, we (1) move fw the repo and
>> (2) then w a release... I'll opine ;-)
>> 
>> 
>> >
>> >
>> > The point of this history is to point out that the project essentially
>> > died in 2012. We simply acknowledged it in 2015.
>> >
>> > So now we have voted to open the repo. The question then becomes what to
>> > do next and going forward. I see several options:
>> >
>> 
>> What happens to the new repo Ralph created, will it just be deleted?
>> 
>> 
>> >
>> > 1. Create a README.md that publishes the projects EOL status and do
>> > nothing else.
>> >
>> Fine with me.
>> 
>> 
>> > 2. Create a README.md that says the project is EOL and no further big
>> > fixes or enhancements will be made but 1.2.18 was a special
>> > circumstance. Perform ONLY the following work for 1.2.18:
>> > a.  Make the build work with a modern version of Maven.
>> >
>> If we move fw w the repo, this seems like a no-brainer requirement IMO.
>> 
>> 
>> > b.  Fix the Java version bug.
>> >
>> Not sure what that one is, but If we move fw w the repo, OK.
>> 
>> c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
>> >
>> If we move fw w the repo, OK
>> 
>> 
>> > d.  Fix CVE-2019-17571
>> > The expectation is that the above would address the actual issues and
>> > not just remove classes.
>> >
>> If we move fw w the repo, OK.
>> 
>> 
>> > Do NOT perform a release of any kind.
>> >
>> 3. Option 2 but only perform a source release.
>> > 4. Option 2 but perform a full release.
>> >
>> Seems like the better solution b/w 3 and 4, a source only feels like a
>> tease if not worse.
>> 
>> 
>> > 5. Option 4 but allow development to continue, including bug fixes and
>> > enhancements.
>> >
>> -1 there. 1.x remains EOL. Focus on 1.2 bridge code in 2.x.
>> 
>> Thank you Ralph but putting this list together! :-)
>> Gary
>> 
>> 
>> >
>> > I personally can see valid reasons to do any of the above.  I have my own
>> > opinion on this but I will post that in a reply to this discussion kickoff.
>> >
>> > If you have other proposals feel free to state them.
>> >
>> > This discussion will be followed up by a vote thread if necessary.
>> >
>> > Ralph
>> >
>> >
>> >
>>

Re: [DISCUSS] The future of Log4j 1.x

[Christian Grobmeier]

Thank you very much Ralph for compiling this list.

On Fri, Dec 24, 2021, at 17:47, Ralph Goers wrote:
> 1. Create a README.md that publishes the projects EOL status and do 
> nothing else.
> 2. Create a README.md that says the project is EOL and no further big 
> fixes or enhancements will be made but 1.2.18 was a special 
> circumstance. Perform ONLY the following work for 1.2.18:
> a.  Make the build work with a modern version of Maven.
> b.  Fix the Java version bug.
> c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
> d.  Fix CVE-2019-17571
> The expectation is that the above would address the actual issues 
> and not just remove classes.
> Do NOT perform a release of any kind.
> 3. Option 2 but only perform a source release.
> 4. Option 2 but perform a full release.
> 5. Option 4 but allow development to continue, including bug fixes and 
> enhancements.

I am thinking option 1 is the best. We should improve log4j2 instead of wasting 
time to software which was last. updated in what, 2012?

However, I can see that there is some users who want to fix serious issues 
because they have reasons.

I would be fine with 2, if:

 - we clearly mark it EOL and tell this is a security patch for those who still 
couldn't upgrade
 - we promote to work on log4j2 bridge et al, if someone is willing to 
contribute, and helping writing migration guides
 - we allow all commits which makes the build easier and fixes (critical) 
issues. No more features which could lead to a version bump to 1.3, which is 
already taken by a failed attempt to upgrade

I am OK with option 4. The build is to complicated for anybody outside the 
developer list to make it happen. If we upgrade, we need to help users further.

Here is a new option.

Assuming we can make it a 1.2.18 and assuming we find out there is >=2 people 
willing to develop this further by ~mid 2022, we vote again if we continue this 
project. 

Only with a committed community we don't have to close it down again. Please 
take also in mind, that there is a competing logging project which developed 
the 1.2.x code base further. This will also add tensions.

Cheers
Christian 


>
> I personally can see valid reasons to do any of the above.  I have my 
> own opinion on this but I will post that in a reply to this discussion 
> kickoff.
>
> If you have other proposals feel free to state them.  
>
> This discussion will be followed up by a vote thread if necessary.
>
> Ralph

Re: [RESULT][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Christian Grobmeier]

On Fri, Dec 24, 2021, at 17:59, Vladimir Sitnikov wrote:
> AFAIK only PMC members have binding votes.
>
> AFAIK Carter Kozak, Robert Middleton, and Volkan Yazici are not PMC members
> of Logging as per
> https://people.apache.org/phonebook.html?project=logging
>
> So the updated summary is
>
> Binding +1 votes were received from Ralph Goers, Dominik Psenner, Matt
> Sicker, Ron Grabowski, and Remko Popma
> Binding -1 votes were received from Gary Gregory and Christian Grobmeier
> A non-binding +1 vote was received from Carter Kozak, Robert Middleton,
> Volkan Yazici, Vladimir Sitnikov

Last I recalled I was a PMC member of this group.
Probably check the link again you sent. 

Re: [DISCUSS] The future of Log4j 1.x

[Christian Grobmeier]

I am going to set up a vote for option 1 and 4. I think we have this thread 
open for a long time already and don't  expect many other responses

--
The Apache Software Foundation
V.P., Data Privacy

On Wed, Dec 29, 2021, at 07:55, Volkan Yazıcı wrote:
> Agreed with all points of Carter.
>
> It is either 1 or 4.
> Anything more than 4 (including 5) is a hard no from me.
>
> On Fri, Dec 24, 2021 at 6:00 PM Carter Kozak  wrote:
>
>> I would agree directionally with option 1 or option 4.
>>
>> Making changes without pushing binary artifacts to maven central (options
>> 2 and 3) is unlikely to do much good for the types of projects which still
>> use log4j1. Option 5 is a hard no from me, my time is already too
>> constrained, there are better options, and the architecture limits
>> substantive improvements.
>>
>> -ck
>>
>> On Fri, Dec 24, 2021, at 11:47, Ralph Goers wrote:
>> > As we all know Log4j 1.x reached end of life in August 2015. Log4j
>> 1.2.17 was released on May 26, 2012. The last commit was to update the
>> > web site 7 years ago. The changes.xml file shows there were commits up
>> to sometime in 2012, all of which were performed by Gary Gregory
>> > and Christian Grobmeier who ironically both voted no to opening the repo
>> back up.
>> >
>> > The point of this history is to point out that the project essentially
>> died in 2012. We simply acknowledged it in 2015.
>> >
>> > So now we have voted to open the repo. The question then becomes what to
>> do next and going forward. I see several options:
>> >
>> > 1. Create a README.md that publishes the projects EOL status and do
>> nothing else.
>> > 2. Create a README.md that says the project is EOL and no further big
>> fixes or enhancements will be made but 1.2.18 was a special
>> > circumstance. Perform ONLY the following work for 1.2.18:
>> > a.  Make the build work with a modern version of Maven.
>> > b.  Fix the Java version bug.
>> > c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
>> > d.  Fix CVE-2019-17571
>> > The expectation is that the above would address the actual issues
>> and not just remove classes.
>> > Do NOT perform a release of any kind.
>> > 3. Option 2 but only perform a source release.
>> > 4. Option 2 but perform a full release.
>> > 5. Option 4 but allow development to continue, including bug fixes and
>> enhancements.
>> >
>> > I personally can see valid reasons to do any of the above.  I have my
>> own opinion on this but I will post that in a reply to this discussion
>> kickoff.
>> >
>> > If you have other proposals feel free to state them.
>> >
>> > This discussion will be followed up by a vote thread if necessary.
>> >
>> > Ralph
>> >
>> >
>> >
>>

[VOTE] Future of Log4j 1.x

[Christian Grobmeier]

Hello, 

as discussed in another thread, this is a vote about the future of log4j 1. 
This vote stays open for the usual 72h.
Options are explained below.

You can vote for:

 [ ] +1, Option 1
 [ ] +1, Option 2
 [ ] +/- 0, abstain
 [ ] -1 object against those options

Option 1: Create a README.md that publishes the projects EOL status and do 
nothing else.
Option 2: Create a README which says the project is EOL but allow the following 
work for 1.2.18 AND create a full release:
a.  Make the build work with a modern version of Maven.
b.  Fix the Java version bug.
c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
d.  Fix CVE-2019-17571

Regards,
Christian
--
The Apache Software Foundation
V.P., Data Privacy

Re: [DISCUSS][VOTE] Future of Log4j 1.x

[Christian Grobmeier]

Makes sense. I will close thus vote not earlier than Jan 5, if there is no 
further objections. Thanks for  your input Tim

--
The Apache Software Foundation
V.P., Data Privacy

On Thu, Dec 30, 2021, at 01:56, Tim Perry wrote:
> I propose that this vote should stay open longer than 72 hours given 
> that we are coming up on New Years and many people who would wish to 
> weigh in might be on vacation right now. 
>
> Tim
>
>> On Dec 29, 2021, at 2:29 PM, Matt Sicker  wrote:
>> 
>> Consistent contributors are frequently invited to be committers and later 
>> PMC members. Having at least three people maintaining anything is an Apache 
>> standard for maintaining vendor neutrality, ensuring a minimum number of 
>> people can verify release candidates to address security issues or any other 
>> releases.
>> 
>> —
>> Matt Sicker
>> 
>>> On Dec 29, 2021, at 14:41, Vladimir Sitnikov  
>>> wrote:
>>> 
>>> 
 
 Log4j is owned by the Logging Services PMC. You cannot incubate it without
>>> this PMC’s approval.
>>> 
>>> Exactly. As far as I understand, Logging pmc should accept patches and
>>> release fixes or they should approve reincubating.
>>> Of course, you can try rejecting patches and disapprove reincubation,
>>> however, that won't hold water.
>>> 
>>> Unfortunately, I have not seen the response from the logging pmc regarding
>>> approve/disapprove re-incubating. There's a pending question to Ron still.
>>> 
>>> I do not consider forks outside of the ASF.
>>> 
 But I notice the one topic you did not respond to was the lack of
>>> interested people other than yourself. Why is that?
>>> 
>>> I find the question irrelevant, and I find it has nothing to do with
>>> accepting patches and releasing 1.2
>>> I belive there were even people on incubator thread, so it is strange why
>>> do you demand that I provide you with a list of rock-star 1.x maintainers.
>>> 
>>> 1) I can't guarantee I will be alive in February. Can you guarantee all the
>>> logging pmc members will be alive then? I doubt so. So I find that
>>> questions like "how can we be sure you will send patches" too intimate.
>>> 
>>> 2) I have already filed a patch for buildscripts. Whould you review it and
>>> merge?
>>> 
>>> 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support
>>> 1.2. What do you do then? Would you add all of them to the logging pmc?
>>> I don't really see the point why do you ask, and at the same time I can't
>>> guarantee the people I gather will be alive tomorrow. I can't guarantee
>>> they will always have interest in 1.2
>>> 
>>> Vladimir

Re: [DISCUSS][VOTE] Future of Log4j 1.x

[Christian Grobmeier]

If there is long term commitment apart from these urgent fixes we can run 
another vote.

You cannot guarantee you are alive by February, nobody can give such guarantees.

The logging pmc is not here to accept all patches as they come in but to make 
decisions best to the project (among other duties).

Once there is a mandate and consent among pmc we most likely try to review and 
comment on the prs coming in. No guarantees though your pr will be accepted as 
it is.

That said, we continue to vote in New committers and pmc members as we always 
have. Prerequisites to become logging committer is long term interest in 
logging and understanding the ASF way. Also, I daresay, many people here like 
to add new people when they are adding positive attitude (versus toxic 
behavior).

I hope all your questions are clarified now and we can continue to discuss (see 
Ralph's message) on slack and vote in this thread, which is, btw not meant for 
discussion but for voting.

--
The Apache Software Foundation
V.P., Data Privacy

On Wed, Dec 29, 2021, at 21:41, Vladimir Sitnikov wrote:
>>Log4j is owned by the Logging Services PMC. You cannot incubate it without
> this PMC’s approval.
>
> Exactly. As far as I understand, Logging pmc should accept patches and
> release fixes or they should approve reincubating.
> Of course, you can try rejecting patches and disapprove reincubation,
> however, that won't hold water.
>
> Unfortunately, I have not seen the response from the logging pmc regarding
> approve/disapprove re-incubating. There's a pending question to Ron still.
>
> I do not consider forks outside of the ASF.
>
>>But I notice the one topic you did not respond to was the lack of
> interested people other than yourself. Why is that?
>
> I find the question irrelevant, and I find it has nothing to do with
> accepting patches and releasing 1.2
> I belive there were even people on incubator thread, so it is strange why
> do you demand that I provide you with a list of rock-star 1.x maintainers.
>
> 1) I can't guarantee I will be alive in February. Can you guarantee all the
> logging pmc members will be alive then? I doubt so. So I find that
> questions like "how can we be sure you will send patches" too intimate.
>
> 2) I have already filed a patch for buildscripts. Whould you review it and
> merge?
>
> 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support
> 1.2. What do you do then? Would you add all of them to the logging pmc?
> I don't really see the point why do you ask, and at the same time I can't
> guarantee the people I gather will be alive tomorrow. I can't guarantee
> they will always have interest in 1.2
>
> Vladimir

Re: [DISCUSS] Starting social media accounts for subprojects

[Christian Grobmeier]

I think thats long overdue and recall we had a component Twitter account for 
log4php.
Later today I will check if I can find the passwords.
The component is dormant, but its worth having access shared with the PMC still

https://twitter.com/log4php/


--
The Apache Software Foundation
V.P., Data Privacy

On Thu, Dec 30, 2021, at 23:39, Matt Sicker wrote:
> We recently had an idea discussed on a video call about potentially 
> starting some Twitter et al. accounts for announcing releases, release 
> candidates, and larger upcoming changes to subprojects (e.g., changing 
> the minimum major version of the underlying programming language or 
> build tooling, major version releases like 2.x -> 3.x, etc). While the 
> dev list remains our official place to discuss development, it would be 
> immensely useful for communicating with our wider user base about 
> changes that may be more relevant to them than to active developers and 
> contributors.
>
> What do you all think? If we do make accounts, would it make sense to 
> divide them into accounts like @log4j, @log4net, @log4cxx, etc., or 
> should they be created like a common account for the whole Logging PMC? 
> And which social media sites would be best to use here? Twitter is an 
> obvious choice, but there could also be other tech-heavy social media 
> sites that would also benefit.
> --
> Matt Sicker

Re: [VOTE] Future of Log4j 1.x

[Christian Grobmeier]

On Sat, Jan 1, 2022, at 18:19, Jochen Wiedmann wrote:
> On Sat, Jan 1, 2022 at 4:40 PM Xeno Amess  wrote:
>
>> >  People should migrate to log4j2.
>> good thinking, but what if they migrate to logback...
>
> No, it's not (good thinking, that is).
>
> Log4j1 is a part of basically *every* Java based server software, that
> I am aware of. People don't want to touch those. They need a drop-in
> replacement, not a successor. Over the last week, I was *really
> puzzled* about all the stuff that claims to be affected by the
> problems in log4j2. And that's the lesser used of the two...

For what exactly do we need that now? The security issues in log4j1 are 10 
years old and you just don't have to use JMSAppender and you are good too go.

Cheers,
Christian

> Jochen
>
>
>
> Philosophy is useless, theology is worse. (Industrial Desease, Dire Straits)

Re: [VOTE] CVE creation process

[Christian Grobmeier]

+1, as this only affects the creation of cves but does not block the fixing 
going on immediately.
I think we do not require majority though, just waiting if someone objects is 
fine for me

On Mon, Jan 3, 2022, at 12:59, Volkan Yazıcı wrote:
> Hello,
>
> As discussed earlier[1], this is a vote to introduce the process that
> enforces CVE submissions and their content should be first subject to
> voting using the (private) `secur...@logging.apache.org` mailing list.
>
> [] +1, accept the process
> [] -1, object to the process because...
>
> The vote will remain open for 72 hours (or more if required). All
> votes are welcome and we encourage everyone to participate, but only
> Logging PMC votes are “officially” counted. As always, at least 3 +1
> votes and more positive than negative votes are required.
>
> Kind regards.
>
> [1] https://lists.apache.org/thread/qd7mr5pt9kby3lkz4j49304tkqgm9yhl

Re: [DISCUSS][VOTE] Future of Log4j 1.x

[Christian Grobmeier]

Hi Leo,

good new year to you!

On Sun, Jan 2, 2022, at 07:12, Leo Simons wrote:
> Hey,
>
> Happy new year everyone!
>
> On Wed, Dec 29, 2021 at 8:54 PM Ralph Goers 
> wrote:
>
>> Leo seemed interested at first but didn’t weigh in on the discussion
>> thread.
>
>
> I'm here. I did mention in a couple mails I'd be away. Real life happens :).
>
> I think I made clear what I am interested in through several emails and in
> code.
> I've also pointed out what I wouldn't do (like step up as a maintainer on a
> permanent basis, or incubate something).

I think you are very welcome at this place and no matter the outcome of this 
vote, let us discuss how you can still find an open source home here. I know 
you have a different opinion, but learning more about Log4j1 I think a person 
with your skills and dedication is more than welcome in working with log4j 1 
migration.

cheers!

> I think all the relevant arguments on how to proceed with 1.x have been
> made (a few times...).
> I don't have anything new to add.
> I'll accept the vote outcome.
>
>
> Cheers!
>
>
> Leo

Re: [VOTE] Future of Log4j 1.x

[Christian Grobmeier]

+1, Option 1


On Wed, Dec 29, 2021, at 20:33, Christian Grobmeier wrote:
> Hello, 
>
> as discussed in another thread, this is a vote about the future of 
> log4j 1. This vote stays open for the usual 72h.
> Options are explained below.
>
> You can vote for:
>
>  [ ] +1, Option 1
>  [ ] +1, Option 2
>  [ ] +/- 0, abstain
>  [ ] -1 object against those options
>
> Option 1: Create a README.md that publishes the projects EOL status and 
> do nothing else.
> Option 2: Create a README which says the project is EOL but allow the 
> following work for 1.2.18 AND create a full release:
> a.  Make the build work with a modern version of Maven.
> b.  Fix the Java version bug.
> c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
> d.  Fix CVE-2019-17571
>
> Regards,
> Christian
> --
> The Apache Software Foundation
> V.P., Data Privacy

[RESULT][VOTE] Future of Log4j 1.x

[Christian Grobmeier]

Hello,
this is the result of the below vote:

11x +1 (Option 1), all binding
1 x +0 (abstaing), non binding
1x -1 (objection against those options), non binding.

Details:

+1, Option 1
Dominik Psenner (binding)
Robert Middleton (binding)
Gary Gregory (binding)
Ralph Goers (binding)
Matt Sicker (binding)
Christian Grobmeier (binding)
Carter Kozak (binding)
Ron Grabowski (binding)
Volkan Yazıcı (binding)
Remko Popma (binding)
Davyd McColl (binding)

+0:
Xeno Amess (non binding)

-1:
Vladimir Sitnikov (non binding)

The PMC decided unanimous to keep Log4 1 EOL.

Since there was a lengthy discussion before and while this, the PMC Chair Ron 
Grabowski will send a statement which explains the thoughts behind this 
decision in detail.

Kind regards,
Christian



Hello, 

as discussed in another thread, this is a vote about the future of log4j 1. 
This vote stays open for the usual 72h.
Options are explained below.

You can vote for:

 [ ] +1, Option 1
 [ ] +1, Option 2
 [ ] +/- 0, abstain
 [ ] -1 object against those options

Option 1: Create a README.md that publishes the projects EOL status and do 
nothing else.
Option 2: Create a README which says the project is EOL but allow the following 
work for 1.2.18 AND create a full release:
a.  Make the build work with a modern version of Maven.
b.  Fix the Java version bug.
c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
d.  Fix CVE-2019-17571

Regards,
Christian
--
The Apache Software Foundation
V.P., Data Privacy

Re: [ANNOUNCE] Log4j 1 End-of-Life Statement

[Christian Grobmeier]

Hello Ceki

On Thu, Jan 6, 2022, at 11:00, Ceki Gülcü wrote:
> The fact that the decision was unanimous on such a delicate matter is 
> quite surprising and very interesting in itself with respect to group 
> dynamics.

You haven't been at the meeting. That's why you don't know anything about this 
group or its "dynamics".

> Coming back to the issue at hand, the notion that log4j 2.x offers a 
> natural migration path from log4j 1.x is rather doubtful.

Why is that? 

There is docs and we haven't received many problems with the migration so far. 
I made such migrations several times myself. I found them pretty straight 
forward.

> As for the various log4j 1.x bugs, log4j 2.x also has numerous bugs and 
> some of the design choices in 2.x are very much debatable.

Log4j 2 is not what we discussed. If you want to discuss log 4j 2, make your 
suggestions in another thread on the dev list.

> More practically speaking, I think it is important to fix the critical 
> issues in log4j 1.x. The effort involved is reasonable and is likely to 
> help a lot of people.

Which ones? The JMSAppender issue or the SockerServer issue? Both have been 
there >2012.  What is suddenly so critical it requires re-releasing EOL 
software? Or did you mean the multithreading issues?

However, if you want to see that fixed, you can help. 

You are still a committer to ASF logging and member to this foundation.

If you like, you can mentor the two potential contributors, review and apply 
the patches. You could also craft the 1.2.18 release and put it up for a vote.

Have a happy new year too!

Kind regards,
Christian



> Best regards and a happy new year.
>
> -- 
> Ceki Gülcü
>
> Please contact suppport(at)qos.ch for donations, sponsorship or support 
> contracts related to SLF4J or logback projects.
>
>
>
> On 06/01/2022 01:23, Ron Grabowski wrote:
>> Dear Log4j community,
>> 
>> While working on the December 2021 Apache Log4j 2 releases the Apache
>> Logging Services PMC received requests to reevaluate the 2015
>> End-of-Life (EOL) decision for Apache Log4j 1, which has seen its
>> latest release in 2012.
>> 
>> We have considered these requests and discussed various options.
>> Ultimately we came to the unanimous decision that the only sustainable
>> approach is to continue to focus on Log4j 2. The PMC hereby reconfirms
>> the 2015 EOL announcement of Log4j 1, meaning no resources will be
>> invested into the Log4j 1 codebase. We encourage users to update to
>> recent versions of Log4j 2. We welcome every effort to contribute to
>> the Log4j community. Please use the developer mailing lists to get in
>> touch: https://logging.apache.org/log4j/2.x/mail-lists.html
>> 
>> The Log4j 1 source code will continue to be publicly available but
>> Pull Requests will be closed as "Won't Fix". The Apache License allows
>> for code forks that respect Apache Software Foundation Trademarks.
>> 
>> Here are some of the reasons we believe this is the right choice for
>> the Log4j project:
>> 
>> * Log4j 2 supports migration from Log4j 1
>> 
>> We've made improvements to
>> https://logging.apache.org/log4j/2.x/manual/migration.html to better
>> explain the process. Many users are not aware that Log4j 2 now
>> supports Log4j 1 configuration files, since this feature is relatively
>> new. We believe most applications using Log4j 1 can now simply replace
>> the Log4j 1.x jar with Log4j 2 jars and be able to run. Users are
>> encouraged to contact us through the project mailing lists
>> (https://logging.apache.org/log4j/2.x/mail-lists.html) if there are
>> additional areas for improvement.
>> 
>> * Log4j 1 deadlock and multithreading design limitations
>> 
>> The decision to relaunch the Log4j project as Log4j 2 meant we had an
>> opportunity to correct long standing design deficiencies. One of these
>> fundamental design deficiencies has to do with how to handle
>> multithreading within the library. The following mailing list question
>> is but one example of known multithreading issues with Log4j 1:
>> https://lists.apache.org/thread/7yqrmzqgzpxmbcc7skl0vr8z33fk4hd4
>> 
>> * High-complexity Log4j 1 bugs
>> 
>> In addition to the items listed, many other issues can be found in
>> Bugzilla: https://bz.apache.org/bugzilla
>> 
>> 50213: Category callAppenders synchronization causes
>> java.lang.Thread.State: BLOCKED
>> 46878: Deadlock in 1.2.15 caused by AsyncAppender and
>> ThrowableInformation classes
>> 41214: Deadlock with RollingFileAppender
>> 44700: Log4J locks rolled log files (files can’t be deleted)
>> 49481: Log4j stops writing to file, and then causes server to lockup
>> 50323: Vulnerability in NTEventLogAppender
>> 50463: AsyncAppender causing deadlock when dispatcher thread dies
>> 50858: Classloader leak when using Log4j in a webapp container such as
>> Tomcat, WebLogic
>> 52141: [STUCK] ExecuteThread...Blocked trying to get lock:
>> org/apache/log4j/Logger@0xc501e0a8[fat lock]
>> 54009: Thread is getting Blocked
>> 54325: Concurrency i

Re: [ANNOUNCE] Log4j 1 End-of-Life Statement

[Christian Grobmeier]

Hi

On Thu, Jan 6, 2022, at 15:05, Ceki Gülcü wrote:
> On 06/01/2022 14:42, Christian Grobmeier wrote:
>> Which ones? The JMSAppender issue or the SockerServer issue? Both have been 
>> there >2012.  What is suddenly so critical it requires re-releasing EOL 
>> software? Or did you mean the multithreading issues?
>
> Certain things have changed during the month of December 2021. The 
> answer to your question regarding urgency of the JMS and 
> SocketAppender** follows from there.

What changed in December 2021 for log4j1? 

>> If you like, you can mentor the two potential contributors, review and apply 
>> the patches. You could also craft the 1.2.18 release and put it up for a 
>> vote.
>
> I don't understand. The PMC just voted to disallow 1.2.18 release for 
> other ASF committers. Have you not?

I have voted for not working on 1.2.18 for the mentioned reasons; I see Ralph 
answered this already, I have nothing to add. I also see you already wrote a 
first message, so I think this is clarified.

Cheers,
Christian


>
> -- 
> Ceki Gülcü

Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)

[Christian Grobmeier]

Hello,

On Fri, Jan 7, 2022, at 08:21, Ceki Gülcü wrote:
> As for infringing on the log4j trademark, I will rename the repo to 
> something else, for example "re4j".
>
> As mentioned in my previous message, if the ASF decides to integrate 
> "re4j" as log4j 1.x, the door is open.

Thanks. You did not respond to my earlier question why this is so urgent after 
10 years,
but I guess we see what you are trying to do on the fork.

If we feel this is valuable, we may vote again. Thanks for keeping that door 
open. I think working on a fork is the best way at this point of time.

Good luck.

Kind regards,
Christian


>
> -- 
> Ceki Gülcü
>
>> —
>> Matt Sicker
>> 
>>> On Jan 6, 2022, at 18:18, Ceki Gülcü  wrote:
>>>
>>> 
>>>
>>> Hello all,
>>>
>>> Given the recent refusal to even consider work on a 1.2.18 branch, which 
>>> would have been subject to PMC vote before release anyway, I have created a 
>>>  separate repository on github under the name "relog4j1". The intent of 
>>> relog4j1 is to fix existing critical issues in log4j 1.x.
>>>
>>> If one day the logging PMC changes its mind and decides to integrate 
>>> "relog4j1" as log4j 1.x, the door is open.
>>>
>>> Those interested to contribute, please contact me directly.
>>>
>>> Good luck and thanks for the fish.
>>> -- 
>>> Ceki Gülcü
>>>

Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)

[Christian Grobmeier]

On Sat, Jan 8, 2022, at 05:11, Julius Davies wrote:
> One person's EOL is another person's open source business model !   (RHEL
> subscriptions are not cheap!)

I doubt anybody would actually pay for log4j. 

>
> Anyway, quick FYI - I noticed Atlassian has rev'd log4j-1.2.17 fifteen
> times !   Might be some good patches in there.  They do publish the
> "sources.jar":
> https://packages.atlassian.com/3rdparty/log4j/log4j/1.2.17-atlassian-15/

Didn’t look at the code, but I wonder why and what they did in those revs.
I got my customers to upgrade and still think this is what should be done. V1 
has so many problems I am still confused people just don’t upgrade but stay 
with eol software. 


>
>
> yours,
>
> Julius
>
>
>
>
> On Fri, Jan 7, 2022 at 11:59 AM Dominik Psenner  wrote:
>
>> End-Of-Life means End-Of-Life and that is the end of the story.
>>
>> If someone keeps patching an End-Of-Life component, how should downstream
>> understand when they should update their product?
>>
>> The answer to this question is the technical definition of End-Of-Life.
>>
>> Upgrade, migrate, rewrite, throw away, whatever, .. log4j1 builds on top of
>> End-Of-Life stuff like java 1.4 and has been dead for a decade.
>>
>> Stop living in the past, the future is now!
>> --
>> Sent from my phone. Typos are a kind gift to anyone who happens to find
>> them.
>>
>> On Fri, Jan 7, 2022, 19:38 Matt Sicker  wrote:
>>
>> > https://github.com/albfernandez/log4j/ is one fork I found that
>> > published a fixed copy on Maven Central. Confluent also publishes a
>> > forked copy, though I don't know where their source code is (package
>> > names are renamed as it's mainly used by old versions of Confluent's
>> > hosted services, so it's possible that the source code isn't
>> > published).
>> >
>> > One of the key missing pieces I've seen in other forks so far is that
>> > they simply ripped a lot of affected code out of the library entirely
>> > which is sure to cause compatibility issues when attempted to be used
>> > as a drop-in replacement. At least the patched versions in RHEL and
>> > Debian are mainly used by other RHEL or Debian packages, so they
>> > already have their own compatibility policies. While I'd imagine Ceki
>> > is one of the only people in the world who could figure out how to
>> > update the old build, it'd also be great to respond to relevant
>> > threads about this while they're active rather than waiting until
>> > after the bell rings. As Christian said, if the work is done outside
>> > the ASF to get a full release working for 1.2.x, then I think we'd be
>> > more receptive to accepting it back and making a release, especially
>> > if there is continued community interest in it. Otherwise, I still
>> > believe it's more useful to patch up the existing v2/v1 compatibility
>> > system so that users can drop in v2 to upgrade things much more
>> > easily, especially given the intractability of many concurrency issues
>> > in v1 that are fairly unacceptable in modern Java applications.
>> >
>> > On Fri, Jan 7, 2022 at 12:18 PM Andrew Marlow 
>> > wrote:
>> > >
>> > > my comment is below:
>> > >
>> > > On Fri, 7 Jan 2022 at 14:23, Christian Grobmeier > >
>> > > wrote:
>> > >
>> > > > Hello,
>> > > >
>> > > > On Fri, Jan 7, 2022, at 08:21, Ceki Gülcü wrote:
>> > > > > As for infringing on the log4j trademark, I will rename the repo to
>> > > > > something else, for example "re4j".
>> > > > >
>> > > > > As mentioned in my previous message, if the ASF decides to
>> integrate
>> > > > > "re4j" as log4j 1.x, the door is open.
>> > > >
>> > > > Thanks. You did not respond to my earlier question why this is so
>> > urgent
>> > > > after 10 years,
>> > > > but I guess we see what you are trying to do on the fork.
>> > > >
>> > > > If we feel this is valuable, we may vote again. Thanks for keeping
>> that
>> > > > door open. I think working on a fork is the best way at this point of
>> > time.
>> > > >
>> > >
>> > > I want to add my thanks to Ceki as well. I would like to see log4j-v1
>> get
>> > > one fix in version 1.2.18 which RedHat have already made for RHEL7.
>> It's
>> > > the one for the SocketServer issue. The source for this fix is out
>> there
>> > > somewhere. I did track it down some time ago but I 've forgotten where
>> I
>> > > found it. Maybe Matt knows where it is, then it could be applied to
>> this
>> > > fork.
>> > >
>> > >
>> > > > Good luck.
>> > > >
>> > > > Kind regards,
>> > > > Christian
>> > > >
>> >
>>

[log4j] Performance comparsion

[Christian Grobmeier]

Hi,

found this:
https://www.sitepoint.com/which-java-logging-framework-has-the-best-performance/?utm_content=buffer79511&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

Re: [log4j] Performance comparsion

[Christian Grobmeier]

and what I wanted to write before hitting "send" to early: I think
Stephen is right with saying we need to improve the docs. Log4j1 docs
were bad, 2 is much better, but I think we can do much, much better.

On Thu, Apr 13, 2017, at 20:38, Christian Grobmeier wrote:
> Hi,
> 
> found this:
> https://www.sitepoint.com/which-java-logging-framework-has-the-best-performance/?utm_content=buffer79511&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

Re: [log4j] Performance comparsion

[Christian Grobmeier]

Usually Disqus comments are moderated. But actually I thought it's
moderated from the Sitepoint team, not the author. But who knows...

On Fri, Apr 14, 2017, at 18:32, Remko Popma wrote:
> Moderated?
> I noticed that the author enjoys taking strong positions on things but at
> the same time finds it inconceivable that he could be wrong.
> 
> On Sat, Apr 15, 2017 at 1:00 AM, Ralph Goers 
> wrote:
> 
> > I’m not sure why my comment has not appeared…
> >
> > Ralph
> >
> > > On Apr 13, 2017, at 1:48 PM, Ralph Goers 
> > wrote:
> > >
> > > I posted a comment on the post as I think he missed a couple of things.
> > >
> > > Ralph
> > >
> > >> On Apr 13, 2017, at 11:38 AM, Christian Grobmeier 
> > wrote:
> > >>
> > >> Hi,
> > >>
> > >> found this:
> > >> https://www.sitepoint.com/which-java-logging-framework-
> > has-the-best-performance/?utm_content=buffer79511&utm_
> > medium=social&utm_source=twitter.com&utm_campaign=buffer
> > >>
> > >
> > >
> > >
> >
> >
> >

Re: [log4j] Performance comparsion

[Christian Grobmeier]

On Thu, Apr 13, 2017, at 22:47, Ralph Goers wrote:
> You have commit rights…. ;-)

hehe :-)
And I actually feel the Open Source itch! Hopefully I can make some
proposal!


> Ralph
> 
> > On Apr 13, 2017, at 11:41 AM, Christian Grobmeier  
> > wrote:
> > 
> > and what I wanted to write before hitting "send" to early: I think
> > Stephen is right with saying we need to improve the docs. Log4j1 docs
> > were bad, 2 is much better, but I think we can do much, much better.
> > 
> > On Thu, Apr 13, 2017, at 20:38, Christian Grobmeier wrote:
> >> Hi,
> >> 
> >> found this:
> >> https://www.sitepoint.com/which-java-logging-framework-has-the-best-performance/?utm_content=buffer79511&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
> > 
> 
>

Re: Feedback request

[Christian Grobmeier]

I agree with Matt.

What I love is the way you use annotations. I can't tell you how I miss
annotations when I work with PHP. 


On Sat, Apr 15, 2017, at 17:47, Matt Sicker wrote:
> It looks pretty neat! The single source code file idea is an amusing
> C-like
> distribution mechanism, but it makes sense for this style of library. I'm
> curious how you're making the docs as I've seen that format a lot and
> think
> it could possibly be useful for log4j-core or one of the other
> subprojects
> at least.
> 
> As for concrete use of this, being a single file, it could easily be
> shaded
> into log4j-core for the CLI classes. Very nice!
> 
> On 15 April 2017 at 09:25, Remko Popma  wrote:
> 
> > Everyone, I would love your feedback on this:
> >
> > https://remkop.github.io/picocli/
> > https://github.com/remkop/picocli
> >
> > It is heavily inspired by JCommander and Args4j but has improved
> > ergonomics, customizable help (with colors) and various other improvements.
> >
> > I hope this will be useful in the log4j-tools module, but any kind of
> > feedback would be great.
> >
> > Remko
> >
> 
> 
> 
> -- 
> Matt Sicker 

Re: [LAZY][VOTE] Release Logging parent pom version 8

[Christian Grobmeier]

+1 

(first release vote in ages :-))

On Thu, Mar 2, 2023, at 22:10, Piotr P. Karwasz wrote:
> This is a lazy vote to release logging-parent 8. This vote is open for
> 72 hours and will pass unless getting a net negative vote count.
>
> Release notes:
>
> * The version of 'org.apache:apache' has been bumped to 29.
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachelogging-1099
>
> POM file:
> https://repository.apache.org/content/repositories/orgapachelogging-1099/org/apache/logging/logging-parent/8/logging-parent-8.pom
>
> All relevant files:
> - 
> https://repository.apache.org/content/repositories/orgapachelogging-1099/org/apache/logging/logging-parent/8/logging-parent-8-source-release.zip
> - 
> https://repository.apache.org/content/repositories/orgapachelogging-1099/org/apache/logging/logging-parent/8/logging-parent-8-source-release.zip.asc
> - 
> https://repository.apache.org/content/repositories/orgapachelogging-1099/org/apache/logging/logging-parent/8/logging-parent-8-source-release.zip.sha512
> - 
> https://repository.apache.org/content/repositories/orgapachelogging-1099/org/apache/logging/logging-parent/8/logging-parent-8.pom
> - 
> https://repository.apache.org/content/repositories/orgapachelogging-1099/org/apache/logging/logging-parent/8/logging-parent-8.pom.asc
>
> Git URL:
> https://gitbox.apache.org/repos/asf/logging-parent.git
>
> Tag:
> logging-parent-8
>
> Keys file:
> https://downloads.apache.org/logging/KEYS
>
> Release signed with keyid 04B44C056663906446B77A6D89F11DC191AA7042
>
> Piotr

Re: [External] Re: Log4j Issue

[Christian Grobmeier]

Hello Gurumoorthi,

Piotr already responded to your email:

> MapLookup#newMap changed from private (as in 2.2) to package (as in
> 2.17.1) in the course of history. Your Tomcat is picking up the
> private one, which means that log4j-core-2.2.jar is still on the
> classpath.
> Double check that the old Log4j2 version are no longer there and
> restart Tomcat to be sure.
>
> Piotr

If this information does not help you, respond to dev@logging.apache.org as 
Dominik told you.

Kind regards,
Christian


--
The Apache Software Foundation
V.P., Data Privacy

On Mon, Mar 20, 2023, at 17:27, Gurumoorthi Vijayalingam wrote:
> Hi Team,
>
> Can you please help us to fix this issue.
>
> Regards,
> Guru.
>
> From: Dominik Psenner 
> Sent: 04 March 2023 02:16
> To: secur...@logging.apache.org
> Cc: Paolo Gil Ostrea ; Roark Hamilton 
> ; Gurumoorthi Vijayalingam 
> 
> Subject: [External] Re: Log4j Issue
>
> CAUTION: This message was sent from outside of the company. Please do 
> not click links or open attachments unless you recognize the source of 
> this email and know the content is safe.
>
> Hi
>
> I'm CCing the original author of the message. Please read below. 
> Further please consider posting to the proper mailing list. The request 
> is not about a security issue and probably should have been posted to 
> dev@logging.apache.org after subscribing 
> to that mailing list.
>
> Warm regards
> Dominik
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find them.
>
> On Fri, Mar 3, 2023, 21:17 Piotr P. Karwasz 
> mailto:piotr.karw...@gmail.com>> wrote:
> Gurumoorthi,
>
> On Fri, 3 Mar 2023 at 19:04, Gurumoorthi Vijayalingam
> mailto:gvijayalin...@simeio.com>> wrote:
>> Just attached the error message and log4j configuration for your reference.
>
> MapLookup#newMap changed from private (as in 2.2) to package (as in
> 2.17.1) in the course of history. Your Tomcat is picking up the
> private one, which means that log4j-core-2.2.jar is still on the
> classpath.
> Double check that the old Log4j2 version are no longer there and
> restart Tomcat to be sure.
>
> Piotr

Re: [External] Re: Log4j Issue

[Christian Grobmeier]

Hello Gurumoorthi,

please subscribe to dev@logging.apache.org by sending an empty message to 
dev-subscr...@logging.apache.org.
It is hard for our message moderators to manually moderate your messages 
through.

You need to find the log4j version of Tomcat. Please search for this. it could 
be in the lib folder of Tomcat.

You can also search the whole installation of Tomcat for "log4j" or 
"log4j-core-2.2.jar", then you should find it.

Kind regards,
Christian


--
The Apache Software Foundation
V.P., Data Privacy

On Fri, Apr 21, 2023, at 12:51, Gurumoorthi Vijayalingam wrote:
> Any help on this request ? we stuck. 
>
> -Original Message-
> From: Gurumoorthi Vijayalingam 
> Sent: Thursday, April 13, 2023 7:36 AM
> To: Christian Grobmeier ; dev@logging.apache.org
> Subject: RE: [External] Re: Log4j Issue
>
> Hi Team,
>
> We tried the steps as Christian mentioned in below email, but still 
> getting same error. Please help us to fix this issue 
>
> Thanks,
> Guru.
>
> -Original Message-
> From: Christian Grobmeier 
> Sent: Tuesday, March 21, 2023 2:17 AM
> To: Gurumoorthi Vijayalingam ; 
> dev@logging.apache.org
> Cc: Paolo Gil Ostrea ; Roark Hamilton 
> ; Bhavana Pujari ; Sireesha 
> Kutala 
> Subject: Re: [External] Re: Log4j Issue
>
> CAUTION: This message was sent from outside of the company. Please do 
> not click links or open attachments unless you recognize the source of 
> this email and know the content is safe.
>
>
> Hello Gurumoorthi,
>
> Piotr already responded to your email:
>
>> MapLookup#newMap changed from private (as in 2.2) to package (as in
>> 2.17.1) in the course of history. Your Tomcat is picking up the 
>> private one, which means that log4j-core-2.2.jar is still on the 
>> classpath.
>> Double check that the old Log4j2 version are no longer there and 
>> restart Tomcat to be sure.
>>
>> Piotr
>
> If this information does not help you, respond to 
> dev@logging.apache.org as Dominik told you.
>
> Kind regards,
> Christian
>
>
> --
> The Apache Software Foundation
> V.P., Data Privacy
>
> On Mon, Mar 20, 2023, at 17:27, Gurumoorthi Vijayalingam wrote:
>> Hi Team,
>>
>> Can you please help us to fix this issue.
>>
>> Regards,
>> Guru.
>>
>> From: Dominik Psenner 
>> Sent: 04 March 2023 02:16
>> To: secur...@logging.apache.org
>> Cc: Paolo Gil Ostrea ; Roark Hamilton 
>> ; Gurumoorthi Vijayalingam 
>> 
>> Subject: [External] Re: Log4j Issue
>>
>> CAUTION: This message was sent from outside of the company. Please do 
>> not click links or open attachments unless you recognize the source of 
>> this email and know the content is safe.
>>
>> Hi
>>
>> I'm CCing the original author of the message. Please read below.
>> Further please consider posting to the proper mailing list. The 
>> request is not about a security issue and probably should have been 
>> posted to dev@logging.apache.org<mailto:dev@logging.apache.org> after 
>> subscribing to that mailing list.
>>
>> Warm regards
>> Dominik
>> --
>> Sent from my phone. Typos are a kind gift to anyone who happens to find them.
>>
>> On Fri, Mar 3, 2023, 21:17 Piotr P. Karwasz 
>> mailto:piotr.karw...@gmail.com>> wrote:
>> Gurumoorthi,
>>
>> On Fri, 3 Mar 2023 at 19:04, Gurumoorthi Vijayalingam 
>> mailto:gvijayalin...@simeio.com>> wrote:
>>> Just attached the error message and log4j configuration for your reference.
>>
>> MapLookup#newMap changed from private (as in 2.2) to package (as in
>> 2.17.1) in the course of history. Your Tomcat is picking up the 
>> private one, which means that log4j-core-2.2.jar is still on the 
>> classpath.
>> Double check that the old Log4j2 version are no longer there and 
>> restart Tomcat to be sure.
>>
>> Piotr

Re: [External] Re: Log4j Issue

[Christian Grobmeier]

Are you deploying your application as a war file? If so, can you unzip that war 
file and search for log4j there?

--
The Apache Software Foundation
V.P., Data Privacy

On Fri, Apr 21, 2023, at 13:21, Gurumoorthi Vijayalingam wrote:
> No, am not able to find log4j version in tomcat lib folder. The problem 
> occurred when we upgraded the jar files from 2.2 t o2.17
>
>
> Regards,
> Guru.
>
> -Original Message-
> From: Christian Grobmeier  
> Sent: Friday, April 21, 2023 4:36 PM
> To: Gurumoorthi Vijayalingam ; 
> dev@logging.apache.org
> Subject: Re: [External] Re: Log4j Issue
>
> CAUTION: This message was sent from outside of the company. Please do 
> not click links or open attachments unless you recognize the source of 
> this email and know the content is safe.
>
>
> Hello Gurumoorthi,
>
> please subscribe to dev@logging.apache.org by sending an empty message 
> to dev-subscr...@logging.apache.org.
> It is hard for our message moderators to manually moderate your 
> messages through.
>
> You need to find the log4j version of Tomcat. Please search for this. 
> it could be in the lib folder of Tomcat.
>
> You can also search the whole installation of Tomcat for "log4j" or 
> "log4j-core-2.2.jar", then you should find it.
>
> Kind regards,
> Christian
>
>
> --
> The Apache Software Foundation
> V.P., Data Privacy
>
> On Fri, Apr 21, 2023, at 12:51, Gurumoorthi Vijayalingam wrote:
>> Any help on this request ? we stuck.
>>
>> -Original Message-
>> From: Gurumoorthi Vijayalingam
>> Sent: Thursday, April 13, 2023 7:36 AM
>> To: Christian Grobmeier ; dev@logging.apache.org
>> Subject: RE: [External] Re: Log4j Issue
>>
>> Hi Team,
>>
>> We tried the steps as Christian mentioned in below email, but still 
>> getting same error. Please help us to fix this issue
>>
>> Thanks,
>> Guru.
>>
>> -Original Message-
>> From: Christian Grobmeier 
>> Sent: Tuesday, March 21, 2023 2:17 AM
>> To: Gurumoorthi Vijayalingam ; 
>> dev@logging.apache.org
>> Cc: Paolo Gil Ostrea ; Roark Hamilton 
>> ; Bhavana Pujari ; Sireesha 
>> Kutala 
>> Subject: Re: [External] Re: Log4j Issue
>>
>> CAUTION: This message was sent from outside of the company. Please do 
>> not click links or open attachments unless you recognize the source of 
>> this email and know the content is safe.
>>
>>
>> Hello Gurumoorthi,
>>
>> Piotr already responded to your email:
>>
>>> MapLookup#newMap changed from private (as in 2.2) to package (as in
>>> 2.17.1) in the course of history. Your Tomcat is picking up the 
>>> private one, which means that log4j-core-2.2.jar is still on the 
>>> classpath.
>>> Double check that the old Log4j2 version are no longer there and 
>>> restart Tomcat to be sure.
>>>
>>> Piotr
>>
>> If this information does not help you, respond to 
>> dev@logging.apache.org as Dominik told you.
>>
>> Kind regards,
>> Christian
>>
>>
>> --
>> The Apache Software Foundation
>> V.P., Data Privacy
>>
>> On Mon, Mar 20, 2023, at 17:27, Gurumoorthi Vijayalingam wrote:
>>> Hi Team,
>>>
>>> Can you please help us to fix this issue.
>>>
>>> Regards,
>>> Guru.
>>>
>>> From: Dominik Psenner 
>>> Sent: 04 March 2023 02:16
>>> To: secur...@logging.apache.org
>>> Cc: Paolo Gil Ostrea ; Roark Hamilton 
>>> ; Gurumoorthi Vijayalingam 
>>> 
>>> Subject: [External] Re: Log4j Issue
>>>
>>> CAUTION: This message was sent from outside of the company. Please do 
>>> not click links or open attachments unless you recognize the source 
>>> of this email and know the content is safe.
>>>
>>> Hi
>>>
>>> I'm CCing the original author of the message. Please read below.
>>> Further please consider posting to the proper mailing list. The 
>>> request is not about a security issue and probably should have been 
>>> posted to dev@logging.apache.org<mailto:dev@logging.apache.org> after 
>>> subscribing to that mailing list.
>>>
>>> Warm regards
>>> Dominik
>>> --
>>> Sent from my phone. Typos are a kind gift to anyone who happens to find 
>>> them.
>>>
>>> On Fri, Mar 3, 2023, 21:17 Piotr P. Karwasz 
>>> mailto:piotr.karw...@gmail.com>> wrote:
>>> Gurumoorthi,
>>>
>>> On Fri, 3 Mar 2023 at 19:04, Gurumoorthi Vijayalingam 
>>> mailto:gvijayalin...@simeio.com>> wrote:
>>>> Just attached the error message and log4j configuration for your reference.
>>>
>>> MapLookup#newMap changed from private (as in 2.2) to package (as in
>>> 2.17.1) in the course of history. Your Tomcat is picking up the 
>>> private one, which means that log4j-core-2.2.jar is still on the 
>>> classpath.
>>> Double check that the old Log4j2 version are no longer there and 
>>> restart Tomcat to be sure.
>>>
>>> Piotr

Re: [External] Re: Log4j Issue

[Christian Grobmeier]

Hello Guru,

the only way to have this issue is with an outdated version of log4j on your 
classpath.
Can you check what classpath is being used in your container? There may be an 
additional classpath that we are not aware of.

Could you let us know the full setup of your machine, in example: 
- exact version of tomcat
- how do you deploy things
- have you probably included log4j in other components (fat jar)
- what is the classpath definition of your application?

I know this is many things to ask, but the assumption is still there are two 
different versions of log4j on your classpath. That's what I would check.

Kind regards,
Christian
 

On Fri, Apr 21, 2023, at 13:53, Gurumoorthi Vijayalingam wrote:
> No, we are not deploying as war file. And the application /lib 
> currently having followed log4j files. 
>
>
> -rw-r-. 1 fruser fruser   16431 Aug 25  2022 jcl-over-slf4j-1.7.21.jar
> -rw-r-. 1 fruser fruser4597 Aug 25  2022 jul-to-slf4j-1.7.21.jar
> -rw-r-. 1 fruser fruser   41071 Aug 25  2022 slf4j-api-1.7.21.jar
> -rw-r-. 1 fruser fruser   16831 Aug 25  2022 i18n-slf4j-1.4.4.jar
> -rwxr-xr-x. 1 fruser fruser  301872 Mar  2 17:28 log4j-api-2.17.1.jar
> -rwxr-xr-x. 1 fruser fruser 1790452 Mar  2 17:28 log4j-core-2.17.1.jar
>
> Regards,
> Guru.
>
> -Original Message-
> From: Christian Grobmeier  
> Sent: Friday, April 21, 2023 4:55 PM
> To: Gurumoorthi Vijayalingam ; 
> dev@logging.apache.org
> Subject: Re: [External] Re: Log4j Issue
>
> CAUTION: This message was sent from outside of the company. Please do 
> not click links or open attachments unless you recognize the source of 
> this email and know the content is safe.
>
>
> Are you deploying your application as a war file? If so, can you unzip 
> that war file and search for log4j there?
>
> --
> The Apache Software Foundation
> V.P., Data Privacy
>
> On Fri, Apr 21, 2023, at 13:21, Gurumoorthi Vijayalingam wrote:
>> No, am not able to find log4j version in tomcat lib folder. The 
>> problem occurred when we upgraded the jar files from 2.2 t o2.17
>>
>>
>> Regards,
>> Guru.
>>
>> -Original Message-
>> From: Christian Grobmeier 
>> Sent: Friday, April 21, 2023 4:36 PM
>> To: Gurumoorthi Vijayalingam ; 
>> dev@logging.apache.org
>> Subject: Re: [External] Re: Log4j Issue
>>
>> CAUTION: This message was sent from outside of the company. Please do 
>> not click links or open attachments unless you recognize the source of 
>> this email and know the content is safe.
>>
>>
>> Hello Gurumoorthi,
>>
>> please subscribe to dev@logging.apache.org by sending an empty message 
>> to dev-subscr...@logging.apache.org.
>> It is hard for our message moderators to manually moderate your 
>> messages through.
>>
>> You need to find the log4j version of Tomcat. Please search for this.
>> it could be in the lib folder of Tomcat.
>>
>> You can also search the whole installation of Tomcat for "log4j" or 
>> "log4j-core-2.2.jar", then you should find it.
>>
>> Kind regards,
>> Christian
>>
>>
>> --
>> The Apache Software Foundation
>> V.P., Data Privacy
>>
>> On Fri, Apr 21, 2023, at 12:51, Gurumoorthi Vijayalingam wrote:
>>> Any help on this request ? we stuck.
>>>
>>> -Original Message-
>>> From: Gurumoorthi Vijayalingam
>>> Sent: Thursday, April 13, 2023 7:36 AM
>>> To: Christian Grobmeier ; 
>>> dev@logging.apache.org
>>> Subject: RE: [External] Re: Log4j Issue
>>>
>>> Hi Team,
>>>
>>> We tried the steps as Christian mentioned in below email, but still 
>>> getting same error. Please help us to fix this issue
>>>
>>> Thanks,
>>> Guru.
>>>
>>> -Original Message-
>>> From: Christian Grobmeier 
>>> Sent: Tuesday, March 21, 2023 2:17 AM
>>> To: Gurumoorthi Vijayalingam ; 
>>> dev@logging.apache.org
>>> Cc: Paolo Gil Ostrea ; Roark Hamilton 
>>> ; Bhavana Pujari ; 
>>> Sireesha Kutala 
>>> Subject: Re: [External] Re: Log4j Issue
>>>
>>> CAUTION: This message was sent from outside of the company. Please do 
>>> not click links or open attachments unless you recognize the source 
>>> of this email and know the content is safe.
>>>
>>>
>>> Hello Gurumoorthi,
>>>
>>> Piotr already responded to your email:
>>>
>>>> MapLookup#newMap changed from private (as in 2.2) to package (as in
>>>> 2.17.1) in t

Future of our websites

[Christian Grobmeier]

Hello,

I want to discuss the future of our logging websites and have prepared a 
document for that:
https://cwiki.apache.org/confluence/display/LOGGING/The+future+of+Logging+websites+and+social+media

We have the opportunity to work with a designer, too. For now, I'd like to 
collect your ideas on how you think our websites should look, the requirements 
you think are necessary (tooling preferences i.e.), and so on.

Currently, it is a small document, but I hope to collect more input here and it 
to Confluence until we know where we are heading. 

Please don't don't think about "how it can be done", but more of "I'd like to 
see.."
We can always remove items, if we are not able to realise them.

Kind regards,
Christian


--
The Apache Software Foundation
V.P., Data Privacy

Remove Noise: using commits@?

[Christian Grobmeier]

Should Github notifications go to a separate list? I know there will be changes 
regarding threading for these kind of notifications, but maybe we should just 
use comm...@logging.apache.org for Github stuff?

Re: Remove Noise: using commits@?

[Christian Grobmeier]

I am sorry for this message, I double checked after your comments and I think I 
have my client misconfigured. I will correct it 

On Thu, Aug 24, 2023, at 08:54, Ralph Goers wrote:
> I took care of most of the noise ages ago.  I created folders in my 
> email client for GitHub, Jira, general notifications, and SVN (now 
> Git). I then set up filters based on the properties in those emails .
>
> That said, my GitHub folder currently has 1327 unread emails, Jira 567, 
> notifications 233  My logging-dev folder pretty only much gets emails 
> generated by humans.  
>
> Volkan, I haven’t checked but I have a suspicion that some of the 
> emails I DON’T get from you somehow match one of those filters and end 
> up in the wrong folder.
>
> Ralph
>
>> On Aug 23, 2023, at 2:03 PM, Matt Sicker  wrote:
>> 
>> I see things split into notifications@ and commits@. Is the issue with 
>> notifications@?
>> 
>>> On Aug 23, 2023, at 3:19 PM, Robert Middleton  wrote:
>>> 
>>> They already go to the notifications list, is that not sufficient?  I’m
>>> pretty sure that’s how all of the jira notifications are setup.
>>> 
>>> -Robert Middleton
>>> 
>>> On Wed, Aug 23, 2023 at 4:15 PM Christian Grobmeier 
>>> wrote:
>>> 
>>>> Should Github notifications go to a separate list? I know there will be
>>>> changes regarding threading for these kind of notifications, but maybe we
>>>> should just use comm...@logging.apache.org for Github stuff?
>>>> 
>>>> 
>>

Re: [Log4j] GitHub Discussions

[Christian Grobmeier]

+1


On Thu, Aug 24, 2023, at 09:26, Volkan Yazıcı wrote:
> Piotr shared a very good observation (in a private Slack post
> ) that
> users ask questions in GitHub Issues, we point them to the mailing list,
> and they disappear. See this ticket
>  for an example.
> Consequently, Matt proposed using GitHub Discussions. Robert added Pulser
> already has it enabled . I
> think many users are more keen on forums, GitHub, StackOverflow, etc. We
> should position ourselves where our users expect us to be. In that
> regard, *GitHub
> Discussions sounds like a great idea and I propose experimenting with it*:
>
>- Enable GitHub Actions
>- Update our support page accordingly
>- Update README
>
> One would think this should be a matter of a `.asf.yaml` one-liner, but 
> it
> is not
> 
> :
>
> *"GitHub Discussions is currently a beta feature and does not have an API
> endpoint. Until this is addressed, please open an Infra Jira ticket with a
> link to a consensus discussion thread for your project."*
>
>
> Hence, *I need your approval in the form of a reply to this post*.

Re: [VOTE] Release Apache Logging Parent 1.10.0

[Christian Grobmeier]

Lgtm as far as I can tell :)

+1

On Tue, Sep 5, 2023, at 11:15, Piotr P. Karwasz wrote:
> Hi Volkan,
>
> On Tue, 5 Sept 2023 at 11:04, Volkan Yazıcı  wrote:
>>
>> Summary: *THE VOTE IS STILL ON* though the Nexus URL should point to
>> https://repository.apache.org/content/repositories/orgapachelogging-1153
>> instead!
>
> The POM looks good to me and I verified that:
>
> ./mvnw clean verify artifact:compare
> -Dreference.repo=https://repository.apache.org/content/repositories/orgapachelogging-1153
>
> succeeds. Hence my +1.
>
> Piotr

Re: [VOTE] Release Apache Logging Parent 10.0.0 (RC4)

[Christian Grobmeier]

+1


On Fri, Sep 8, 2023, at 16:07, Volkan Yazıcı wrote:
> This is a vote to release the Apache Logging Parent 10.0.0 (RC4).
>
> Source repository: https://github.com/apache/logging-parent
> Commit: 2af643f84ada9a05e08229d077c6fafee2fed732
> Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1168
> Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
>
> Please download, test, and cast your votes on this mailing list.
>
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
>
> This vote is open for 72 hours and will pass unless getting a
> net negative vote count. All votes are welcome and we encourage
> everyone to test the release, but only the Logging Services PMC
> votes are officially counted. At least 3 +1 votes and more
> positive than negative votes are required.
>
> # RC3..RC4 changes[1]
>
> - Fixed `revision` and BOM flattening
>
> [1] 
> https://github.com/apache/logging-parent/compare/9aaef0c594cd7dd7fe1f9ffe244f55f20439b7ce..2af643f84ada9a05e08229d077c6fafee2fed732
>
> # RC2..RC3 changes[2]
>
> - Fixed plugin definitions
>
> [2] 
> https://github.com/apache/logging-parent/compare/24a4b9bc706ed978f36c28c114e289547c4a71ad..9aaef0c594cd7dd7fe1f9ffe244f55f20439b7ce
>
> # RC1..RC2 changes[3]
>
> - Set version to `10.0.0` (requested by Matt & Ralph)
> - Fix SVN path in `generate-email.sh` (requested by Gary)
> - Split the distribution into `src` and `bin` parts (requested by Gary)
> - Automate `revision` property update in `pom.xml` in CI (requested by Ralph)
> - Automate changelog release in CI (requested by Ralph)
>
> [3] 
> https://github.com/apache/logging-parent/compare/3dd83461faa058690a5ed821ee81dfc2d744ec7c..24a4b9bc706ed978f36c28c114e289547c4a71ad
>
> # Remarks
>
> - `logging-parent` doesn't contain any binary artifacts, it is a
>   `pom.xml` with some reusable CI workflow YAMLs.
> - One can reproduce the very same distribution by checking
>   out the commit and running
>   `./mvnw -P distribution -DattachmentCount=0 -DattachmentFilepathPattern=x`
>
> # Release Notes
>
> This minor release contains various improvements that we expect to
> relieve the load on `pom.xml` and GitHub Actions workflows of
> Maven-based projects we parent. This is of particular importance while
> managing and cutting releases from multiple repositories.
> See `README.adoc` for the complete list of features and their usage.
>
> See this[3] `log4j-tools` GitHub Actions workflow run demonstrating a
> successful release cut using a SNAPSHOT version of this
> `logging-parent` release. All preparations (release notes, source and
> binary distributions, vote & announcement emails, etc.) are staged to
> both Nexus and SVN and waiting the release manager to proceed.
>
> [4] https://github.com/apache/logging-log4j-tools/actions/runs/6122466478
>
> ## Changes
>
> ### Added
>
> * Added `changelog-export` profile to easily export changelogs
>   to Markdown files
> * Added `changelog-release` profile to easily move
>   `src/changelog/.?.x.x` contents to their associated release directory
> * Added `deploy` profile to ease the Maven `deploy` goal
> * Added `distribution` profile to easily create a distribution file
>   containing Git-tracked sources, release notes, binary
>   attachments, `NOTICE.txt`, etc.
> * Documented release instructions (i.e., `RELEASING.md`)
> * Added `release` profile to share common release-specific
>   Maven configuration
> * Added reusable GitHub Actions workflows to share CI boilerplate
>   for other repositories
> * Switched to using `log4j-changelog-maven-plugin` for managing
>   changelog and release notes
>
> ### Changed
>
> * Switched to semantic versioning (old version: `9`,
>   new version: `10.0.0`)

Re: Retire Chainsaw

[Christian Grobmeier]

On Tue, Sep 19, 2023, at 20:47, Vladimir Sitnikov wrote:
> I truly do not understand why PMC suggests "all or nothing". Either
> "chainsaw must be fully maintained" or "it must be nuked right away
> from the website".

I think this was not proposed. If we archive a project, we'd move it to a 
dormant section where everything remains available. However, it would be clear 
that there is no active maintenance.

> What is wrong with just adding "ok, this is no longer receiving
> attention because..." and keeping the website open for everybody in
> case they happen to run into chainsaw?

Adding a note on the current status is surely not a bad idea. We can add this 
note on the chainsaw website right away, maybe also saying: "this repo is in 
need of maintainers - please help out, i fyou can"

Kind regards,
Christian

>
> Vladimir

Re: Retire Chainsaw

[Christian Grobmeier]

On Tue, Sep 19, 2023, at 20:52, Vladimir Sitnikov wrote:
>> Scott, could you (or anybody else) spare time to perform the following
>> maintenance tasks?
>
> I don't use chainsaw personally, however, I am afraid I might run into
> a project that does, so I would prefer to keep docs afloat.
>
> Volkan,
> Does the deal qualify for log4j 1.x?
> I would love to resolve issues like 1..6 for log4j 1.x: adding GitHub
> Actions CI, fixing stale pom references, documenting release steps,
> and so on.

We discussed this back then and agreed not to revive a project for several 
reasons. 

However, time has passed. 

You should make a separate thread on this topic on this list, and we should 
exchange arguments again if you want to talk about it.

I cannot say if something changed in the PMC opinion, but we also have some new 
people on the board; maybe there are other opinions now.

Kind regards,
Christian

Re: Retire Chainsaw

[Christian Grobmeier]

Hi

we have last commits in 2022, so there was at least a little activity. 
I would guess we should open "issues" for Chainsaw, and add a note on the 
website saying "We need help".
If we don't see new people stepping up, we can still do something and announce 
EOL.


On Tue, Sep 19, 2023, at 20:45, Volkan Yazıcı wrote:
>1. Update dependencies (e.g., `hsqldb:hsqldb:1.8.0.7` has a CVE)
>2. Revamp the CI (preferably move it to GitHub Actions)
>3. Migrate to GitHub Issues

What does this task mean exactly? Copying issues from Jira to Github?

Kind regards
Christian

Re: [Discuss][VOTE] Move Chainsaw to dormant status

[Christian Grobmeier]

On Thu, Sep 21, 2023, at 19:38, Ralph Goers wrote:
> At this point in time I will abstain from voting. As far as I am 
> concerned only 1 vote counts - Scott’s. He has steadfastly asked that 
> the project not be retired and until he positively says he will no 
> longer maintain it I am not willing to override that.


Agreed. I don’t think this discussion is already due for a vote. Even when we 
consider it dormant, we should consider to fix the problem. Unlike log4j1, 
chainsaw was never considered EOL.

I would like to hear from Scott but also Robert, who did the last commits.

Christian 

> I should also note that AFAIK we have never “archived” a dormant 
> project. We simply change its status on the web site. That said, a 
> read-only repo does make some sense for a dormant project I guess.
>
> Ralph
>
>> On Sep 21, 2023, at 10:00 AM, Volkan Yazıcı  wrote:
>> 
>> As earlier discussions[1] indicate, Chainsaw has been lacking on
>> maintenance and no PMC member stepped up to perform necessary chores.
>> This is a vote to retire the Chainsaw by means of
>> 
>> - Move it to the list of dormant projects[2]
>> - Making it clear in its README and website that the project is not
>> maintained anymore
>> - Archive its repository[3]
>> 
>> Please cast your votes on this mailing list.
>> 
>> [ ] +1, retire the project
>> [ ] -1, don't retire, because...
>> 
>> This vote is open for 72 hours and will pass unless getting a net
>> negative vote count. All votes are welcome and we encourage everyone,
>> but only the Logging Services PMC votes are officially counted. At
>> least 3 +1 votes and more positive than negative votes are required.
>> 
>> [1] https://lists.apache.org/thread/fsykp5hxr9z0c2h85snnhnj2pq553t6q
>> [2] https://logging.apache.org/dormant.html
>> [3] https://github.com/apache/chainsaw

Re: `chainsaw` vs `logging-chainsaw`

[Christian Grobmeier]

On Thu, Sep 21, 2023, at 21:53, Robert Middleton wrote:
> I think #1 is a mirror of SVN(
> https://svn.apache.org/repos/asf/logging/chainsaw/trunk/), while #2 is a
> mirror of the gitbox repository.

Looks like the SVN mirror is outdated. Can we safely remove it?
If there are no objections, I will create a ticket with infra

Christian

> -Robert
>
> On Thu, Sep 21, 2023 at 1:59 PM Volkan Yazıcı  wrote:
>
>> Does anybody know the difference between these two repositories[1][2]
>> and why the mirroring does not work? [1] hasn't been updated since
>> 2014.
>>
>> [1] https://github.com/apache/chainsaw
>> [2] https://github.com/apache/logging-chainsaw
>>

Re: `chainsaw` vs `logging-chainsaw`

[Christian Grobmeier]

On Fri, Sep 22, 2023, at 20:16, Gary Gregory wrote:
> An svn mirror should be useless. Would you please do a sanity check? Is the
> last commit from repo in our git repo?

Yes, the Git repo: Updated on Jul 19, 2023  1,134 commits
SVN: Updated on Jul 8, 2022,  934 commits

>
> TY,
> Gary
>
> On Fri, Sep 22, 2023, 1:50 PM Christian Grobmeier  wrote:
>
>>
>> On Thu, Sep 21, 2023, at 21:53, Robert Middleton wrote:
>> > I think #1 is a mirror of SVN(
>> > https://svn.apache.org/repos/asf/logging/chainsaw/trunk/), while #2 is a
>> > mirror of the gitbox repository.
>>
>> Looks like the SVN mirror is outdated. Can we safely remove it?
>> If there are no objections, I will create a ticket with infra
>>
>> Christian
>>
>> > -Robert
>> >
>> > On Thu, Sep 21, 2023 at 1:59 PM Volkan Yazıcı  wrote:
>> >
>> >> Does anybody know the difference between these two repositories[1][2]
>> >> and why the mirroring does not work? [1] hasn't been updated since
>> >> 2014.
>> >>
>> >> [1] https://github.com/apache/chainsaw
>> >> [2] https://github.com/apache/logging-chainsaw
>> >>
>>

[chainsaw] Developing for Chainsaw

[Christian Grobmeier]

Hi,

I tried to start Chainsaw from the official build, using Maven (mvn package) 
and even starting it using the LogUI main class.

All methods failed for various reasons.

What is the best method to get Chainsaw started, when trying to fix an issue?

Kind regards,
Christian

When running using IntelliJ:

20:33:04.814 [AWT-EventQueue-0] INFO  org.apache.log4j.chainsaw.LogUI - 
SecurityManager is now: null
20:33:17.611 [AWT-EventQueue-0] WARN  
org.apache.log4j.chainsaw.help.HelpManager - Could not find any local JavaDocs, 
you might want to consider running 'ant javadoc'. The release version will be 
able to access Javadocs from the Apache website.
20:33:26.420 [AWT-EventQueue-0] DEBUG 
org.apache.log4j.chainsaw.ApplicationPreferenceModelPanel - Can't find new GTK 
L&F, might be Windows, or (ApplicationPreferenceModelPanel.java:127)
at 
org.apache.log4j.chainsaw.ApplicationPreferenceModelPanel.createTreeModel(ApplicationPreferenceModelPanel.java:86)
at 
org.apache.log4j.chainsaw.AbstractPreferencePanel.initComponents(AbstractPreferencePanel.java:67)
at 
org.apache.log4j.chainsaw.ApplicationPreferenceModelPanel.(ApplicationPreferenceModelPanel.java:57)
at org.apache.log4j.chainsaw.LogUI.initGUI(LogUI.java:406)
at org.apache.log4j.chainsaw.LogUI.activateViewer(LogUI.java:528)
at 
java.desktop/java.awt.event.InvocationEvent.dispatch$$$capture(InvocationEvent.java:318)
at 
java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java)
at 
java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:771)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:722)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:716)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at 
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:741)
at 
java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at 
java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at 
java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at 
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at 
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at 
java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)



--
The Apache Software Foundation
V.P., Data Privacy

Migrating the landing page

[Christian Grobmeier]

Hello,

the current landing page:
https://logging.apache.org/

is done with JBake. We have rather complicated instructions on how to 
re-generate the landing page:
https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Sites

The Infra team recommends Pelican or Jekyll to create these kinds of pages. I 
have in-depth knowledge of Jekyll and would like to propose migrating the 
current landing page to Jekyll.

The benefits:

- autodeploy of our changes
- great support of blogging (I'd like to create one)
- easy handling and supported by Infra
- writing content in Markdown

I am aware that we have a discussion open on how to do documentation in the 
future. I would still like to migrate the page asap and  - if deemed necessary 
- touch it again later.

So far, I will leave all design/content intact until migrated, and come back 
with additional changes (as the blog) after migration to be discussed 
separately.

If there are no objections, I will start with this move sometime next week.

Thanks!
Christian

--
The Apache Software Foundation
V.P., Data Privacy

Re: Migrating the landing page

[Christian Grobmeier]

On Fri, Sep 22, 2023, at 22:08, Ralph Goers wrote:
> Personally, I hate all these tools. I picked JBake simply because I 
> could figure out how to run it with a simple Maven command.
>
> I really don’t see how you can make it any simpler by changing the 
> tooling. If you look at the instructions they are all git commands 
> except for “mvn install”.
>
> The current web site supports markdown and asciidoc.
>
> I am not in favor of changing the tooling for the sake of changing the 
> tooling.  I am in favor of changing the tooling if there is some major 
> tangible benefit. I have always wanted to use tooling that would let us 
> edit the pages in a GUI editor similar to like Wix or Squarespace do. I 
> despise having to write things in Markdown or Asiciidoc and then run a 
> tool so I can preview what it is going to look like.
>
> In other words, I want the ease of editing and maintaining the web site 
> to drive the tooling decision, not the other way around.

Currently, there are 10 steps listed for deploying the website.
I do "git commit && push"

Currently, we have to install JBake
In my scenario, I use Docker.

As an example, for the privacy website to check:
docker run --rm -p 4000:4000 --mount type=bind,src=$PWD,dst=/root/build --mount 
type=volume,dst=/root/build/node_modules -it apache/privacy_apache_org serve 
--watch --incremental

There are significant benefits in this, such as speed of deployment, support of 
infra, etc pp. 
I don't see any reason to stick with JBake.

I understand you don't like static site generators, but in this case, a less 
frequently updated website, I see benefits: easy blogging support and ASF 
support. Additionally, Docker support.

There is also GUI support for Jekyll and Hugo, but I don't like it. There is 
none for JBake to my knowledge.

I an not changing the tooling because I like Jekyll better, but because it is a 
standard, I have autodeploy tools ready and it generally is better understood 
than JBake.

Kind regards,
Christian


>
> Ralph
>
>> On Sep 22, 2023, at 11:47 AM, Christian Grobmeier  
>> wrote:
>> 
>> Hello,
>> 
>> the current landing page:
>> https://logging.apache.org/
>> 
>> is done with JBake. We have rather complicated instructions on how to 
>> re-generate the landing page:
>> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Sites
>> 
>> The Infra team recommends Pelican or Jekyll to create these kinds of pages. 
>> I have in-depth knowledge of Jekyll and would like to propose migrating the 
>> current landing page to Jekyll.
>> 
>> The benefits:
>> 
>> - autodeploy of our changes
>> - great support of blogging (I'd like to create one)
>> - easy handling and supported by Infra
>> - writing content in Markdown
>> 
>> I am aware that we have a discussion open on how to do documentation in the 
>> future. I would still like to migrate the page asap and  - if deemed 
>> necessary - touch it again later.
>> 
>> So far, I will leave all design/content intact until migrated, and come back 
>> with additional changes (as the blog) after migration to be discussed 
>> separately.
>> 
>> If there are no objections, I will start with this move sometime next week.
>> 
>> Thanks!
>> Christian
>> 
>> --
>> The Apache Software Foundation
>> V.P., Data Privacy

Re: Migrating the landing page

[Christian Grobmeier]

On Sat, Sep 23, 2023, at 02:30, Apache wrote:
> You have to be kidding me. I now need to use Docker to build the web 
> site? And that is somehow simpler?

The actual build is then done by GitHub Actions. And yes, I consider it a lot 
simpler to run one docker command (I even have a shell script for this) to 
check and let actions do the rest.

You can see it in action on the privacy website. 

>
> Ralph
>
>> On Sep 22, 2023, at 2:03 PM, Christian Grobmeier  
>> wrote:
>> 
>> 
>> 
>>> On Fri, Sep 22, 2023, at 22:08, Ralph Goers wrote:
>>> Personally, I hate all these tools. I picked JBake simply because I 
>>> could figure out how to run it with a simple Maven command.
>>> 
>>> I really don’t see how you can make it any simpler by changing the 
>>> tooling. If you look at the instructions they are all git commands 
>>> except for “mvn install”.
>>> 
>>> The current web site supports markdown and asciidoc.
>>> 
>>> I am not in favor of changing the tooling for the sake of changing the 
>>> tooling.  I am in favor of changing the tooling if there is some major 
>>> tangible benefit. I have always wanted to use tooling that would let us 
>>> edit the pages in a GUI editor similar to like Wix or Squarespace do. I 
>>> despise having to write things in Markdown or Asiciidoc and then run a 
>>> tool so I can preview what it is going to look like.
>>> 
>>> In other words, I want the ease of editing and maintaining the web site 
>>> to drive the tooling decision, not the other way around.
>> 
>> Currently, there are 10 steps listed for deploying the website.
>> I do "git commit && push"
>> 
>> Currently, we have to install JBake
>> In my scenario, I use Docker.
>> 
>> As an example, for the privacy website to check:
>> docker run --rm -p 4000:4000 --mount type=bind,src=$PWD,dst=/root/build 
>> --mount type=volume,dst=/root/build/node_modules -it 
>> apache/privacy_apache_org serve --watch --incremental
>> 
>> There are significant benefits in this, such as speed of deployment, support 
>> of infra, etc pp. 
>> I don't see any reason to stick with JBake.
>> 
>> I understand you don't like static site generators, but in this case, a less 
>> frequently updated website, I see benefits: easy blogging support and ASF 
>> support. Additionally, Docker support.
>> 
>> There is also GUI support for Jekyll and Hugo, but I don't like it. There is 
>> none for JBake to my knowledge.
>> 
>> I an not changing the tooling because I like Jekyll better, but because it 
>> is a standard, I have autodeploy tools ready and it generally is better 
>> understood than JBake.
>> 
>> Kind regards,
>> Christian
>> 
>> 
>>> 
>>> Ralph
>>> 
>>>>> On Sep 22, 2023, at 11:47 AM, Christian Grobmeier  
>>>>> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> the current landing page:
>>>> https://logging.apache.org/
>>>> 
>>>> is done with JBake. We have rather complicated instructions on how to 
>>>> re-generate the landing page:
>>>> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Sites
>>>> 
>>>> The Infra team recommends Pelican or Jekyll to create these kinds of 
>>>> pages. I have in-depth knowledge of Jekyll and would like to propose 
>>>> migrating the current landing page to Jekyll.
>>>> 
>>>> The benefits:
>>>> 
>>>> - autodeploy of our changes
>>>> - great support of blogging (I'd like to create one)
>>>> - easy handling and supported by Infra
>>>> - writing content in Markdown
>>>> 
>>>> I am aware that we have a discussion open on how to do documentation in 
>>>> the future. I would still like to migrate the page asap and  - if deemed 
>>>> necessary - touch it again later.
>>>> 
>>>> So far, I will leave all design/content intact until migrated, and come 
>>>> back with additional changes (as the blog) after migration to be discussed 
>>>> separately.
>>>> 
>>>> If there are no objections, I will start with this move sometime next week.
>>>> 
>>>> Thanks!
>>>> Christian
>>>> 
>>>> --
>>>> The Apache Software Foundation
>>>> V.P., Data Privacy

Re: `chainsaw` vs `logging-chainsaw`

[Christian Grobmeier]

Hi,

Infra archived this repo for us:
https://github.com/apache/chainsaw

Kind regards,
Christian

On Fri, Sep 22, 2023, at 22:33, Gary Gregory wrote:
> On Fri, Sep 22, 2023 at 2:28 PM Christian Grobmeier
>  wrote:
>>
>>
>>
>> On Fri, Sep 22, 2023, at 20:16, Gary Gregory wrote:
>> > An svn mirror should be useless. Would you please do a sanity check? Is the
>> > last commit from repo in our git repo?
>>
>> Yes, the Git repo: Updated on Jul 19, 2023  1,134 commits
>> SVN: Updated on Jul 8, 2022,  934 commits
>
> TY for checking Christian.
>
> Gary
>
>>
>> >
>> > TY,
>> > Gary
>> >
>> > On Fri, Sep 22, 2023, 1:50 PM Christian Grobmeier  
>> > wrote:
>> >
>> >>
>> >> On Thu, Sep 21, 2023, at 21:53, Robert Middleton wrote:
>> >> > I think #1 is a mirror of SVN(
>> >> > https://svn.apache.org/repos/asf/logging/chainsaw/trunk/), while #2 is a
>> >> > mirror of the gitbox repository.
>> >>
>> >> Looks like the SVN mirror is outdated. Can we safely remove it?
>> >> If there are no objections, I will create a ticket with infra
>> >>
>> >> Christian
>> >>
>> >> > -Robert
>> >> >
>> >> > On Thu, Sep 21, 2023 at 1:59 PM Volkan Yazıcı  wrote:
>> >> >
>> >> >> Does anybody know the difference between these two repositories[1][2]
>> >> >> and why the mirroring does not work? [1] hasn't been updated since
>> >> >> 2014.
>> >> >>
>> >> >> [1] https://github.com/apache/chainsaw
>> >> >> [2] https://github.com/apache/logging-chainsaw
>> >> >>
>> >>

Re: Archiving `logging-log4j-server` and `-audit`

[Christian Grobmeier]

Hi,

what is the purpose of log4j-server actually?
I don't find any information about it.

I wonder, if this has a real use case (Gary uses it) but no releases, should we 
create a Sandbox/Lab?
Personally, if this just for example purposes, we maybe should actually move it 
-samples as suggested below.

This thread is 8 days old, probably it is safe to move this repo now - we can 
always -1 a commit if there is still an objection

Kind regards,
Christian


On Mon, Sep 18, 2023, at 10:09, Volkan Yazıcı wrote:
> Hey Gary,
>
> I'd appreciate your response on this `dev@` thread. I am cleaning up all
> repositories and trying to either (in order of preference)
>
>1. delete them (since they are practically empty or irrelevant)
>2. archive them (clearly communicate it to the users that nobody is
>working on these projects, they are not maintained, etc. the repository is
>there only for archival purposes. note the archival is a reversible
>operation.)
>3. modernize them (make `./mvnw clean verify` work flawlessly on
>multiple platforms, erect the CI, updated dependencies, setup `dependabot`,
>clean up `pom.xml`s, docs, `README.adoc`, etc.)
>
> From this point of view, we (Ralph, Piotr, and me) are in favor of
> archiving `logging-log4j-server` and moving the `log4j-server` module to
> `logging-log4j-samples`, which is completely modernized. Is that okay with
> you?
>
>
> On Thu, Sep 14, 2023 at 8:25 PM Volkan Yazıcı  wrote:
>
>> Gary, you haven't replied to this question of mine yet. I'd like to
>> know more about your use case.
>>
>> I had a call with Ralph and he stated `log4j-server` is not usable
>> without customizations. Hence, he added, it is better suited to
>> `log4j-samples`. I liked this idea. Do you have any objections if we
>> archive the `log4j-server` and move its content to `log4j-samples`
>> instead?
>>
>> On Wed, Sep 13, 2023 at 3:16 PM Volkan Yazıcı  wrote:
>> >
>> > The project doesn't have any releases, how do you use it at work? Note
>> that once they are retired (i.e., archived) you will still have access to
>> the sources.
>> >
>> > On Wed, Sep 13, 2023 at 3:06 PM Gary Gregory 
>> wrote:
>> >>
>> >> Yes, we use logging-log4j-server at work.
>> >>
>> >> Gary
>> >>
>> >> On Wed, Sep 13, 2023 at 8:15 AM Volkan Yazıcı  wrote:
>> >> >
>> >> > I propose retiring `logging-log4j-server`
>> >> >  and
>> `logging-log4j-audit`
>> >> >  repositories (which
>> never
>> >> > had any releases) and making it clear in their READMEs that these
>> >> > repositories exist only for archival purposes. Objections?
>>

Re: Migrating the landing page

[Christian Grobmeier]

elease notes,
>> adding a search bar, styling the page, syntax highlighting source code,
>> etc. – should be done by a separate "tool" located elsewhere. This will
>> enable the committers to stop worrying about the website and its
>> intricacies once and for all. As a bonus, Logging Services will have a one
>> uniform beautifully-dressed look to the outside world where they can
>> navigate with ease. The good news is, the tooling is there and it is called
>> Antora <https://antora.org/>. Somebody just needs to spearhead this effort
>> and put a handful of strongly-opinionated guys on the same page. 😅
>> 
>> *Saving the day*
>> 
>> Do you just want to save the day? Go ahead, JBake and AsciiDoc are a great
>> combo. People will appreciate it. It will certainly be an improvement. Do
>> you want to build the future? You should look beyond a single project and
>> its individual website.
>> 
>> 
>> On Fri, Sep 22, 2023 at 8:48 PM Christian Grobmeier 
>> wrote:
>> 
>>> Hello,
>>> 
>>> the current landing page:
>>> https://logging.apache.org/
>>> 
>>> is done with JBake. We have rather complicated instructions on how to
>>> re-generate the landing page:
>>> 
>>> https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Sites
>>> 
>>> The Infra team recommends Pelican or Jekyll to create these kinds of
>>> pages. I have in-depth knowledge of Jekyll and would like to propose
>>> migrating the current landing page to Jekyll.
>>> 
>>> The benefits:
>>> 
>>> - autodeploy of our changes
>>> - great support of blogging (I'd like to create one)
>>> - easy handling and supported by Infra
>>> - writing content in Markdown
>>> 
>>> I am aware that we have a discussion open on how to do documentation in
>>> the future. I would still like to migrate the page asap and  - if deemed
>>> necessary - touch it again later.
>>> 
>>> So far, I will leave all design/content intact until migrated, and come
>>> back with additional changes (as the blog) after migration to be discussed
>>> separately.
>>> 
>>> If there are no objections, I will start with this move sometime next week.
>>> 
>>> Thanks!
>>> Christian
>>> 
>>> --
>>> The Apache Software Foundation
>>> V.P., Data Privacy
>>>

Re: Migrating the landing page

[Christian Grobmeier]

vacy_apache_org serve --watch --incremental
>>>> 
>>>> Uh... That hurts. This is how you can achieve the same in JBake: `./mvnw
>>>> jbake:watch`.
>>>> 
>>>> *The unspoken killer feature: reproducibility*
>>>> 
>>>> I have been tinkering with static site generators for more than a decade –
>>>> I love them. I don't know of your experience, but anything beyond Java
>>>> sucks a big time when it comes to reproducibility. You cannot run a Ruby
>>>> application written 10 years ago on a modern operating system. Many Ruby
>>>> libraries depend on system libraries that either are not shipped with the
>>>> distro anymore or broke the ABI in the past. I need to use this
>>>> hand-crafted `Dockerfile`
>>>> <https://github.com/vy/vy.github.io/blob/source/Dockerfile> running on
>>>> Ubuntu `14.04` with a particular constellation of Ruby dependencies so that
>>>> I can install a version of `nanoc` that compiles my website. It is an
>>>> operational nightmare.
>>>> 
>>>> But let's talk about Java and JBake: `./mvnw jbake:watch`. This only
>>>> requires the host to have a decent OS, shell, and JDK. That is all. No
>>>> more, no less. Docker? Nah. Python? Nah. Some weird OS package? Nah. I can
>>>> confidently say this command will highly likely run without a single line
>>>> of change for several decades. Given its historical track record, I don't
>>>> think any other alternative can beat Java in this area and it is of
>>>> uttermost importance given how hard it is for the PMC to afford time on the
>>>> website.
>>>> 
>>>> *The argument of familiarity*
>>>> 
>>>> 90% of Logging Services committers are Java developers. That is where our
>>>> expertise lies in. If you throw at them a `pom.xml` and a bunch of AsciiDoc
>>>> files in `src/site/asciidoc`, without blinking an eye, they would correctly
>>>> guess what to do. Moving away from this safe zone to uncharted territories,
>>>> in particular, without factually justifying the rationale, will simply do
>>>> more harm than benefit, if there is any at all.
>>>> 
>>>> *The argument of "INFRA supports Jekyll and Pelican"*
>>>> 
>>>> What does that support exactly entail? You don't need to compile the site
>>>> and push changes to a particular branch that INFRA monitors to serve the
>>>> actual domain? It is a dozen lines of GitHub Actions workflow YAML. I
>>>> volunteer to do this.
>>>> 
>>>> ASF INFRA serves projects by providing infrastructural functions that
>>>> didn't exist... decades ago? Many of its offerings are superseded by far
>>>> better alternatives in platforms like GitHub, GitLab, etc.
>>>> 
>>>> *Markdown-vs-AsciiDoc*
>>>> 
>>>> If you look close (and long?) enough to a Markdown-based document
>>>> collection, you will notice HTML tags, everywhere. Wait a second? Why did
>>>> we decide to use Markdown in the first place? To avoid manually typing
>>>> HTML! Yup. The moment you want to do formatting that is slightly
>>>> sophisticated (putting a code block under a bullet, annotating source code,
>>>> admonitions, etc.) Markdown collapses. Hence, people reach out to sprinkle
>>>> HTML into their Markdown. This makes templating impossible in the long run,
>>>> since every single hand-written HTML will have its own style, formatting,
>>>> structure, etc. which totally defeats the purpose of using a unified markup
>>>> language. Hence, please use a markup language that would suffice the
>>>> formatting needs of a technical document. Given its rich feature set,
>>>> wealthy ecosystem, and large community, I doubt if there is an alternative
>>>> here besides AsciiDoc.
>>>> 
>>>> *The future of Logging Services websites*
>>>> 
>>>> In its current state, we have several projects erecting their own websites
>>>> by tooling of their preferences: Log4cxx uses Doxygen, Log4j Scala API uses
>>>> `asciidoc-maven-plugin`, Log4j 2 and Log4j Kotlin API uses
>>>> `maven-site-plugin`, etc. Such a diverse ecosystem requires significant
>>>> maintenance investment. Maintenance of not just the tooling, but also
>>>> styling. In my opinion, ideally, projects should simply provide a set of
>>>> gl

Re: [VOTE] Release Apache Log4j Kotlin API 1.3.0

[Christian Grobmeier]

+1

--
The Apache Software Foundation
V.P., Data Privacy

On Thu, Sep 28, 2023, at 15:26, Volkan Yazıcı wrote:
> This is a vote to release the Apache Log4j Kotlin API 1.3.0.
>
> Source repository: https://github.com/apache/logging-log4j-kotlin
> Commit: b273cfb450898f079d2fd10b575330bfb900101b
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-kotlin
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1186
> Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
>
> Please download, test, and cast your votes on this mailing list.
>
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
>
> This vote is open for 72 hours and will pass unless getting a
> net negative vote count. All votes are welcome and we encourage
> everyone to test the release, but only the Logging Services PMC
> votes are officially counted. At least 3 +1 votes and more
> positive than negative votes are required.
>
> === Release Notes
>
> This minor release bumps the Kotlin baseline to 1.6.21 and contains
> various small improvements.
>
>  Added
>
> * Added an extension property for storing a cached logger (#29)
> * Added facade APIs for manipulating the context map and stack (#30)
> * Added missing `catching` and `throwing` API methods in `KotlinLogger` (#32)
> * Added JPMS support and used `org.apache.logging.log4j.api_kotlin`
> for the module name (identical to OSGi `Bundle-SymbolicName`) of the
> `log4j-api-kotlin` artifact
>
>  Changed
>
> * Updated Log4j dependency to `2.20.0`
> * Bumped `logging-parent` version to `10.1.0` and overhauled the
> entire project infrastructure to take advantage of its goodies (#37)
> * Renamed OSGi `Bundle-SymbolicName` from
> `org.apache.logging.log4j.kotlin` to
> `org.apache.logging.log4j.api_kotlin`
> * Migrated tests to JUnit 5
> * Bumped Kotlin and Kotlin Extensions baseline to `1.6.21` and `1.6.4`
> respectively

Re: Refining product feature set strategy

[Christian Grobmeier]

I see your point and agree with many things. I suggest we are not (only) making 
"data-driven" decisions. Most of us do this for fun, not for money. It is 
perfectly OK to decide just because we like it and enjoy ourselves.

You are raising an excellent point: maintenance.

We have a lot of stuff that appears to be less maintained, and it is impossible 
to judge if it is safe to use. 

We can always add new groups of components, similar to Apache Commons: 
Maintained, Sandbox, and Dormant, if moving to GitHub is not an option.

I would categorize it like this:

* Maintained: active contributions, three people willing to vote on releases 
and follow its development
* Sandbox: active contributions, at least one person willing to keep an 
oversight, no releases necessary, website flagged with "This component is 
experimental - use at own risk."
* Dormant: No active contributions, no (more) releases, website flagged with 
"This component is not maintained."

While we don't need to take my proposal, I would like to implement something 
like this so:

* we can keep a better oversight, 
* have a more clear communication with our users and 
* also have a clear guideline that saves us tons of "deprecation discussions."

Kind regards,
Christian

On Fri, Sep 29, 2023, at 09:59, Volkan Yazıcı wrote:
> I want to challenge the current way of PMC determining the product feature
> set and work towards a more sustainable alternative.
>
> Logging Services team...
>
>- delivers mission-critical products that are deployed at the core of
>the world-wide infrastructure (actually, in Mars too)
>- is short on development resources compared to its wide range of
>offerings
>- deals with substantial amount of legacy
>- suffers from knowledge silo
>
> Any IT team in this state would be really conservative on accepting new
> features and try hard to get rid of the bloat. They would react to this
> challenge by first discovering the user base, pinpointing the core values,
> and then lazer-focusing the limited development resources on to the crucial
> deliverables. Though we do something totally different, one can even say
> the opposite. Below I share excerpts from recent mailing list posts.
>
> *"I had added [X] ... to show how to write plugins and for some
> consulting-related use cases"* – PMC member explaining how feature X was
> released
>
> *"... stuff seems like it could be useful"* – PMC member asking to keep
> feature X
>
> *"my employer used [X] ... for anyone implementing ... this would be very
> relevant.  By archiving this we are basically telling users that they
> cannot use it any more since it will no longer be supported. For that
> reason I am not in favor of [retiring]"* – PMC member asking to keep
> feature X
>
> *"We [the employer] ... use [X]"* – PMC member asking to keep feature X
>
> *"User base [is] ... very low to non-existent."* – PMC member asking to
> keep product X
>
> *"[PMC member] has steadfastly [reacted] ... and until he positively says
> he will no longer maintain it I am not willing to override that"* – PMC
> member asking to keep product X because another (one and only) PMC member
> reacted on product retirement inquiry
>
> *"Our employers are ... paying customers."* – a PMC member explaining why
> we should keep feature X used by an organization employing another PMC
> member
>
>
> I see a pattern in the way we decide to maintain a feature/product:
>
>- It is not data-driven. It is disconnected from its user base. No usage
>statistics, etc. is shared or used.
>- We serve individuals' and employers' agendas.
>- We underestimate the cost of adding/keeping a feature.
>
> I think this diet is "unhealthy" because:
>
>- It adds up to the bloat. It is yet another component developers need
>to maintain its dependencies, documentation, website, integration with the
>build system, etc. This bizarrely slows down the development experience.
>(Ever wondered how much `log4j-osgi` takes during `./mvnw verify`?)
>- It adds up to the attack surface.
>- Features that are supposed to be optional get shipped to users without
>their consent. (Consider the percentage of the Log4Shell victims that used
>the JNDI functionality at all.)
>- Scarce development resources get wasted on chores due to the
>excessive landscape.
>- It gives users the wrong impression that the feature/product is
>maintained, though under the hood it is just kept there because a
>privileged group wants so.
>
> I want to refine this approach with your help. To start the discussion, I
> propose the following strategy instead:
>
> *"We only accept a feature with data-driven justification."* – Have a brand
> new idea? Grab yourself a GitHub/GitLab repository that belongs to either
> you or your employer, knock yourself out without any ASF/PMC burdens, and
> amaze your users. Once the user attraction gets enough gravity, let's
> discuss blessing it as a part of th

Re: [Discuss][VOTE] Move Chainsaw to dormant status

[Christian Grobmeier]

On Fri, Sep 22, 2023, at 12:51, Christian Grobmeier wrote:
> On Thu, Sep 21, 2023, at 19:38, Ralph Goers wrote:
>> At this point in time I will abstain from voting. As far as I am 
>> concerned only 1 vote counts - Scott’s. He has steadfastly asked that 
>> the project not be retired and until he positively says he will no 
>> longer maintain it I am not willing to override that.
>
>
> Agreed. I don’t think this discussion is already due for a vote. Even 
> when we consider it dormant, we should consider to fix the problem. 
> Unlike log4j1, chainsaw was never considered EOL.
>
> I would like to hear from Scott but also Robert, who did the last commits.

I was just reading that message again, and would like to add something.

I actually disagree that only one vote counts in this case. The PMC as a whole 
is responsible for maintaining a component, fixing security issues etc. If we 
decide to keep a component, we should be behind this decision.

I think we should reopen this vote and discussion in a few weeks again to see, 
if there actually was any maintenance (no threating here)

Kind regards,
Christian



> Christian 
>
>> I should also note that AFAIK we have never “archived” a dormant 
>> project. We simply change its status on the web site. That said, a 
>> read-only repo does make some sense for a dormant project I guess.
>>
>> Ralph
>>
>>> On Sep 21, 2023, at 10:00 AM, Volkan Yazıcı  wrote:
>>> 
>>> As earlier discussions[1] indicate, Chainsaw has been lacking on
>>> maintenance and no PMC member stepped up to perform necessary chores.
>>> This is a vote to retire the Chainsaw by means of
>>> 
>>> - Move it to the list of dormant projects[2]
>>> - Making it clear in its README and website that the project is not
>>> maintained anymore
>>> - Archive its repository[3]
>>> 
>>> Please cast your votes on this mailing list.
>>> 
>>> [ ] +1, retire the project
>>> [ ] -1, don't retire, because...
>>> 
>>> This vote is open for 72 hours and will pass unless getting a net
>>> negative vote count. All votes are welcome and we encourage everyone,
>>> but only the Logging Services PMC votes are officially counted. At
>>> least 3 +1 votes and more positive than negative votes are required.
>>> 
>>> [1] https://lists.apache.org/thread/fsykp5hxr9z0c2h85snnhnj2pq553t6q
>>> [2] https://logging.apache.org/dormant.html
>>> [3] https://github.com/apache/chainsaw

[chainsaw] Trouble starting it at all

[Christian Grobmeier]

Hi,

I have found out Chainsaw requires Java 11. I used this from IntelliJ and run 
LogUI.
However, even when there is no error message, the Splash Screen never 
disappears. 
Is there any specific verion of Java I need?

These are he last lines i see:

15:15:29.580 [AWT-EventQueue-0] DEBUG 
org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map 
org.apache.log4j.chainsaw.LogUI
15:15:29.580 [AWT-EventQueue-0] DEBUG 
org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map 
org.apache.log4j.chainsaw.LogPanelLoggerTreeModel
15:15:29.581 [AWT-EventQueue-0] DEBUG 
org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map 
org.apache.log4j.chainsaw.LoggerNameTreePanel

Then no further actitivty,

Any ideas?

--
The Apache Software Foundation
V.P., Data Privacy

Re: [chainsaw] Trouble starting it at all

[Christian Grobmeier]

I have installed Netbeans and tried it with that. 
I also tried Corretta 11, Zulu 11, Zulu 11 with FX. OpenJDK 11 is no longer 
available for me (on Mac) it seems.

Still no success. The splash opens, but no further movement.

I have two errors earlier, but I don't think they break anything:

ERROR org.apache.log4j.chainsaw.LogUI - Uncaught exception in thread 
Thread[AWT-EventQueue-0,6,main]
java.util.NoSuchElementException: Key 'statusBar' does not map to an existing 
object!
at 
org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
 ~[commons-configuration2-2.7.jar:2.7]
at 
org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)
 ~[commons-configuration2-2.7.jar:2.7]

and the underlying cause is printed extra:

java.util.NoSuchElementException: Key 'statusBar' does not map to an existing 
object!
at 
org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
at 
org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)


Either it is something special in the OpenJDK or maybe even related to the Mac. 
I assume you are on Windows. Could you try with another JDK, maybe Zulu or 
Correta?





--
The Apache Software Foundation
V.P., Data Privacy

On Fri, Sep 29, 2023, at 17:19, Robert Middleton wrote:
> It starts up for me with Netbeans and OpenJDK 11.  I would expect an
> exception/stack trace to be printed to stderr if an exception was thrown
> that caused it to fail to load.
>
> -Robert Middleton
>
> On Fri, Sep 29, 2023 at 9:17 AM Christian Grobmeier 
> wrote:
>
>> Hi,
>>
>> I have found out Chainsaw requires Java 11. I used this from IntelliJ and
>> run LogUI.
>> However, even when there is no error message, the Splash Screen never
>> disappears.
>> Is there any specific verion of Java I need?
>>
>> These are he last lines i see:
>>
>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>> org.apache.log4j.chainsaw.LogUI
>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel
>> 15:15:29.581 [AWT-EventQueue-0] DEBUG
>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>> org.apache.log4j.chainsaw.LoggerNameTreePanel
>>
>> Then no further actitivty,
>>
>> Any ideas?
>>
>> --
>> The Apache Software Foundation
>> V.P., Data Privacy
>>

Re: [chainsaw] Trouble starting it at all

[Christian Grobmeier]

OK, got it running, after commenting those lines:

//statusBar.setSelected(config.getBoolean("statusBar"));
statusBar.setSelected(false);
//receivers.setSelected(config.getBoolean("showReceivers"));
receivers.setSelected(false);
//toolBar.setSelected(config.getBoolean("toolbar"));
toolBar.setSelected(false);
//configureTabPlacement(config.getInt("tabPlacement"));
configureTabPlacement(1);

Looks like the missing configuration is a problem. 
Is there any configuration I should add to the startup?


On Fri, Sep 29, 2023, at 18:36, Christian Grobmeier wrote:
> I have installed Netbeans and tried it with that. 
> I also tried Corretta 11, Zulu 11, Zulu 11 with FX. OpenJDK 11 is no 
> longer available for me (on Mac) it seems.
>
> Still no success. The splash opens, but no further movement.
>
> I have two errors earlier, but I don't think they break anything:
>
> ERROR org.apache.log4j.chainsaw.LogUI - Uncaught exception in thread 
> Thread[AWT-EventQueue-0,6,main]
> java.util.NoSuchElementException: Key 'statusBar' does not map to an 
> existing object!
>   at 
> org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
>  
> ~[commons-configuration2-2.7.jar:2.7]
>   at 
> org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)
>  
> ~[commons-configuration2-2.7.jar:2.7]
>
> and the underlying cause is printed extra:
>
> java.util.NoSuchElementException: Key 'statusBar' does not map to an 
> existing object!
>   at 
> org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
>   at 
> org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)
>
>
> Either it is something special in the OpenJDK or maybe even related to 
> the Mac. I assume you are on Windows. Could you try with another JDK, 
> maybe Zulu or Correta?
>
>
>
>
>
> --
> The Apache Software Foundation
> V.P., Data Privacy
>
> On Fri, Sep 29, 2023, at 17:19, Robert Middleton wrote:
>> It starts up for me with Netbeans and OpenJDK 11.  I would expect an
>> exception/stack trace to be printed to stderr if an exception was thrown
>> that caused it to fail to load.
>>
>> -Robert Middleton
>>
>> On Fri, Sep 29, 2023 at 9:17 AM Christian Grobmeier 
>> wrote:
>>
>>> Hi,
>>>
>>> I have found out Chainsaw requires Java 11. I used this from IntelliJ and
>>> run LogUI.
>>> However, even when there is no error message, the Splash Screen never
>>> disappears.
>>> Is there any specific verion of Java I need?
>>>
>>> These are he last lines i see:
>>>
>>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
>>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>>> org.apache.log4j.chainsaw.LogUI
>>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
>>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel
>>> 15:15:29.581 [AWT-EventQueue-0] DEBUG
>>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>>> org.apache.log4j.chainsaw.LoggerNameTreePanel
>>>
>>> Then no further actitivty,
>>>
>>> Any ideas?
>>>
>>> --
>>> The Apache Software Foundation
>>> V.P., Data Privacy
>>>

Re: [chainsaw] Trouble starting it at all

[Christian Grobmeier]

On Fri, Sep 29, 2023, at 18:51, Scott Deboy wrote:
> There should be a default config. Do you have anything in the .chainsaw
> directory? If so, delete it.

Yes figured it right when I received your message.

The application created this directory. Looking into it, there were files as 
chainsaw.settings.properties. These files looked incomplete. 

After I deleted it, it actually worked. No idea why this was created that way.


>
> On Fri, Sep 29, 2023, 9:49 AM Christian Grobmeier 
> wrote:
>
>> OK, got it running, after commenting those lines:
>>
>> //statusBar.setSelected(config.getBoolean("statusBar"));
>> statusBar.setSelected(false);
>> //receivers.setSelected(config.getBoolean("showReceivers"));
>> receivers.setSelected(false);
>> //toolBar.setSelected(config.getBoolean("toolbar"));
>> toolBar.setSelected(false);
>> //configureTabPlacement(config.getInt("tabPlacement"));
>> configureTabPlacement(1);
>>
>> Looks like the missing configuration is a problem.
>> Is there any configuration I should add to the startup?
>>
>>
>> On Fri, Sep 29, 2023, at 18:36, Christian Grobmeier wrote:
>> > I have installed Netbeans and tried it with that.
>> > I also tried Corretta 11, Zulu 11, Zulu 11 with FX. OpenJDK 11 is no
>> > longer available for me (on Mac) it seems.
>> >
>> > Still no success. The splash opens, but no further movement.
>> >
>> > I have two errors earlier, but I don't think they break anything:
>> >
>> > ERROR org.apache.log4j.chainsaw.LogUI - Uncaught exception in thread
>> > Thread[AWT-EventQueue-0,6,main]
>> > java.util.NoSuchElementException: Key 'statusBar' does not map to an
>> > existing object!
>> >   at
>> >
>> org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
>>
>> > ~[commons-configuration2-2.7.jar:2.7]
>> >   at
>> >
>> org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)
>>
>> > ~[commons-configuration2-2.7.jar:2.7]
>> >
>> > and the underlying cause is printed extra:
>> >
>> > java.util.NoSuchElementException: Key 'statusBar' does not map to an
>> > existing object!
>> >   at
>> >
>> org.apache.commons.configuration2.AbstractConfiguration.throwMissingPropertyException(AbstractConfiguration.java:1902)
>> >   at
>> >
>> org.apache.commons.configuration2.AbstractConfiguration.checkNonNullValue(AbstractConfiguration.java:1889)
>> >
>> >
>> > Either it is something special in the OpenJDK or maybe even related to
>> > the Mac. I assume you are on Windows. Could you try with another JDK,
>> > maybe Zulu or Correta?
>> >
>> >
>> >
>> >
>> >
>> > --
>> > The Apache Software Foundation
>> > V.P., Data Privacy
>> >
>> > On Fri, Sep 29, 2023, at 17:19, Robert Middleton wrote:
>> >> It starts up for me with Netbeans and OpenJDK 11.  I would expect an
>> >> exception/stack trace to be printed to stderr if an exception was thrown
>> >> that caused it to fail to load.
>> >>
>> >> -Robert Middleton
>> >>
>> >> On Fri, Sep 29, 2023 at 9:17 AM Christian Grobmeier <
>> grobme...@apache.org>
>> >> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> I have found out Chainsaw requires Java 11. I used this from IntelliJ
>> and
>> >>> run LogUI.
>> >>> However, even when there is no error message, the Splash Screen never
>> >>> disappears.
>> >>> Is there any specific verion of Java I need?
>> >>>
>> >>> These are he last lines i see:
>> >>>
>> >>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
>> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>> >>> org.apache.log4j.chainsaw.LogUI
>> >>> 15:15:29.580 [AWT-EventQueue-0] DEBUG
>> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel
>> >>> 15:15:29.581 [AWT-EventQueue-0] DEBUG
>> >>> org.apache.log4j.chainsaw.LogPanelLoggerTreeModel - Adding to Map
>> >>> org.apache.log4j.chainsaw.LoggerNameTreePanel
>> >>>
>> >>> Then no further actitivty,
>> >>>
>> >>> Any ideas?
>> >>>
>> >>> --
>> >>> The Apache Software Foundation
>> >>> V.P., Data Privacy
>> >>>
>>

[chainsaw] Is ZeroConf support relevant?

[Christian Grobmeier]

Volkan asked this question here:
https://github.com/apache/logging-chainsaw/issues/24

I guess, since Log4j1 is EOL we can safely remove this feature, right?

Re: [chainsaw] Is ZeroConf support relevant?

[Christian Grobmeier]

Oh wow I was sure this is log4j1 great, I even found some docs.
https://logging.apache.org/log4j/2.x/manual/configuration.html#chainsaw-can-automatically-process-your-log-files-advertising-ap

Thanks!

On Fri, Sep 29, 2023, at 21:40, Scott Deboy wrote:
> This is a log4j2 feature.
>
> Scott
>
> On Fri, Sep 29, 2023, 12:24 PM Christian Grobmeier 
> wrote:
>
>> Volkan asked this question here:
>> https://github.com/apache/logging-chainsaw/issues/24
>>
>> I guess, since Log4j1 is EOL we can safely remove this feature, right?
>>

Re: [VOTE] Release Apache Log4j Tools 0.5.0

[Christian Grobmeier]

+1



On Fri, Sep 29, 2023, at 13:13, Volkan Yazıcı wrote:
> This is a vote to release the Apache Log4j Tools 0.5.0.
>
> Source repository: https://github.com/apache/logging-log4j-tools
> Commit: 861b03c70a76ca19408ffc8c4a77bc0c4e5e4570
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-tools
> Nexus:
> https://repository.apache.org/content/repositories/orgapachelogging-1187
> Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
>
> Please download, test, and cast your votes on this mailing list.
>
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
>
> This vote is open for 72 hours and will pass unless getting a
> net negative vote count. All votes are welcome and we encourage
> everyone to test the release, but only the Logging Services PMC
> votes are officially counted. At least 3 +1 votes and more
> positive than negative votes are required.
>
> === Release Notes
>
> This minor release contains various bug fixes and improvements.
>
>  Added
>
> * Started publishing the project website[1]
>
> [1] https://logging.staged.apache.org/log4j/tools
>
>  Changed
>
> * Made `author` element optional and bumped the XML schema version to
> `0.1.2` (#81)
> * Make `log4j-changelog-maven-plugin` thread-safe (#80)
> * Update `org.apache.logging:logging-parent` to version `10.1.0` (#82)
> * Update `org.junit.jupiter:junit-jupiter-engine` to version `5.10.0`

[chainsaw] Lots of commented code // Backwards compatibility?

[Christian Grobmeier]

Hi,

Looking through the code base, I saw lots of code that is commented. Some 
classes (maybe because of this) are not even used anymore. I only saw one class 
(ChainsawViewer), which might make sense to keep.

Is it OK to remove this all? Or is there a specific reason for this?

Some methods are no longer used or empty despite not being commented. I would 
also like to remove them when they don't have any purpose. Since they are 
public, BC is no longer guaranteed. For a Standalone app like this, I don't 
consider this a problem, but I would like to know if there are any objections.

Kind regards,
Christian

[chainsaw] What is necessary for a 2.2 release?

[Christian Grobmeier]

Hello,

I am moving things around a lot. There is much refactoring that is necessary 
alone LogPanel had ~4500 lines of code. I believe this lot of LOCs is so 
complicated to understand that it prevents people from contributing - let alone 
Swing, but we can't change that.

Apart from usual refactorings, I wonder what should be the goal of 2.2?

I have already upgraded some dependencies that have security flaws. 2 more are 
in the pom, but they have no patched versions so far.

Should we add at least one feature? Is there maybe one already in that I missed?

I would appreciate it if one of the more experienced Swing-devs here could 
advise or maybe contribute some code so we can justify a release.

The next question would be:
How is chainsaw released at all?

Kind regards,
Christian

Re: [chainsaw] What is necessary for a 2.2 release?

[Christian Grobmeier]

On Sun, Oct 1, 2023, at 20:59, Scott Deboy wrote:
> It's great to see the contribution, thanks Christian!
>
> I pulled down latest master and it looks like there are some UI
> glitches we should fix - for example, resizing the logger tree pane
> doesn't render correctly.
>
> As I mentioned before, I assume there are a bunch of features we lost
> when we moved from log4j1 - some may not be critical, but I think
> persisting 'default' tab settings is pretty important if it's not
>
> I'd like us to at least support the log4j2 zeroconf functionality as
> well as VFSLogFilePatternReceiver.
>
> I'm happy to dig in - will look at latest master and contribute.

I would be more than glad if you could take some kind of a lead here. My 
Swing-foo is long time gone and so far I just tried to clean a few things or 
make the code more comprehensible. 

I will keep trying to extracting things, making classes a bit smaller if 
possible. I will closely follow what you are doing and try to learn from it.

Maybe, once we can persist tab settings and then release it, no matter how the 
rest of the cleanup is.


>
> Scott
>
> On 10/1/23, Christian Grobmeier  wrote:
>> Hello,
>>
>> I am moving things around a lot. There is much refactoring that is necessary
>> alone LogPanel had ~4500 lines of code. I believe this lot of LOCs is so
>> complicated to understand that it prevents people from contributing - let
>> alone Swing, but we can't change that.
>>
>> Apart from usual refactorings, I wonder what should be the goal of 2.2?
>>
>> I have already upgraded some dependencies that have security flaws. 2 more
>> are in the pom, but they have no patched versions so far.
>>
>> Should we add at least one feature? Is there maybe one already in that I
>> missed?
>>
>> I would appreciate it if one of the more experienced Swing-devs here could
>> advise or maybe contribute some code so we can justify a release.
>>
>> The next question would be:
>> How is chainsaw released at all?
>>
>> Kind regards,
>> Christian
>>

Re: [chainsaw] What is necessary for a 2.2 release?

[Christian Grobmeier]

On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote:
> The ability to route events to tabs is a core feature in the code -
> that's how Chainsaw log messages end up in a Chainsaw-specific tab -
> but the ability to control that routing via a 'routing expression' was
> nuked from app-wide preferences - another thing we should bring back.
>
> It looks like we lost a lot of prefs, both panel-level and app-wide prefs.

Yes, I think all prefs are somehow gone. At least everything that is writes to 
a file seems to be commented.
I didn't remove those things yet, as they seemed to big and I didn't understand 
well how they'd work or how I would test (I lack the knowledge of how the UI 
should operate but only see what is there now)


>
> Scott
>
> On 10/1/23, Robert Middleton  wrote:
>> I would say the saving/loading of settings is probably the main thing to
>> fix - if I remember correctly, it kinda works at the moment.  Part of the
>> issue with what it did before was that the settings were scattered among
>> several different files with no apparent rhyme or reason, and converting
>> them to one file I'm not sure if everything works.
>>
>> The one feature that I'm pretty sure doesn't exist is the ability to have
>> multiple log messages go to one tab, but I don't think that is critical for
>> release.  In order to properly support that I think requires a bit more
>> planning on both the UI side(so you can know how things are routed) and on
>> the back-end side(to do the actual routing).
>>
>> -Robert Middleton
>>
>> On Sun, Oct 1, 2023 at 3:14 PM Christian Grobmeier 
>> wrote:
>>
>>> On Sun, Oct 1, 2023, at 20:59, Scott Deboy wrote:
>>> > It's great to see the contribution, thanks Christian!
>>> >
>>> > I pulled down latest master and it looks like there are some UI
>>> > glitches we should fix - for example, resizing the logger tree pane
>>> > doesn't render correctly.
>>> >
>>> > As I mentioned before, I assume there are a bunch of features we lost
>>> > when we moved from log4j1 - some may not be critical, but I think
>>> > persisting 'default' tab settings is pretty important if it's not
>>> >
>>> > I'd like us to at least support the log4j2 zeroconf functionality as
>>> > well as VFSLogFilePatternReceiver.
>>> >
>>> > I'm happy to dig in - will look at latest master and contribute.
>>>
>>> I would be more than glad if you could take some kind of a lead here. My
>>> Swing-foo is long time gone and so far I just tried to clean a few things
>>> or make the code more comprehensible.
>>>
>>> I will keep trying to extracting things, making classes a bit smaller if
>>> possible. I will closely follow what you are doing and try to learn from
>>> it.
>>>
>>> Maybe, once we can persist tab settings and then release it, no matter
>>> how
>>> the rest of the cleanup is.
>>>
>>>
>>> >
>>> > Scott
>>> >
>>> > On 10/1/23, Christian Grobmeier  wrote:
>>> >> Hello,
>>> >>
>>> >> I am moving things around a lot. There is much refactoring that is
>>> necessary
>>> >> alone LogPanel had ~4500 lines of code. I believe this lot of LOCs is
>>> >> so
>>> >> complicated to understand that it prevents people from contributing -
>>> let
>>> >> alone Swing, but we can't change that.
>>> >>
>>> >> Apart from usual refactorings, I wonder what should be the goal of
>>> >> 2.2?
>>> >>
>>> >> I have already upgraded some dependencies that have security flaws. 2
>>> more
>>> >> are in the pom, but they have no patched versions so far.
>>> >>
>>> >> Should we add at least one feature? Is there maybe one already in that
>>> >> I
>>> >> missed?
>>> >>
>>> >> I would appreciate it if one of the more experienced Swing-devs here
>>> could
>>> >> advise or maybe contribute some code so we can justify a release.
>>> >>
>>> >> The next question would be:
>>> >> How is chainsaw released at all?
>>> >>
>>> >> Kind regards,
>>> >> Christian
>>> >>
>>>
>>

Re: [chainsaw] What is necessary for a 2.2 release?

[Christian Grobmeier]

On Sun, Oct 1, 2023, at 22:09, Scott Deboy wrote:
> I pushed branch "chainsaw-with-log4j1-dep" representing the working
> log4j1 code for those that want to easily see what used to exist.
>
> I'll probably selectively incorporate pieces from that branch into master.

I think thats a great idea. I will be very busy for the next week, so I am not 
going to make many changes then.
However, when I return I plan to work further on the LogPanel and cut it into 
pieces, so it is (hopefully) easier to maintain.

Kind regards,
Christian

>
> On 10/1/23, Christian Grobmeier  wrote:
>>
>> On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote:
>>> The ability to route events to tabs is a core feature in the code -
>>> that's how Chainsaw log messages end up in a Chainsaw-specific tab -
>>> but the ability to control that routing via a 'routing expression' was
>>> nuked from app-wide preferences - another thing we should bring back.
>>>
>>> It looks like we lost a lot of prefs, both panel-level and app-wide
>>> prefs.
>>
>> Yes, I think all prefs are somehow gone. At least everything that is writes
>> to a file seems to be commented.
>> I didn't remove those things yet, as they seemed to big and I didn't
>> understand well how they'd work or how I would test (I lack the knowledge of
>> how the UI should operate but only see what is there now)
>>
>>
>>>
>>> Scott
>>>
>>> On 10/1/23, Robert Middleton  wrote:
>>>> I would say the saving/loading of settings is probably the main thing to
>>>> fix - if I remember correctly, it kinda works at the moment.  Part of
>>>> the
>>>> issue with what it did before was that the settings were scattered among
>>>> several different files with no apparent rhyme or reason, and converting
>>>> them to one file I'm not sure if everything works.
>>>>
>>>> The one feature that I'm pretty sure doesn't exist is the ability to
>>>> have
>>>> multiple log messages go to one tab, but I don't think that is critical
>>>> for
>>>> release.  In order to properly support that I think requires a bit more
>>>> planning on both the UI side(so you can know how things are routed) and
>>>> on
>>>> the back-end side(to do the actual routing).
>>>>
>>>> -Robert Middleton
>>>>
>>>> On Sun, Oct 1, 2023 at 3:14 PM Christian Grobmeier
>>>> 
>>>> wrote:
>>>>
>>>>> On Sun, Oct 1, 2023, at 20:59, Scott Deboy wrote:
>>>>> > It's great to see the contribution, thanks Christian!
>>>>> >
>>>>> > I pulled down latest master and it looks like there are some UI
>>>>> > glitches we should fix - for example, resizing the logger tree pane
>>>>> > doesn't render correctly.
>>>>> >
>>>>> > As I mentioned before, I assume there are a bunch of features we lost
>>>>> > when we moved from log4j1 - some may not be critical, but I think
>>>>> > persisting 'default' tab settings is pretty important if it's not
>>>>> >
>>>>> > I'd like us to at least support the log4j2 zeroconf functionality as
>>>>> > well as VFSLogFilePatternReceiver.
>>>>> >
>>>>> > I'm happy to dig in - will look at latest master and contribute.
>>>>>
>>>>> I would be more than glad if you could take some kind of a lead here.
>>>>> My
>>>>> Swing-foo is long time gone and so far I just tried to clean a few
>>>>> things
>>>>> or make the code more comprehensible.
>>>>>
>>>>> I will keep trying to extracting things, making classes a bit smaller
>>>>> if
>>>>> possible. I will closely follow what you are doing and try to learn
>>>>> from
>>>>> it.
>>>>>
>>>>> Maybe, once we can persist tab settings and then release it, no matter
>>>>> how
>>>>> the rest of the cleanup is.
>>>>>
>>>>>
>>>>> >
>>>>> > Scott
>>>>> >
>>>>> > On 10/1/23, Christian Grobmeier  wrote:
>>>>> >> Hello,
>>>>> >>
>>>>> >> I am moving things around a lot. There is much refactoring that is
>>>>> necessary
>>>>> >> alone LogPanel had ~4500 lines of code. I believe this lot of LOCs
>>>>> >> is
>>>>> >> so
>>>>> >> complicated to understand that it prevents people from contributing
>>>>> >> -
>>>>> let
>>>>> >> alone Swing, but we can't change that.
>>>>> >>
>>>>> >> Apart from usual refactorings, I wonder what should be the goal of
>>>>> >> 2.2?
>>>>> >>
>>>>> >> I have already upgraded some dependencies that have security flaws.
>>>>> >> 2
>>>>> more
>>>>> >> are in the pom, but they have no patched versions so far.
>>>>> >>
>>>>> >> Should we add at least one feature? Is there maybe one already in
>>>>> >> that
>>>>> >> I
>>>>> >> missed?
>>>>> >>
>>>>> >> I would appreciate it if one of the more experienced Swing-devs here
>>>>> could
>>>>> >> advise or maybe contribute some code so we can justify a release.
>>>>> >>
>>>>> >> The next question would be:
>>>>> >> How is chainsaw released at all?
>>>>> >>
>>>>> >> Kind regards,
>>>>> >> Christian
>>>>> >>
>>>>>
>>>>
>>

Re: [chainsaw] What is necessary for a 2.2 release?

[Christian Grobmeier]

On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote:
> Some(most?) of the settings should be saved:
> https://github.com/apache/logging-chainsaw/blob/5ccb3c8e55dffd4361c549c3bcdac3f3675f79e5/src/main/java/org/apache/log4j/chainsaw/prefs/SettingsManager.java#L191
>
> The stuff that is commented out should just be the old saving code that
> used XStream to save the data out.

You made it using this commit (thank you, its easy to track):
https://github.com/apache/logging-chainsaw/commit/75bedf98665188eef4d13e4bfbb4b0dae456f65e

One question: why did we remove Xstream? it seem there was an update late 2022 
to address some security.
Should we just re-enable it or was there other reasons too?




>
> -Robert Middleton
>
> On Sun, Oct 1, 2023 at 3:39 PM Christian Grobmeier 
> wrote:
>
>>
>> On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote:
>> > The ability to route events to tabs is a core feature in the code -
>> > that's how Chainsaw log messages end up in a Chainsaw-specific tab -
>> > but the ability to control that routing via a 'routing expression' was
>> > nuked from app-wide preferences - another thing we should bring back.
>> >
>> > It looks like we lost a lot of prefs, both panel-level and app-wide
>> prefs.
>>
>> Yes, I think all prefs are somehow gone. At least everything that is
>> writes to a file seems to be commented.
>> I didn't remove those things yet, as they seemed to big and I didn't
>> understand well how they'd work or how I would test (I lack the knowledge
>> of how the UI should operate but only see what is there now)
>>
>>
>> >
>> > Scott
>> >
>> > On 10/1/23, Robert Middleton  wrote:
>> >> I would say the saving/loading of settings is probably the main thing to
>> >> fix - if I remember correctly, it kinda works at the moment.  Part of
>> the
>> >> issue with what it did before was that the settings were scattered among
>> >> several different files with no apparent rhyme or reason, and converting
>> >> them to one file I'm not sure if everything works.
>> >>
>> >> The one feature that I'm pretty sure doesn't exist is the ability to
>> have
>> >> multiple log messages go to one tab, but I don't think that is critical
>> for
>> >> release.  In order to properly support that I think requires a bit more
>> >> planning on both the UI side(so you can know how things are routed) and
>> on
>> >> the back-end side(to do the actual routing).
>> >>
>> >> -Robert Middleton
>> >>
>> >> On Sun, Oct 1, 2023 at 3:14 PM Christian Grobmeier <
>> grobme...@apache.org>
>> >> wrote:
>> >>
>> >>> On Sun, Oct 1, 2023, at 20:59, Scott Deboy wrote:
>> >>> > It's great to see the contribution, thanks Christian!
>> >>> >
>> >>> > I pulled down latest master and it looks like there are some UI
>> >>> > glitches we should fix - for example, resizing the logger tree pane
>> >>> > doesn't render correctly.
>> >>> >
>> >>> > As I mentioned before, I assume there are a bunch of features we lost
>> >>> > when we moved from log4j1 - some may not be critical, but I think
>> >>> > persisting 'default' tab settings is pretty important if it's not
>> >>> >
>> >>> > I'd like us to at least support the log4j2 zeroconf functionality as
>> >>> > well as VFSLogFilePatternReceiver.
>> >>> >
>> >>> > I'm happy to dig in - will look at latest master and contribute.
>> >>>
>> >>> I would be more than glad if you could take some kind of a lead here.
>> My
>> >>> Swing-foo is long time gone and so far I just tried to clean a few
>> things
>> >>> or make the code more comprehensible.
>> >>>
>> >>> I will keep trying to extracting things, making classes a bit smaller
>> if
>> >>> possible. I will closely follow what you are doing and try to learn
>> from
>> >>> it.
>> >>>
>> >>> Maybe, once we can persist tab settings and then release it, no matter
>> >>> how
>> >>> the rest of the cleanup is.
>> >>>
>> >>>
>> >>> >
>> >>> > Scott
>> >>> >
>> >>> > On 10/1/23, C

Re: Refining product feature set strategy

[Christian Grobmeier]

Hi

On Sat, Sep 30, 2023, at 00:52, Ralph Goers wrote:
> Requiring hoops that must be jumped through before stuff can be 
> accepted is just a terrible idea. It does nothing but create a 
> perception that we are not open to new contributions and new 
> contributors.

I am also against hoops, but all for letting the users know how maintained (or 
not) a component is. We can accept everything, but first it goes too sandbox. 
It is the only sand thing to do.

Because we didn’t do this, we had log4shell. We accepted a feature long time 
ago that nobody ever really used and forgot about it.

We should at least tell the user what is maintained and what not.

Sandbox, dormant and stable are not hoops but communication about the health of 
a component.

> In short, I am in favor of retiring things when they are no longer 
> maintainable. 

This is very hard. As you know, I look into chainsaw right now. I believe it is 
currently not in a good state. It’s hard to read, technology is outdated 
(swing). Before I started, I would have said it is no longer maintainable. Now 
I still think the same, but with a lot of effort it could become maintainable 
again. Even log4j1 could be maintainable with a lot of people power. Following 
this, nothing would be ever retired.

The better metric is: do we have the time to maintain it. If nobody is around 
who feels responsible a component could go to dormant indicating the state.

> I am completely in favor of adding new components when 
> they make sense. IOW, every contribution needs to be considered on its 
> own merits.

Agreed. Sandbox could be open even for all ASF committers, entry barriers could 
be low. Dormant components could go back to sandbox as well, if new people want 
to work on it.

Christian 

>
> Ralph
>
>
>
>> On Sep 29, 2023, at 11:32 AM, Gary Gregory  wrote:
>> 
>> I think Jira is good enough for that, since there is transition from state
>> to state that can be used to shepherd issues through. RFC, JEP, all way too
>> heavy handed for us IMO.
>> 
>> Gary
>> 
>> 
>> On Fri, Sep 29, 2023, 2:05 PM Matt Sicker  wrote:
>> 
>>> I think it could be valuable for us to establish some form of an RFC
>>> process for proposing and developing major new features. I also want to
>>> avoid being too process-heavy here as that would also disincentivize
>>> contributions. I agree that we should try to be more data-driven to
>>> determine what features and products should have the most attention.
>>> 
>>> I do like the idea of having “sample” plugins which are not distributed as
>>> binaries, though, which can be used in documentation for examples of how to
>>> integrate your own systems. With the flexibility of the plugin system here,
>>> we can defer the implementation of more obscure integrations to the end
>>> user.
>>> 
>>> I will note that we do already have some level of filtering to what we
>>> include. I’ve proposed numerous features in the past that I didn’t pursue
>>> due to reasons raised by others or lack of interest.
>>> 
 On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı  wrote:
 
 I want to challenge the current way of PMC determining the product
>>> feature
 set and work towards a more sustainable alternative.
 
 Logging Services team...
 
  - delivers mission-critical products that are deployed at the core of
  the world-wide infrastructure (actually, in Mars too)
  - is short on development resources compared to its wide range of
  offerings
  - deals with substantial amount of legacy
  - suffers from knowledge silo
 
 Any IT team in this state would be really conservative on accepting new
 features and try hard to get rid of the bloat. They would react to this
 challenge by first discovering the user base, pinpointing the core
>>> values,
 and then lazer-focusing the limited development resources on to the
>>> crucial
 deliverables. Though we do something totally different, one can even say
 the opposite. Below I share excerpts from recent mailing list posts.
 
 *"I had added [X] ... to show how to write plugins and for some
 consulting-related use cases"* – PMC member explaining how feature X was
 released
 
 *"... stuff seems like it could be useful"* – PMC member asking to keep
 feature X
 
 *"my employer used [X] ... for anyone implementing ... this would be very
 relevant.  By archiving this we are basically telling users that they
 cannot use it any more since it will no longer be supported. For that
 reason I am not in favor of [retiring]"* – PMC member asking to keep
 feature X
 
 *"We [the employer] ... use [X]"* – PMC member asking to keep feature X
 
 *"User base [is] ... very low to non-existent."* – PMC member asking to
 keep product X
 
 *"[PMC member] has steadfastly [reacted] ... and until he positively says
 he will no longer maintain it I am not willing to override that"* – PMC

Re: [chainsaw] What is necessary for a 2.2 release?

[Christian Grobmeier]

On Mon, Oct 2, 2023, at 16:15, Robert Middleton wrote:
> At least two reasons I can think of:
> 1. Xstream doesn’t work on all java versions as you saw
> 2. Simplify by using the commons config instead of rolling our own.
>
> Each tab should now have just one config file, the idea being that you can
> now share config files between people.  Before each tab had at least
> two(maybe three) files.  One was the xml config, one was a java serialized
> map.  Removing the java serialization is important.

OK. Do you think something based on Jackson would be good? It's JSON though.

>From an example:

ObjectMapper objectMapper = new ObjectMapper();
Car car = new Car("yellow", "renault");
objectMapper.writeValue(new File("target/car.json"), car);

We could wrap this in some kind of class and make it accessible per "tab" (or 
whatever).


>
> -Robert Middleton
>
> On Mon, Oct 2, 2023 at 6:12 AM Christian Grobmeier 
> wrote:
>
>>
>> On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote:
>> > Some(most?) of the settings should be saved:
>> >
>> https://github.com/apache/logging-chainsaw/blob/5ccb3c8e55dffd4361c549c3bcdac3f3675f79e5/src/main/java/org/apache/log4j/chainsaw/prefs/SettingsManager.java#L191
>> >
>> > The stuff that is commented out should just be the old saving code that
>> > used XStream to save the data out.
>>
>> You made it using this commit (thank you, its easy to track):
>>
>> https://github.com/apache/logging-chainsaw/commit/75bedf98665188eef4d13e4bfbb4b0dae456f65e
>>
>> One question: why did we remove Xstream? it seem there was an update late
>> 2022 to address some security.
>> Should we just re-enable it or was there other reasons too?
>>
>>
>>
>>
>> >
>> > -Robert Middleton
>> >
>> > On Sun, Oct 1, 2023 at 3:39 PM Christian Grobmeier > >
>> > wrote:
>> >
>> >>
>> >> On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote:
>> >> > The ability to route events to tabs is a core feature in the code -
>> >> > that's how Chainsaw log messages end up in a Chainsaw-specific tab -
>> >> > but the ability to control that routing via a 'routing expression' was
>> >> > nuked from app-wide preferences - another thing we should bring back.
>> >> >
>> >> > It looks like we lost a lot of prefs, both panel-level and app-wide
>> >> prefs.
>> >>
>> >> Yes, I think all prefs are somehow gone. At least everything that is
>> >> writes to a file seems to be commented.
>> >> I didn't remove those things yet, as they seemed to big and I didn't
>> >> understand well how they'd work or how I would test (I lack the
>> knowledge
>> >> of how the UI should operate but only see what is there now)
>> >>
>> >>
>> >> >
>> >> > Scott
>> >> >
>> >> > On 10/1/23, Robert Middleton  wrote:
>> >> >> I would say the saving/loading of settings is probably the main
>> thing to
>> >> >> fix - if I remember correctly, it kinda works at the moment.  Part of
>> >> the
>> >> >> issue with what it did before was that the settings were scattered
>> among
>> >> >> several different files with no apparent rhyme or reason, and
>> converting
>> >> >> them to one file I'm not sure if everything works.
>> >> >>
>> >> >> The one feature that I'm pretty sure doesn't exist is the ability to
>> >> have
>> >> >> multiple log messages go to one tab, but I don't think that is
>> critical
>> >> for
>> >> >> release.  In order to properly support that I think requires a bit
>> more
>> >> >> planning on both the UI side(so you can know how things are routed)
>> and
>> >> on
>> >> >> the back-end side(to do the actual routing).
>> >> >>
>> >> >> -Robert Middleton
>> >> >>
>> >> >> On Sun, Oct 1, 2023 at 3:14 PM Christian Grobmeier <
>> >> grobme...@apache.org>
>> >> >> wrote:
>> >> >>
>> >> >>> On Sun, Oct 1, 2023, at 20:59, Scott Deboy wrote:
>> >> >>> > It's great to see the contribution, thanks Christian!
>> >> >>> >
>> >> >>> > I pulled down latest mas

Re: [chainsaw] What is necessary for a 2.2 release?

[Christian Grobmeier]

On Mon, Oct 2, 2023, at 20:58, Scott Deboy wrote:
> I'm working to restore all the menu items that were nuked, and the
> prior LogUI/LogPanel functionality allowing config import.
>
> It's a big task, and will likely result in some of the recent
> LogUI/LogPanel refactoring being reverted, but will do what I can to
> minimize the impact.

Of course, I can re-refactor later ;-)
Looking forward to it, feel free to revert whatever you think is 
necessary/makes your life easier


>
> Scott
>
> On 10/2/23, Christian Grobmeier  wrote:
>> On Mon, Oct 2, 2023, at 16:15, Robert Middleton wrote:
>>> At least two reasons I can think of:
>>> 1. Xstream doesn’t work on all java versions as you saw
>>> 2. Simplify by using the commons config instead of rolling our own.
>>>
>>> Each tab should now have just one config file, the idea being that you
>>> can
>>> now share config files between people.  Before each tab had at least
>>> two(maybe three) files.  One was the xml config, one was a java
>>> serialized
>>> map.  Removing the java serialization is important.
>>
>> OK. Do you think something based on Jackson would be good? It's JSON
>> though.
>>
>> From an example:
>>
>> ObjectMapper objectMapper = new ObjectMapper();
>> Car car = new Car("yellow", "renault");
>> objectMapper.writeValue(new File("target/car.json"), car);
>>
>> We could wrap this in some kind of class and make it accessible per "tab"
>> (or whatever).
>>
>>
>>>
>>> -Robert Middleton
>>>
>>> On Mon, Oct 2, 2023 at 6:12 AM Christian Grobmeier 
>>> wrote:
>>>
>>>>
>>>> On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote:
>>>> > Some(most?) of the settings should be saved:
>>>> >
>>>> https://github.com/apache/logging-chainsaw/blob/5ccb3c8e55dffd4361c549c3bcdac3f3675f79e5/src/main/java/org/apache/log4j/chainsaw/prefs/SettingsManager.java#L191
>>>> >
>>>> > The stuff that is commented out should just be the old saving code
>>>> > that
>>>> > used XStream to save the data out.
>>>>
>>>> You made it using this commit (thank you, its easy to track):
>>>>
>>>> https://github.com/apache/logging-chainsaw/commit/75bedf98665188eef4d13e4bfbb4b0dae456f65e
>>>>
>>>> One question: why did we remove Xstream? it seem there was an update
>>>> late
>>>> 2022 to address some security.
>>>> Should we just re-enable it or was there other reasons too?
>>>>
>>>>
>>>>
>>>>
>>>> >
>>>> > -Robert Middleton
>>>> >
>>>> > On Sun, Oct 1, 2023 at 3:39 PM Christian Grobmeier
>>>> > >>> >
>>>> > wrote:
>>>> >
>>>> >>
>>>> >> On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote:
>>>> >> > The ability to route events to tabs is a core feature in the code -
>>>> >> > that's how Chainsaw log messages end up in a Chainsaw-specific tab
>>>> >> > -
>>>> >> > but the ability to control that routing via a 'routing expression'
>>>> >> > was
>>>> >> > nuked from app-wide preferences - another thing we should bring
>>>> >> > back.
>>>> >> >
>>>> >> > It looks like we lost a lot of prefs, both panel-level and app-wide
>>>> >> prefs.
>>>> >>
>>>> >> Yes, I think all prefs are somehow gone. At least everything that is
>>>> >> writes to a file seems to be commented.
>>>> >> I didn't remove those things yet, as they seemed to big and I didn't
>>>> >> understand well how they'd work or how I would test (I lack the
>>>> knowledge
>>>> >> of how the UI should operate but only see what is there now)
>>>> >>
>>>> >>
>>>> >> >
>>>> >> > Scott
>>>> >> >
>>>> >> > On 10/1/23, Robert Middleton  wrote:
>>>> >> >> I would say the saving/loading of settings is probably the main
>>>> thing to
>>>> >> >> fix - if I remember correctly, it kinda works at the moment.  Part
>>>> >> >> of
>>>> >> the
>&

Re: Refining product feature set strategy

[Christian Grobmeier]

On Mon, Oct 2, 2023, at 17:38, Ralph Goers wrote:

>>> Agreed. Sandbox could be open even for all ASF committers, entry barriers 
>>> could be low. Dormant components could go back to sandbox as well, if new 
>>> people want to work on it.
>> 
>> Can we create a repo open to all Apache committers? If yes, let's
>> create a `logging-sandbox` repo right now.
>
> I don’t believe we can. Commons will make any ASF member a committer if 
> they ask. I don’t recall if that applies to any ASF committer as well. 
> It might.

I asked Infra, it is possible to create a repository that is public and 
read/write to all committers

Kind regards,
Christian

[proposal] Create sandbox, open to all committers

[Christian Grobmeier]

Hi,

I want to create a sandbox for experimental logging features and ideas. All ASF 
committers should be welcome to contribute and have access by default.

Everybody can add their custom extensions to it and develop it further. We 
would collect code bases from all over the eco system on a central base, making 
it easier to find interesting pieces of code that you can reuse.

This sandbox can also serve as a place were "dormant" components can be revived.

The sandbox needs to indicate to the users that these components are "used on 
on risk".

I am hesitating making this an official vote, since some of us may not have 
seen this proposal buried in the other threads. However, if there is no 
negative response to this thread, I will move forward and request a git 
repository for this purpose since it is not critical.

Kind regards,
Christian

Re: [log4j] LOG4J2-3669 Scala API license

[Christian Grobmeier]

No idea about the origin,
but our repo shows:
https://github.com/search?q=repo%3Aapache%2Flogging-log4j-scala%20%20typesafehub%2Fscalalogging&type=code

The repo here:
https://github.com/typesafehub/scalalogging

Points to:
https://github.com/lightbend-labs/scala-logging

I can see that the very old version of the old repo has some authors that also 
the new repo has:
https://github.com/lightbend-labs/scala-logging/commits/0057744a001c5757f5f6976c37ea6743ceace2d8/src/main/scala/com/typesafe/scalalogging/LoggerMacro.scala?browsing_rename_history=true&new_path=src/main/scala-2/com/typesafe/scalalogging/LoggerMacro.scala&original_branch=main
(Heiko)

So I assume, but I do not know, that it would be safe to update this reference

Kind regards,
Christian


On Wed, Oct 4, 2023, at 20:07, Matt Sicker wrote:
> I’m not sure which parts of the code are inspired by the other library. 
> I mostly worked on the build files :)
>
>> On Oct 4, 2023, at 2:02 AM, Volkan Yazıcı  wrote:
>> 
>> PJ states in LOG4J2-3669 
>> that the NOTICE file should contain reference to Typesafe/Lightbend for
>> "inspired code". Could somebody (Matt?) help there, please?

Re: [log4j] Improving log4j security

[Christian Grobmeier]

Hello Vladimir,

I am not sure if you received Piotrs message below - please let us know :)

Kind regards,
Christian

--
The Apache Software Foundation
V.P., Data Privacy

On Thu, Oct 5, 2023, at 22:05, Piotr P. Karwasz wrote:
> Hi Vladimir,
>
> On Thu, 5 Oct 2023 at 21:47, Klebanov, Vladimir
>  wrote:
>> I would like to contribute some code in order to make log4j usage more 
>> secure. I have now sent two emails to the log4j security team but did not 
>> receive a response. Is anybody here interested? How can we discuss this 
>> further?
>
> Both times (10 Aug 2023, 23:19 and 29 Aug 2023, 20:49) we sent an
> answer to your address at sap.com.
>
> Anyway the general consensus was that the issue with generating HTML
> using PatternLayout does not constitute a security problem and you can
> discuss it on this mailing list or file an issue in Github issues.
>
> Piotr

Re: [chainsaw] What is necessary for a 2.2 release?

[Christian Grobmeier]

geson seems to do a good job, like Jackson (same JSR). 
I'd like to move forward with JSON format for storing properties. 

I am not sure what the status currently is, if Scott is still working on it :) 
I could also make some kind of proposal or so for storing properties 

On Tue, Oct 3, 2023, at 01:20, Scott Deboy wrote:
> I think persisting to json format makes sense/would be easy to consume
> with tools if needed.
>
> On 10/2/23, Robert Middleton  wrote:
>>> OK. Do you think something based on Jackson would be good? It's JSON
>>> though.
>>
>> We already have a dependency on genson for JSON parsing, so if we
>> really want to use JSON that would make the most sense.  Commons
>> config can read/write XML; currently I just have it configured to do
>> properties files.  I think we can write our own reader/writer as well,
>> but ultimately I don't think that there is anything special that we
>> need that commons config doesn't provide us out of the box.
>>
>> -Robert Middleton
>>
>> On Mon, Oct 2, 2023 at 5:14 PM Matt Sicker  wrote:
>>>
>>> Jackson makes for a good library here because it also supports several
>>> data formats (YAML, XML, HOCON, and all sorts of others, both textual and
>>> binary) and is fairly extensible for hooking any custom serialization or
>>> deserialization logic you need. Given the desire to avoid Java
>>> serialization, it is perfectly reasonable to avoid XStream as that’s
>>> basically Java serialization using XML with all the pitfalls that entails
>>> (I dealt with this fairly extensively back in the Jenkins project which
>>> used an old fork of XStream for managing config files and state).
>>>
>>> I haven’t used Commons Configuration before, but it seems fairly
>>> appropriate for this sort of thing as well.
>>>
>>> > On Oct 2, 2023, at 1:43 PM, Christian Grobmeier 
>>> > wrote:
>>> >
>>> > On Mon, Oct 2, 2023, at 16:15, Robert Middleton wrote:
>>> >> At least two reasons I can think of:
>>> >> 1. Xstream doesn’t work on all java versions as you saw
>>> >> 2. Simplify by using the commons config instead of rolling our own.
>>> >>
>>> >> Each tab should now have just one config file, the idea being that you
>>> >> can
>>> >> now share config files between people.  Before each tab had at least
>>> >> two(maybe three) files.  One was the xml config, one was a java
>>> >> serialized
>>> >> map.  Removing the java serialization is important.
>>> >
>>> > OK. Do you think something based on Jackson would be good? It's JSON
>>> > though.
>>> >
>>> > From an example:
>>> >
>>> > ObjectMapper objectMapper = new ObjectMapper();
>>> > Car car = new Car("yellow", "renault");
>>> > objectMapper.writeValue(new File("target/car.json"), car);
>>> >
>>> > We could wrap this in some kind of class and make it accessible per
>>> > "tab" (or whatever).
>>> >
>>> >
>>> >>
>>> >> -Robert Middleton
>>> >>
>>> >> On Mon, Oct 2, 2023 at 6:12 AM Christian Grobmeier
>>> >> 
>>> >> wrote:
>>> >>
>>> >>>
>>> >>> On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote:
>>> >>>> Some(most?) of the settings should be saved:
>>> >>>>
>>> >>> https://github.com/apache/logging-chainsaw/blob/5ccb3c8e55dffd4361c549c3bcdac3f3675f79e5/src/main/java/org/apache/log4j/chainsaw/prefs/SettingsManager.java#L191
>>> >>>>
>>> >>>> The stuff that is commented out should just be the old saving code
>>> >>>> that
>>> >>>> used XStream to save the data out.
>>> >>>
>>> >>> You made it using this commit (thank you, its easy to track):
>>> >>>
>>> >>> https://github.com/apache/logging-chainsaw/commit/75bedf98665188eef4d13e4bfbb4b0dae456f65e
>>> >>>
>>> >>> One question: why did we remove Xstream? it seem there was an update
>>> >>> late
>>> >>> 2022 to address some security.
>>> >>> Should we just re-enable it or was there other reasons too?
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >

[all] Sonarcloud

[Christian Grobmeier]

Hi,

I added a fork of Chainsaw to Sonarcloud, which I find very helpful:
https://sonarcloud.io/summary/overall?id=grobmeier_logging-chainsaw

I asked Infra, and they would add projects by request to Sonarcloud. 

If you are interested, I'd like to add that to our repos.
If not, it is fine because I can run this locally and using my fork - nothing 
critical to have.

Let me know :)

Kind regards,
Christian

Re: [chainsaw] What is necessary for a 2.2 release?

[Christian Grobmeier]

On Sun, Oct 8, 2023, at 23:19, Scott Deboy wrote:
> I started but haven't had much time this week. The UI updates driven by
> settings changes are most of what I have left.

OK great to hear, in that case I hold myself back a little longer :)

Thanks!

>
> On Sun, Oct 8, 2023, 2:17 PM Christian Grobmeier 
> wrote:
>
>> geson seems to do a good job, like Jackson (same JSR).
>> I'd like to move forward with JSON format for storing properties.
>>
>> I am not sure what the status currently is, if Scott is still working on
>> it :) I could also make some kind of proposal or so for storing properties
>>
>> On Tue, Oct 3, 2023, at 01:20, Scott Deboy wrote:
>> > I think persisting to json format makes sense/would be easy to consume
>> > with tools if needed.
>> >
>> > On 10/2/23, Robert Middleton  wrote:
>> >>> OK. Do you think something based on Jackson would be good? It's JSON
>> >>> though.
>> >>
>> >> We already have a dependency on genson for JSON parsing, so if we
>> >> really want to use JSON that would make the most sense.  Commons
>> >> config can read/write XML; currently I just have it configured to do
>> >> properties files.  I think we can write our own reader/writer as well,
>> >> but ultimately I don't think that there is anything special that we
>> >> need that commons config doesn't provide us out of the box.
>> >>
>> >> -Robert Middleton
>> >>
>> >> On Mon, Oct 2, 2023 at 5:14 PM Matt Sicker  wrote:
>> >>>
>> >>> Jackson makes for a good library here because it also supports several
>> >>> data formats (YAML, XML, HOCON, and all sorts of others, both textual
>> and
>> >>> binary) and is fairly extensible for hooking any custom serialization
>> or
>> >>> deserialization logic you need. Given the desire to avoid Java
>> >>> serialization, it is perfectly reasonable to avoid XStream as that’s
>> >>> basically Java serialization using XML with all the pitfalls that
>> entails
>> >>> (I dealt with this fairly extensively back in the Jenkins project which
>> >>> used an old fork of XStream for managing config files and state).
>> >>>
>> >>> I haven’t used Commons Configuration before, but it seems fairly
>> >>> appropriate for this sort of thing as well.
>> >>>
>> >>> > On Oct 2, 2023, at 1:43 PM, Christian Grobmeier <
>> grobme...@apache.org>
>> >>> > wrote:
>> >>> >
>> >>> > On Mon, Oct 2, 2023, at 16:15, Robert Middleton wrote:
>> >>> >> At least two reasons I can think of:
>> >>> >> 1. Xstream doesn’t work on all java versions as you saw
>> >>> >> 2. Simplify by using the commons config instead of rolling our own.
>> >>> >>
>> >>> >> Each tab should now have just one config file, the idea being that
>> you
>> >>> >> can
>> >>> >> now share config files between people.  Before each tab had at least
>> >>> >> two(maybe three) files.  One was the xml config, one was a java
>> >>> >> serialized
>> >>> >> map.  Removing the java serialization is important.
>> >>> >
>> >>> > OK. Do you think something based on Jackson would be good? It's JSON
>> >>> > though.
>> >>> >
>> >>> > From an example:
>> >>> >
>> >>> > ObjectMapper objectMapper = new ObjectMapper();
>> >>> > Car car = new Car("yellow", "renault");
>> >>> > objectMapper.writeValue(new File("target/car.json"), car);
>> >>> >
>> >>> > We could wrap this in some kind of class and make it accessible per
>> >>> > "tab" (or whatever).
>> >>> >
>> >>> >
>> >>> >>
>> >>> >> -Robert Middleton
>> >>> >>
>> >>> >> On Mon, Oct 2, 2023 at 6:12 AM Christian Grobmeier
>> >>> >> 
>> >>> >> wrote:
>> >>> >>
>> >>> >>>
>> >>> >>> On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote:
>> >>> >>>> Some(most?) of the settings should be saved:
>> >>> 

Re: [log4j] Improving log4j security

[Christian Grobmeier]

Since Piotrs response went to spam (thanks for confirming) I'd like to make 
sure you reveived Volkans questions as well. Please let me know if you did. 

If you didn't, he sent his response to the mailing list, if you need help 
subscribing, please let me know 

On Mon, Oct 9, 2023, at 22:28, Volkan Yazıcı wrote:
> *[I am sharing my earlier response (almost) verbatim below.]*
>
> I would like to address your both old and the most recent email *myself* –
> that is, it only reflects my personal view, and not of the PMC.
>
>>  A HTML-safe layout is only achieved if
>
>> defined akin to:
>
>>
>
>>  `.
>
>
>> Would Log4j be willing to improve the usability of encoding in pattern
>> layouts to make it less likely for users to shoot themselves in the foot?
>
>
> We provide best in the class support for JSON, HTML, etc. with their
> associated dedicated layouts. If users insist on using `PatternLayout` for
> those purposes, it feels to me somebody is stubbornly trying to pass SQL
> arguments with string concatenation.
>
>
> Nevertheless, if you have any proposals on _"improving the usability of
> encoding in pattern layouts to make it less likely for users to shoot
> themselves in the foot"_, you are more than welcome! The entire Log4j crew
> would be happy to assist you for such contributions.
>
>
>> I did go ahead and create a proof-of-concept encoder for
>
>> log4j that securely encodes exceptions without completely
>
>> mangling the stack traces:
>
>>
>
>> https://github.com/vlkl-sap/log4j-encoder
>
>>
>
>> There are two different implementations of the encoder with
>
>> different trade-offs (to be discussed). I also implemented a
>
>> new, more encompassing text encoder, based on URL
>
>> encoding, but this aspect is independent.
>
>
> Before writing any code, would you mind helping us with the following
> questions, please?
>
>
>1. Do you have a use case? If so, where does `HtmlLayout` fall short of
>addressing it?
>2. Assuming `HtmlLayout` doesn't address your needs, can we [in a
>backward-compatible manner] improve `HtmlLayout` to make it work for you?
>3. Can we [in a backward-compatible manner] incorporate your
>`PatternLayout` changes?
>
> Kind regards.
>
>
> On Mon, Oct 9, 2023 at 5:24 PM Klebanov, Vladimir
>  wrote:
>
>> Thanks, Piotr. I don't know what happened to your replies (maybe the spam
>> filter dropped them), but I am happy that we recovered from that now.
>>
>> Log injections are definitely security issues, but if you prefer to talk
>> about them in the open, I will follow suit.
>>
>> For context: a log injection occurs when an application logs user-supplied
>> data (which is often the case). Attacker can exploit log injection to forge
>> log records and impede forensics or exploit potential vulnerabilities in
>> log-processing systems. There is a variety of string classes that attackers
>> can try to inject, including newlines, ANSI sequences, Unicode direction
>> markers, Unicode homographs, JavaScript, PHP, etc.
>>
>> Ideally, applications defend against log injection attacks by encoding
>> (aka escaping) user-supplied data before logging. The specific encoding
>> depends on the desired level of protection. URL-encoding, for instance,
>> would protect against all of the above-mentioned attack classes, but weaker
>> encodings may be sometimes acceptable as well.
>>
>> A natural place to implement encoding is in the pattern layout
>> configuration. Some encoding pattern converters are already available in
>> log4j, but there are still gaps that I would like to help fill. I think
>> there are roughly three of them:
>>
>> 1. The documentation should more prominently explain the issue. Today,
>> most users would probably think that the following layout is HTML-safe,
>> while it's not:
>> 
>>
>> 2. The HTML encoder is not always sufficient. I would like to see an
>> addition of a stricter one, such as a URL-encoder.
>>
>> 3. The current encoders encode all structured data (like the complete
>> exception stacktrace) and not just the injection-prone parts (i.e., the
>> exception message). This means I cannot replace the insecure layout above
>> with the secure layout
>>
>> 
>>
>> without changing how logs are parsed (as the stack frames will not be
>> separated by newlines anymore).
>>
>> I have created a PoC implementation of an improved encoder, but I would
>> obviously need help to make it productive. Is anyone here interested in
>> that? Questions and comments are welcome as well.
>>
>> Thanks,
>> Vladimir
>>
>>
>> -Original Message-
>> From: Piotr P. Karwasz 
>> Sent: Thursday, 5 October 2023 22:06
>> To: dev@logging.apache.org; Klebanov, Vladimir 
>> Subject: Re: [log4j] Improving log4j security
>>
>> [You don't often get email from piotr.karw...@gmail.com. Learn why this
>> is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Hi Vladimir,
>>
>> On Thu, 5 Oct 2023 at 21:47, Klebanov, Vladimir
>>  wrote:
>> > I would like to contribut

Status of log4j-audit

[Christian Grobmeier]

Hello,

We have been talking about log4j-audit (same thread as with log4j-server).

I have checked today after seeing Piotr's message, and even after reading the 
readme, I am still trying to figure out the purpose of this product. That 
aside, I am concerned the last change was four years ago. -audit is depending 
to Log4j 2.10, which is affected by log4shell.

I checked on the releases, and I see only RCs here:
https://github.com/apache/logging-log4j-audit/tags
But two releases here:
https://logging.apache.org/log4j-audit/latest/download.html

What message are we sending?

As I understand it we are currently promoting software that contains log4shell 
without any word of warning or any development plan on the horizon.

Do we have any development cycles left to fix at least the security issues, 
with the Flume project probably merging into this project?

I am not asking for the "will power", but the "real power": if it is not 
realistic to maintain this project, we should add warning labels, consider EOL, 
and/or actively search for contributors.

I am willing to support a bit, but only if I understand the use of -audit :)

Kind regards,
Christian

[site] Jekyll proposal (in branch)

[Christian Grobmeier]

Hello,

Based on recent comments, I made a branch for using Jekyll on the leading site. 
It's a branch, we can discard it. The migration took me 1.5h, excluding this 
e-mail - not much wasted.

https://github.com/apache/logging-site/tree/jekyll

This is not yet auto-deployed, but if nobody opposes it, I will move on, merge, 
and autodeploy.

Here is some info:

Jekyll supports data files like this:
https://github.com/apache/logging-site/blob/jekyll/_data/projects.yml

In the future, one could modify those data files directly from GitHub UI to 
update a status or a team member. It would be autodeployed then. The code for 
the output is also simple:

https://github.com/apache/logging-site/blob/jekyll/index.html

The amount of HTML has decreased. In addition, I was able to use Flexbox, which 
is built-in to browsers (no more slow Bootstrap in this case)

We also can make use of SCSS now, which can use advanced CSS (in this case only 
nesting):
https://github.com/apache/logging-site/blob/jekyll/css/site.scss#L44

The current team list could be moved to a data file, too, but I left it as adoc 
to showcase that this Jekyll page can work with adoc as well:
https://github.com/apache/logging-site/blob/jekyll/team-list.adoc

If you want to work with Jekyll, you can run the scripts:

./run-docker-build.sh (only one time; Docker needs to be installed)
./run-jekyll.sh (when you want to work)

This way, you can build locally and check. However, you don't need to do this 
to update tiny things quickly.

Please let me know if you want to object; otherwise, I would love to move this 
forward.

If we, at some later point in time, move on to something like Antora, I will 
gladly help to migrate; however, since we are using adoc for this website as 
well, it should be straightforward.

As soon as I have a go for this, I will prepare a blog section announcing the 
latest releases and preparing everything for some announcements we had in mind 
on the PMC list.

Kind regards,
Christian

Re: Status of log4j-audit

[Christian Grobmeier]

As long as we can get those security issues released, I am fine.
Personally I am fine with helping with the editor, if it stays as web app (I 
can do react and such).
If it's JavaFX - I am lost. I have hard time helping with Swing in Chainsaw.

Since you mentioned its importance, we should work on a release very soon. It 
is really hard to justify the presence of those security issues, even when I 
understood from Matt that users need to chose their versions themselves.

Still, I am not perfectly clear of what you will do with it and what the 
"additional audit apis" actually are. I have a feeling though. 

On Tue, Oct 10, 2023, at 22:53, Ralph Goers wrote:
> Yes, I can update the dependencies and do a release.
>
> The primary issue with the project as it stands is the Catalog Editor 
> UI. It is really stupid. It uses Spring Boot for the UI but it is meant 
> to run locally. It was suggested I switch the UI to JavaFX but I have 
> never had the chance.
>
> FWWI - Log4j-Audit is the entire reason I created Log4j2. It cannot 
> work with SLF4J/Logback.
>
> Ralph
>
>
>> On Oct 10, 2023, at 1:48 PM, Matt Sicker  wrote:
>> 
>> Log4j Audit has multiple components:
>> 
>> * Audit API for extending log4j-api with some additional audit logging APIs
>> * Tool for managing your audit event schemata and such (the web app thing)
>> * Tool for generating structured log classes from the event schemata
>> 
>> Thus, in typical use, you can (and should) specify what version of 
>> log4j-core you’re using for your application. As for maintenance, the web UI 
>> could use an overhaul (though it would likely involve a rewrite into 
>> something more popular like React), but the overall library is fairly 
>> compact. I do have an outstanding Jira issue for Log4j to work on a more 
>> fluent API for structured logging, and that sort of feature can be informed 
>> or inspired by log4j-audit.
>> 
>> As for the log4j-server question, I’d expect that if we adopt Flume into the 
>> PMC, then Flume would supersede the server examples since we’d have 
>> something far more mature and production-ready for such a use case.
>> 
>>> On Oct 10, 2023, at 1:33 PM, Christian Grobmeier  
>>> wrote:
>>> 
>>> Hello,
>>> 
>>> We have been talking about log4j-audit (same thread as with log4j-server).
>>> 
>>> I have checked today after seeing Piotr's message, and even after reading 
>>> the readme, I am still trying to figure out the purpose of this product. 
>>> That aside, I am concerned the last change was four years ago. -audit is 
>>> depending to Log4j 2.10, which is affected by log4shell.
>>> 
>>> I checked on the releases, and I see only RCs here:
>>> https://github.com/apache/logging-log4j-audit/tags
>>> But two releases here:
>>> https://logging.apache.org/log4j-audit/latest/download.html
>>> 
>>> What message are we sending?
>>> 
>>> As I understand it we are currently promoting software that contains 
>>> log4shell without any word of warning or any development plan on the 
>>> horizon.
>>> 
>>> Do we have any development cycles left to fix at least the security issues, 
>>> with the Flume project probably merging into this project?
>>> 
>>> I am not asking for the "will power", but the "real power": if it is not 
>>> realistic to maintain this project, we should add warning labels, consider 
>>> EOL, and/or actively search for contributors.
>>> 
>>> I am willing to support a bit, but only if I understand the use of -audit :)
>>> 
>>> Kind regards,
>>> Christian
>>

Re: [site] Jekyll proposal (in branch)

[Christian Grobmeier]

Hello,

I made the Jekyll branch work with the staging environment:
https://logging.staged.apache.org/

When you change something in the sources, it will be automatically deployed to 
Staging.

We also have a "news section", aka blog:
https://logging.staged.apache.org/blog/

To add or change a project, you made want to edit:
https://github.com/apache/logging-site/blob/jekyll/_data/projects.yml
You can edit it directly in Github UI if you prefer to try it out.

It will take a few seconds to build and deploy.

I want to move the Team members to a data file as well.

If no objections, I'd like to move this to asf-site

Kind regards,
Christian


On Tue, Oct 10, 2023, at 23:10, Christian Grobmeier wrote:
> Hello,
>
> Based on recent comments, I made a branch for using Jekyll on the 
> leading site. It's a branch, we can discard it. The migration took me 
> 1.5h, excluding this e-mail - not much wasted.
>
> https://github.com/apache/logging-site/tree/jekyll
>
> This is not yet auto-deployed, but if nobody opposes it, I will move 
> on, merge, and autodeploy.
>
> Here is some info:
>
> Jekyll supports data files like this:
> https://github.com/apache/logging-site/blob/jekyll/_data/projects.yml
>
> In the future, one could modify those data files directly from GitHub 
> UI to update a status or a team member. It would be autodeployed then. 
> The code for the output is also simple:
>
> https://github.com/apache/logging-site/blob/jekyll/index.html
>
> The amount of HTML has decreased. In addition, I was able to use 
> Flexbox, which is built-in to browsers (no more slow Bootstrap in this 
> case)
>
> We also can make use of SCSS now, which can use advanced CSS (in this 
> case only nesting):
> https://github.com/apache/logging-site/blob/jekyll/css/site.scss#L44
>
> The current team list could be moved to a data file, too, but I left it 
> as adoc to showcase that this Jekyll page can work with adoc as well:
> https://github.com/apache/logging-site/blob/jekyll/team-list.adoc
>
> If you want to work with Jekyll, you can run the scripts:
>
> ./run-docker-build.sh (only one time; Docker needs to be installed)
> ./run-jekyll.sh (when you want to work)
>
> This way, you can build locally and check. However, you don't need to 
> do this to update tiny things quickly.
>
> Please let me know if you want to object; otherwise, I would love to 
> move this forward.
>
> If we, at some later point in time, move on to something like Antora, I 
> will gladly help to migrate; however, since we are using adoc for this 
> website as well, it should be straightforward.
>
> As soon as I have a go for this, I will prepare a blog section 
> announcing the latest releases and preparing everything for some 
> announcements we had in mind on the PMC list.
>
> Kind regards,
> Christian

Re: [log4j] Improving log4j security

[Christian Grobmeier]

This whole problem sounds as follows:

- we don't escape because we don't think we should use a pattern layout like 
this
- an attacker sends data to the log
- the log sends data to a processing system
- if this processing issue has a flaw, bad things might happen

It does not sound like a widespread scenario, but a possible one. When I have 
learned one thing, it is we should not assume to know how a user might use a 
component. Even when we don't recommend this format for machine2machine, people 
still do it.

I assume we could quickly make log4j safer by adding an encoder, as suggested 
by Vladimir, so my question is, why should we not do it?

Kind regards,
Christian

On Thu, Oct 12, 2023, at 18:37, Klebanov, Vladimir wrote:
> Hi Volkan,
>
> It's not just about exchanging data between systems - that is just one 
> particular instance of a larger problem. If you use a pattern layout 
> for _any_ reason, it is currently extremely inconvenient to configure 
> securely. If you use a structured layout, again for any reason, it's 
> still inconvenient to configure securely, though indeed less so than a 
> pattern layout. My understanding is that not everyone can, will, or 
> should always use a structured layout over a pattern layout. For 
> entertainment, I have collected some layout statistics, which I include 
> below.
>
> For the pattern layout case, I have prototyped improved encoders that 
> can be used with log4j. The code has already been shared with you, 
> though it will obviously need (lots of) discussion. I am happy to 
> continue discussing the topic / working on the code with anyone who 
> finds it worthwhile.
>
> Thanks,
> Vladimir
>
> Statistics: The dataset is certainly debatable, but it's the best one I 
> have. Out of the top 1000 starred Java repositories on GitHub, 89 
> contain a file log4j2.xml with at least one element matching .*Layout. 
> Out of these 89 repos, every single one defines at least one pattern 
> layout. Only two repos out of 89 define a layout that is not a pattern 
> layout: one repo a JSONLayout and one a StackdriverLayout. 
>
>
> -Original Message-
> From: Volkan Yazıcı  
> Sent: Wednesday, 11 October 2023 11:32
> To: dev@logging.apache.org
> Subject: Re: [log4j] Improving log4j security
>
> Your use case sounds to me as follows: "I want to use `PatternLayout` for
> exchanging data between two systems and ... [it is insecure.]" (Please
> correct me if I am wrong.) My answer is: "Don't".
>
> `PatternLayout` is not designed to be machine-readable. If I am not
> mistaken, there is not even a standard format for stack traces. Consider
> ones generated from exceptions containing messages with newline characters.
> How are you gonna deal with parsing those? Or thread names, custom levels,
> custom markers, etc. with a newline? My point is, don't use `PatternLayout`
> for exchanging data between systems. For that purpose, we recommend using
> structured layouts, e.g., `JsonTemplateLayout`. ELK, Splunk, Datadog,
> NewRelic, etc. they all accept JSON.
>
> In conclusion, I recommend you to use JTL for publishing logs to other
> systems. If you have `PatternLayout` [encoder?] enhancements that we can
> incorporate in a backward-compatible way, please share.

Re: [log4j] Improving log4j security

[Christian Grobmeier]

On Thu, Oct 12, 2023, at 20:44, Piotr P. Karwasz wrote:
> However we should consider properly documenting PatternLayout: there
> should be a warning reminding users that while it is technically
> possible to generate a proper JSON or XML using this layout it is not
> the suggested way.

No objections to letting people know how it is supposed to work :)

[VOTE] Release Apache Log4j 2.21.0

[Christian Grobmeier]

This is a vote to release the Apache Log4j 2.21.0.

Website: https://logging-log4j.staged.apache.org/log4j/2.x/
GitHub: https://github.com/apache/logging-log4j2
Commit: 493d9a9daabc72d10582c4682538baa93a2a
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j
Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1202
Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0

Please download, test, and cast your votes on this mailing list.

[ ] +1, release the artifacts
[ ] -1, don't release, because...

This vote is open for 72 hours and will pass unless getting a
net negative vote count. All votes are welcome and we encourage
everyone to test the release, but only the Logging Services PMC
votes are officially counted.

== Release Notes

This release primarily focuses on enhancements to our OSGi and JPMS support and 
contains several bug fixes.
It will be the first release built and signed by the CI using the 
https://keyserver.ubuntu.com/pks/lookup?search=077E8893A6DCC33DD4A4D5B256E73BA9A0B592D0&op=index[ASF
 Logging Services Release Manager GPG key], which is shared in 
https://www.apache.org/dist/logging/KEYS[KEYS].

The Log4j 2.21.0 API, as well as the other artifacts, maintains binary 
compatibility with the previous release.

Apache Log4j 2.21.0 requires Java 8 to run.
The build requires JDK 11 and generates reproducible binaries.

For complete information on Apache Log4j 2, including instructions on how to 
submit bug reports, patches, get support, or suggestions for improvement, see 
http://logging.apache.org/log4j/2.x/[the Apache Log4j 2 website].

=== OSGi changes

All the published artifacts are OSGi bundles or fragments.

This release introduces a change in the bundle symbolic names to allow them to 
function as JPMS module name: all hyphens `-` present in the bundle names of 
previous releases were replaced by dots `.`.

=== JPMS changes

All the published artifacts have been migrated from automatic modules to named 
JPMS modules.
All packages marked as private in the Javadoc are not exported.

The module name of four bridges (`log4j-slf4j-impl`, `log4j-slf4j2-impl`, 
`log4j-to-jul` and `log4j-to-slf4j`) have been changed to adhere to the same 
convention as the OSGi bundle names.


=== Added

* Added marker parent support to `JsonTemplateLayout` (#1381)
* Added https://facebook.github.io/zstd/[ZStandard compression] support (#1508, 
#1514)
* Added a warning for incorrect syntax of highlighting styles (#1545, #1637)

=== Changed

* Open `FileExtension` methods to allow their usage in custom 
``RolloverStrategy``s (#1365, #1683)
* Bumped the minimum Java version required for the build to JDK 11. Runtime 
requirements remain unchanged. (#1369)
* Set the default `minLevel` and `maxLevel` of `LevelRangeFilter` to `OFF` and 
`ALL`, respectively (#1503)
* Removed additional `isFiltered` checks in `AsyncLoggerConfig` (#1550)
* Use Java version-specific warnings in `StackLocator` (#1760)
* Started logging a status error event instead of an NPE in 
`OsgiServiceLocator.loadServices(Class, Lookup, boolean)` when a bundle has no 
valid `BundleContext` for a service type
* Implemented a CI-based release process
* Update Eclipse Angus Activation to version 
https://github.com/eclipse-ee4j/angus-activation/releases/tag/2.0.1[2.0.1] 
(#1591)
* Update Eclipse Angus Mail to version 
https://github.com/eclipse-ee4j/angus-mail/releases/tag/2.0.2[2.0.2] (#1591)
* Update `com.datastax.cassandra:cassandra-driver-core` to version 3.11.5 
(#1591)
* Update Apache Cassandra to version 
https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt[3.11.16] 
(#1591)
* Update Apache Commons Compress to version 
https://commons.apache.org/proper/commons-compress/changes-report.html#a1.24.0[1.24.0]
 (#1591)
* Update Apache Commons CSV to version 
https://commons.apache.org/proper/commons-csv/changes-report.html#a1.10.0[1.10.0]
 (#1591)
* Update Jackson to version 
https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15.2[2.15.2] (#1591)
* Update Jakarta Activation API to version 
https://jakarta.ee/specifications/activation/2.1/changelog/[2.1.2] (#1591)
* Update Jakarta Mail API to version 
https://jakarta.ee/specifications/mail/2.1/changelog/[2.1.2] (#1591)
* Update JCTools to version 
https://github.com/JCTools/JCTools/blob/master/RELEASE-NOTES.md[4.0.1] (#1591)
* Update Apache Kafka to version 
https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html[3.4.0] (#1591)
* Update Kubernetes client to version 
https://github.com/fabric8io/kubernetes-client/releases?q=5.12.4[5.12.4] (#1591)
* Update `org.mongodb:mongodb-driver-core` to version 4.10.2 (#1591)
* Update `io.netty:netty-bom` to version 4.1.97 (#1591)
* Update Spring Boot to version 
https://github.com/spring-projects/spring-boot/releases/tag/v2.7.15[2.7.15] 
(#1591)
* Update Spring Framework to version 
https://github.com/spring-projects/spring-framework/releases/tag/v5.3.29[5.3.29]
 (#1591)
* Update Tomcat JULI 

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

[Christian Grobmeier]

>> [1] Christian's recent Jekyll experiment on the `asf-staging` branch
>> of `logging-site` repository confused the INFRA and it is acting
>> strangely. This will *NOT* be an issue when we push the website
>> changes to production, i.e., `asf-site` branch. Though we will try
>> fixing `asf-staging` anyway in the meantime.

On Fri, Oct 13, 2023, at 13:28, Piotr P. Karwasz wrote:
> I think that the problem is that the `asf-staging` branch in
> `logging-site` has switched from a `content` folder to an `output`
> folder, while some of our 6 other site repos have a `content` folder.
> It is fixable, but INFRA offers us an infinite number of
> `logging-.staged.apache.org` domains and I think we should use
> it.

According to this doc:
https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-WebsitedeploymentserviceforGitrepositories

We just have to give it a profile:

staging:
  profile: mystuff

Would result in:

logging-mystuff.staged.apache.org

I can easily migrate to this.

The folder "output" is the default with ASF infra, but it is possible to 
replace it with content:

jekyll:
  whoami: jekyll
  target: asf-staging 
  outputdir: content 

Why is content not causing this issue?
For me both is possible, just trying to understand the best way.

Kind regards,
Christian