Re: Archive `logging-pipelines`

[Dominik Psenner]

Hi Volkan. Log4net used to use jenkins pipelines. But I can't recall any
reference to that repository.

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Fri, Sep 15, 2023, 09:04 Volkan Yazıcı  wrote:

> AFAIC, no Logging Services projects use Jenkins pipelines anymore.
> Created INFRA-24991 to archive the `logging-pipelines` repository,
> FYI.
>

Re: I have a question regarding LOG4NET-27 and LOG4NET-367.

[Dominik Psenner]

Hi,

I am mostly no longer involved in software development, busy otherwise. It
is great to see you are interested and willing to invest your valuable time.

There should be a branch containing the work in progress of the next
generation rolling file appender. I named it something like RFA-NG if my
memory does not fail on me. You could base your work on that or proceed
otherwise.

Warm regards
Dominik
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sun, Mar 19, 2023, 13:38 夏月 梨幸  wrote:

> I do not speak English, so please excuse the machine translation.
>
> Hello.
> Let me ask you a question.
>
> 1) Which is the best way to proceed on the topic of MaxDateRollBackups in
> RollingFileAppender?
> ・post https://issues.apache.org/jira/browse/LOG4NET-27
> ・post https://issues.apache.org/jira/browse/LOG4NET-367
> ・post dev@logging.apache.org
>
> 2) Since RollingFileAppender has been suggested to be re-created in
> LOG4NET-367, I am working on implementing MaxDateRollBackups as a single
> function independent of Log4Net.
> We hoped that if we provided an API, the person leading LOG4NET-367
> would call it at the right time from the appropriate method in
> RollingFileAppender.
>
> However, since Log4Net became dormant on 2020/04/05 and was revived on
> 2020/04/06, we are not sure who is now in charge and leading LOG4NET-367.
> Is Dominik Psenner still in charge of LOG4NET-367? Or is he giving it
> up?
>
> 3) I am currently working on implementing MaxDateRollBackups in
> VisualStudio2022 with .NetFramework4.7, C# 7.0.
> However, I found the following statement.
>
> > apache-log4net-source-2.0.15.zip
> >   BUILDING.md
> >   Log4net provides support for a wide array of targets, including
> >   - older .net 2 and 3.5 (including client profiles)
> >   - more modern net40/net45
> >   - netstandard1.3/2.0
>
> Would I have had to implement it in .NetFramework 2.0, C# 2.0?
>
> That is all.
>
> Thank you for reading.
>
> 夏月 梨幸(Natsuki Rikou)
>
>

Re: [ANNOUNCE] Changes to Jira Account Creation (issues.a.o/jira)

[Dominik Psenner]

GitHub issues could be a good replacement for jira IMO.



Mailing lists do not have an issue with spam because there are human
moderators doing most of the filtering. ;-)

There are several moderation messages every day, some of them even directly
land in my spam folder and I won't bother finding them. For me in
particular this is Gmail's spam filtering. I don't know if that is any
better than others.

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Mon, Oct 24, 2022, 04:07 Robert Middleton  wrote:

> I'm somewhat annoyed that the spam in jira is not able to be
> automatically filtered out.  The mailing lists don't seem to have an
> issue with spam.
>
> Jira is definitely more powerful(and better in some regards) but the
> github issues and projects do seem to have more of a feature parity
> with Jira now.
>
> I will plan on enabling the Github issues for Log4cxx sometime in the
> next few days unless somebody strongly disagrees.
>
> -Robert Middleton
>
> On Sun, Oct 23, 2022 at 7:30 PM Matt Sicker  wrote:
> >
> > Jira support is left in place for anyone who heavily relies on it
> already. I’d prefer not to maintain two issue repositories, so I’d lean
> toward switching to GH Issues. Would be nice if we could copy existing
> issues over or have some sort of redirect URLs.
> >
> > A nice advantage to uses GHI would be using other actions to help
> maintain a changelog file based on issues and PRs. That sort of thing
> integrates nicely with Dependabot, too!
> >
> > —
> > Matt Sicker
> >
> > > On Oct 23, 2022, at 15:40, Gary Gregory 
> wrote:
> > >
> > > Using 2 issue tracking system sounds like a pain... :-(
> > >
> > > Gary
> > >
> > >> On Sun, Oct 23, 2022, 16:34 Ralph Goers 
> wrote:
> > >>
> > >> Yup, I somehow missed that sentence.
> > >>
> > >> So they are suggesting that development continue to use Jira but users
> > >> report issues via GitHub. I would expect if we do that then we would
> also
> > >> create corresponding Jira issues for any of the GitHub issues we
> choose to
> > >> work on.
> > >>
> > >> Ralph
> > >>
> >  On Oct 23, 2022, at 12:57 PM, Volkan Yazıcı  wrote:
> > >>>
> > >>> Users will need to create a JIRA account, which needs to be
> supervised by
> > >>> the PMC, so that they can submit a bug report or ask a question. I
> cannot
> > >>> think of a more cumbersome method for a F/OSS project to accept
> issues.
> > >> Put
> > >>> another way, practically no public users will go this route.
> > >>>
> > >>> Please search for "GitHub Issues" in the original email, in
> particular,
> > >>> this statement: *"We suggest projects consider using GitHub Issues
> for
> > >>> customer-facing questions/bug reports/etc."*
> > >>>
> > >>>
> > >>> On Sun, Oct 23, 2022 at 9:48 PM Ralph Goers <
> ralph.go...@dslextreme.com>
> > >>> wrote:
> > >>>
> >  I actually don’t know where this idea of switching to GitHub issues
> is
> >  coming from.
> >  The email from infra talks about how Jira will no longer allow
> random
> >  users to sign
> >  up and the tool they provided to allow the PMC to register users. I
> > >> would
> >  guess the
> >  expectation would be that we would provide some process for our
> users to
> >  requests
> >  ids from the PMC.
> > 
> >  What does any of this have to do with GitHub issues. I see no
> mention of
> >  that in
> >  the email from infra.
> > 
> >  Ralph
> > 
> > > On Oct 23, 2022, at 12:10 PM, Volkan Yazıcı 
> wrote:
> > >
> > > I personally think this is great news in the long run. I already
> had
> > > pitched the idea of moving to GitHub Issues earlier, but it was
> back
> > >> then
> > > rejected due to various reasons; GitHub is proprietary, JIRA also
> plays
> >  an
> > > archive role due to its age, `changes.xml` sort-of requires JIRA
> > >> tickets,
> > > etc. World spam organizations solved the discussion for everyone.
> 
> > >
> > > We were already receiving bug reports via Issues, nothing has
> changed
> > >> in
> > > this regard. Yet we need to reflect the official switch to Issues
> in
> > >> our
> > > documentation, which right now points users to JIRA
> > > , too. I also
> > >> expect
> > > more questions funneled via StackOverflow, since several people
> were
> >  using
> > > JIRA for asking questions too. Last but not least, maybe this would
> >  create
> > > sufficient leverage to replace `changes.xml` with something else.
> > >
> > > On Sat, Oct 22, 2022 at 4:53 AM Matt Sicker 
> wrote:
> > >
> > >> This is relevant to potentially switching to GitHub issues.
> > >>
> > >>
> > >> Begin forwarded message:
> > >>
> > >>> From: fluxo 
> > >>> Date: October 21, 2022 at 20:02:01 CDT
> > >>> To: annou...@infra.apache.org
> > >>> Subject: [ANNOUNCE] Changes to Jira Account Creation

Re: log issue

[Dominik Psenner]

Hi,

As far as I know log4rc is not a library part of Apache Logging Services
TLP. Would it be possible that you have sent this to the wrong recipient?

Dominik
--
Sent from my phone.

On Wed, Oct 12, 2022, 07:35 Krotha, Suharika 
wrote:

> Hii,
> Logs are not appearing on using log4rc
>
>

Re: ci-builds all 3.6TB disk is full!

[Dominik Psenner]

Before blindly shooting away storage, I propose to look at what is actually
stored. For example, there could be log4net builds in need of storage. I
assume that log4net is still building on jenkins.

On Wed, 20 Apr 2022 at 20:15, Gary Gregory  wrote:

> I guess you can ask Gavin ;-)
>
> Gary
>
> On Wed, Apr 20, 2022, 09:12 Volkan Yazıcı  wrote:
>
> > We haven't been using Jenkins for months. I think we can safely remove
> all
> > `target` folders and whatever cache there is. But I am curious, how is
> this
> > number exactly obtained?
> >
> > On Wed, Apr 20, 2022 at 3:04 PM Gary Gregory 
> > wrote:
> >
> > > Hi All,
> > > Looks like our Looging project is using too much space, almost 6 GB in
> > the
> > > CI system. Does anyone here know how to clean this up and prevent it
> from
> > > happening?
> > >
> > > Gary
> > >
> > > -- Forwarded message -
> > > From: Gavin McDonald 
> > > Date: Wed, Apr 20, 2022, 03:27
> > > Subject: ci-builds all 3.6TB disk is full!
> > > To: builds 
> > >
> > >
> > > Hi All,
> > >
> > > Seems we need to do another cull of projects storing way too much data.
> > >
> > > Below are everyone above 1GB. Just FYI, 1GB is fine, likely 50GB is
> fine,
> > > but above
> > > that, its just too much. I will be removing 1TB of data from wherever I
> > can
> > > get it.
> > >
> > > Please, look after your jobs, and your fellow projects by limiting what
> > you
> > > keep.
> > >
> > > 1.6TTomee
> > > 451GKafka
> > > 303Gjames
> > > 176Gcarbondata
> > > 129GJackrabbit
> > > 71G Brooklyn
> > > 64G Sling
> > > 64G Netbeans
> > > 60G Ranger
> > > 38G AsterixDB
> > > 33G OODT
> > > 29G Tika
> > > 27G Syncope
> > > 24G Atlas
> > > 20G IoTDB
> > > 18G CXF
> > > 16G POI
> > > 11G Solr
> > > 11G Mesos
> > > 8.7GRoyale
> > > 7.8GLucene
> > > 7.6GMyFaces
> > > 7.6GDirectory
> > > 6.4GOpenJPA
> > > 6.0GManifoldCF
> > > 5.9GActiveMQ
> > > 5.7GLogging
> > > 5.6GArchiva
> > > 5.5GUIMA
> > > 5.3Gctakes
> > > 4.7GHeron
> > > 4.6GJena
> > > 4.0GOpenOffice
> > > 3.8GCloudstack
> > > 3.4GShiro
> > > 2.5GQpid
> > > 2.1GJSPWiki
> > > 2.1GJMeter
> > > 2.0GJClouds
> > > 1.8GSantuario
> > > 1.8GOpenMeetings
> > > 1.8GCamel
> > > 1.7GKaraf
> > > 1.7GHttpComponents
> > > 1.7GAnt
> > > 1.5GTapestry
> > > 1.5GCommons
> > > 1.3GDeltaSpike
> > > 1.2GRya
> > > 1.2GAries
> > > 1.2GAccumulo
> > > 1.1GPDFBox
> > >
> > > --
> > >
> > > *Gavin McDonald*
> > > Systems Administrator
> > > ASF Infrastructure Team
> > >
> >
>


-- 
Dominik Psenner

Re: Dynamically updating filters across many instances

[Dominik Psenner]

Ralph, I do not believe that there exists a "one size fits it all"
solution. Yes, running in debug log has drawbacks and should not be
necessary. And yet I learned that only debug logs may provide enough
insights. The cause for this is simple: developers test code at "debug"
level and when time is short, may not add enough log statements on info.

My intention was to push the horizon and I wanted to share this idea only
because I read "hundreds of applications are configured from a single
configuration file that should be modified only by qualified personnel". To
me this single configuration file sounds like a single point of failure
where even only a small typo can have devastative effect. Looking for a
solution that goes beyond the logging configuration may be a good idea in
such a case.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sun, Apr 10, 2022, 07:21 Ralph Goers  wrote:

> What you propose below is exactly what I described in my previous post.
> Whether it makes its way into Log4J will depend on how generally useful it
> ends up being.
>
> As for distributed tracing, yes, of course it is, it is the collection of
> logs for a single user or account across all the components involved in
> processing a request. But while the problem may occur in component B it may
> be caused by something that happened in component A, so you need all the
> logs as if they came from a single application to diagnose the problem. Of
> course, all the logs need correlation data to be able to do this.
>
> Ralph
>
> > On Apr 8, 2022, at 4:32 PM, Volkan Yazıcı  wrote:
> >
> > What you are describing sounds to me more fitting for distributed
> tracing
> > rather than logging, but I will skip that discussion for now.
> >
> > Rather than "hacking" a Log4j component to deliver this functionality,
> I'd
> > simply implement a custom Filter keeping a cache of user IDs to be
> > inspected. This cache could be populated from SCC or some database where
> > your operators have write access by means of a dashboard, web UI, or
> > something. Since this custom filter implementation totally belongs to
> you,
> > you can even go wild and implement instantaneous updates via long-polling
> > or publishing IDs-to-be-inspected snapshots to an event queue.
> >
> > I think every moderately sized company (incl. yours, I presume) has a
> > handful of libraries shared by all its applications. You can leverage
> these
> > to take care of making sure your custom filter lands into their
> classpaths.
> >
> >> On Wed, Apr 6, 2022 at 9:14 AM Ralph Goers 
> >> wrote:
> >>
> >> I’m looking for some inspiration.
> >>
> >> At work we use Spring Cloud Config and host our logging configuration
> >> there. It is shared by something like 150 services, which comes out to
> >> hundreds of service instances. We have a standard of including the
> user’s
> >> id and the customer’s account number in the ThreadContext and passing
> those
> >> automatically from one service to another.  Operationally, went to
> normally
> >> log at WARN or INFO. But when a customer calls with a problem we want
> to be
> >> able to enable debug logging for that user or account. I know I could
> use
> >> either the DynamicThresholdFilter or the ContextMapFilter to do this.
> >>
> >> So here are the issues.
> >> 1. We don’t really want operations folks editing the log4j configuration
> >> file directly.
> >> 2. Our SCC uses a Git repo hosted by a third party. We don’t really want
> >> to open access to allow Git to call SCCs endpoint to notify it of
> changes.
> >> 3. Without the Git notification we will have to poll for changes in SCC.
> >> This means it could be a few minutes before SCC notices changes and then
> >> another few minutes before Log4j notices changes.
> >>
> >>
> >> I’m considering doing something like:
> >>
> >>  >> onMatch="ACCEPT" onMismatch="NEUTRAL">
> >>   
> >> 
> >>
> >> Where scc represents a new SpringCloudConfigLookup. This would have to
> >> represent a file in SCC that contains a mapping for accountNumber to
> >> something.
> >>
> >> There are a number of issues with this.
> >> 1. This still requires editing and committing a file.
> >> 2. It has the polling delay.
> >> 3. Log4j-Spring-Cloud-Config would have to cause the file to be
> monitored
> >> just as the config file is.
> >> 4. The syntax of the existing Filters requires that when looking for
> >> multiple users each must be specified in its own key. That would mean
> the
> >> filter would have to be preconfigured with the maximum number of
> accounts
> >> it can look for. It would also mean the syntax for specifying the
> account
> >> numbers could get messy. However, it could register a Watcher for the
> >> external file and force a reconfiguration when it does.
> >>
> >> An alternative to reconfiguring could be to specify the variable as
> >> $${src:accountNumber) and resolve the lookup for every log event.
> >> Presumably it would use a cached value and cause 

Re: Dynamically updating filters across many instances

[Dominik Psenner]

> >> 
> >>
> >> Where scc represents a new SpringCloudConfigLookup. This would have to
> >> represent a file in SCC that contains a mapping for accountNumber to
> >> something.
> >>
> >> There are a number of issues with this.
> >> 1. This still requires editing and committing a file.
> >> 2. It has the polling delay.
> >> 3. Log4j-Spring-Cloud-Config would have to cause the file to be
> monitored
> >> just as the config file is.
> >> 4. The syntax of the existing Filters requires that when looking for
> >> multiple users each must be specified in its own key. That would mean
> the
> >> filter would have to be preconfigured with the maximum number of
> accounts
> >> it can look for. It would also mean the syntax for specifying the
> account
> >> numbers could get messy. However, it could register a Watcher for the
> >> external file and force a reconfiguration when it does.
> >>
> >> An alternative to reconfiguring could be to specify the variable as
> >> $${src:accountNumber) and resolve the lookup for every log event.
> >> Presumably it would use a cached value and cause the value to change
> when
> >> the file is changed.
> >>
> >> These are just the first few things I thought of to do this. Does anyone
> >> else have any ideas?
> >>
> >> Ralph
>
>

-- 
Dominik Psenner

Re: [Newsletter] Re: log4net - performance hit because UserName is fetched always

[Dominik Psenner]

eintrag / Commercial Register No.: HRA 16 270,
> Persönlich haftender Gesellschafter / Personally Liable Partner: RUSEG
> Verwaltungs-GmbH, Sitz der Gesellschaft / Company's Place of Business:
> München, Registereintrag / Commercial Register No.: HRB 7 534,
> Umsatzsteuer-Identifikationsnummer (USt-IdNr.) / VAT Identification No.: DE
> 130 256 683, Elektro-Altgeräte Register (EAR) / WEEE Register No.: DE 240
> 437 86
> >
> >
>


-- 
Dominik Psenner

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

[Dominik Psenner]

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

Re: [VOTE] Future of Log4j 1.x

[Dominik Psenner]

+1, option 1

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Tue, Jan 4, 2022, 22:19 Remko Popma  wrote:

> +1 for Option 1
>
> On Wed, Jan 5, 2022 at 4:51 AM Volkan Yazıcı  wrote:
>
> > +1, Option 1
> >
> > On Wed, 29 Dec 2021, 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
> > >
> >
>

Re: [VOTE] CVE creation process

[Dominik Psenner]

+-0

I have no strong opinion. I do believe that an informal consensus about our
best practice should be all we need. It should suffice when two pmc members
acknowledge both fix and official communication. My perception is that we
already do our best. Beyond that, it will always be a walk on the edge to
satisfy all and any potential criteria (response time, quality of the fix,
quality of the communication, quality of the mitigation procedures, ..). We
may have to accept that these criteria will never be exactly the same and
have the same weight for all security issues.

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Mon, Jan 3, 2022, 16:54 Jason Pyeron  wrote:

> > -Original Message-
> > From: Xeno Amess
> > Sent: Monday, January 3, 2022 10:40 AM
> >
> > +0
> >
> > I just worried several things.
> >
> > 1. Will it make the cve's fix come out more slowly?
> > A vote means waiting for 72 hours usually.
> >
> > 2. Do all PMC who enter the vote always have enough ability and knowledge
> > for notifying how severe a vulnerability? Some vulnerabilities are, seems
> > small problem, nothing at all, but would actually do very much damage.
>
>
> 1. see: https://www.apache.org/foundation/voting.html
>
> 2. it does not have to be 72 hours.
>
> 3. Use CONSENSUS THROUGH SILENCE.
>
> e.g.
>
> Subject: Vote on apply CVE of 8.3 (v3 score) to release x.y.z [18 hours,
> silence=approve]
>
> SUMMARY... blah blah blah
>
> [] +1, Create CVE and accept tag release
> [] -1, DO NOT create CVE and address release at another time / vote
>
> The vote will remain open for 18 hours (short security timeline). 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.
>
> LACK OF NEGATIVE VOTES will be assume as a consensus.
>
> -Jason
>
>

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

[Dominik Psenner]

+1, Option 1

People should migrate to log4j2.

On Thu, 30 Dec 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 <
> sitnikov.vladi...@gmail.com> 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
>


-- 
Dominik Psenner

Re: [log4cxx] CI Benchmarking

[Dominik Psenner]

Hi Stephen,

The trouble with benchmarks in CI is that the numbers may be largely
unreliable, depending mostly on the hardware where it runs and in general
the surrounding environment. Chances are high that the benchmarks will not
produce comparable results.

It would however be good to provide some tools to run the (same) benchmarks
manually.

When run on the same hardware with different codebases or on different
hardware with the same codebase, the outcome may provide interesting and
comparable insights.

Warm regards
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Tue, Dec 28, 2021, 07:46 Stephen Webb  wrote:

> Hi,
>
> Robert has created a benchmark that I thought would be nice to integrate
> into CI.
>
> I see the Log4J has some benchmarks actions which are currently run
> manually with results posted to github pages.
>
> Do you consider this a useful/optimal approach?
>
> Would an threshold which an action could check for each PR be useful?
>
> Regards
> Stephen Webb
>
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> Virus-free.
> www.avast.com
> <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

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

[Dominik Psenner]

I am in favor of option 1, basically this:

* Add an EOL marker, big and bold
* Allow the repository to be cloned
* Allow the repository to be forked
* Disable the creation of new pull requests (on github)
* Disable creation of issues (on github; this is the default; I want to
stress this by mentioning it explicitly)

My reasoning behind this is that an EOL must not consume resources. Any
resource available should be invested in something that is not EOL so that
opportunities are not lost with friction or distraction.

Having this, someone can easily fork/clone the repository on github and
work on the codebase. We may consider accepting these patches as
contributions in the future. So long logging services considers log4j1 EOL,
people should be strongly encouraged to migrate and not to base their work
on an EOL component.

Why not allow creation of pull requests or issues? This clearly draws a
line. Logging services is not investing resources in an EOL component. This
enforces that any new commits happen on a fork or clone. This has the
effect that the public could not become confused. In the perception of the
general public any changes are clearly unrelated to Apache logging
services. The position of Apache logging services is clearly that the
component is EOL.

Should valuable contributions appear in the future we may reconsider what
to do. We could then for instance review changes in a fork and cherry pick
the contributions. This could hold for minimal changes that fix CVEs. If
changes are too large to be cherry picked, my gut feeling tells me that too
many resources are invested in an EOL component.

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Fri, Dec 24, 2021, 17: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
>
>
>

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

[Dominik Psenner]

As PMC member I voted to make the source code available in a git
repository. The git repository and the mailing list are all the tools
needed to prepare contributions and fixes. It allows for easy forking and
contributions to prosper. I would love to see this cause the community to
grow. It would be awesome to see more committers and add additional PMC
members.

As of now, log4j1 is still EOL. By examining future contributions we can
have a discussion about the EOL status in the future.

Lets take one step at a time! To me it is premature to open a public issue
tracker or accepting pull requests from the public. Someone would have to
review them and we would allow allocation of resources in favor of loosing
other opportunities. As said, I voted +1 to provide the tools needed to let
contributors work on contributions.

I encourage you to end the discussions now and to start working on
contributions instead.

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Fri, Dec 24, 2021, 13:51 Vladimir Sitnikov 
wrote:

> Dominik,
>
> Are you willing to add committers and PMC members to the log4j 1.x
> community?
>
> If you forbid issues and pull requests, then it goes against the idea of
> adding new commuters and PMC members for 1.x.
>
> 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?
>
> 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: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Dominik Psenner]

+1

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Thu, Dec 23, 2021, 22:38 Ralph Goers  wrote:

> +1
>
> Ralph
>
> > On Dec 23, 2021, at 2: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: Resurrecting log4j 1.x

[Dominik Psenner]

So far it has been discussed to patch 1.2.17. I propose to fork
logging-log4j1 [1] and base improvements on tag v1_2_17,  de9f0ea. As far
as I can tell, no additional work is required from Infra or Logging
Services.

[1] https://github.com/apache/logging-log4j1
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Thu, Dec 23, 2021, 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
>
> Vladimir
>

Re: Resurrecting log4j 1.x

[Dominik Psenner]

There are fixes for the flaws of log4j1 available: migrate to log4j2.

Is there a concrete need for log4j1 to be patched and that need cannot be
satisfied by migrating to log4j2?

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Thu, Dec 23, 2021, 16:39 Vladimir Sitnikov 
wrote:

> Volkan>To the best of
> Volkan>my knowledge, nobody has reached out to us with such a request
> except you
> Volkan>and Leo
>
> I think they just swallowed the pill that "1.x is marked EOL", and they did
> workarounds.
> a) make security team understand "the CVEs of 1.x are not that impactful
> for them"
> b) make internal forks that cut the problematic classes
> c) RedHat having their own fork
>
> However, now log4j went on the radars again,
> so I believe it is way easier (and better) to **fix** CVE than to keep
> explaining that
> "CVEs are not important in this specific case"
>
> I believe you might have access to the download stats for log4j.jar, so you
> can
> relate on the number of its usages.
>
> However, now I realize that the project itself is NOT dead as long as there
> are
> people that want to maintain it.
> It is not wise to say "log4j 1.x is dead" or "log4j 1.x is EOL" when there
> are people
> willing to maintain and release new versions.
> Note: I am not that crazy to do major refactorings in 1.x branch.
>
> So I figured out that releasing log4j 18+ ( : ) would make the lives of
> MANY MANY
> engineers and apps way easier. They would have a drop-in-replacement that
> fixes CVEs,
> improves security all over the world, and so on.
>
> Volkan>I bet it is a matter of months people will start asking for
> Volkan>other fixes once we make a 1.x release.
>
> Now we have a real issue: 1.x has LOTs of known CVEs.
> Could we refrain from theoretical discussions?
>
> Just in case, if in February you observe 10 newly created PRs,
> then it would be a nice problem to have.
>
> If all the PRs turn out to be trivial (e.g. fix NPE in a special case, or
> fix java.version parsing for Java 17),
> then you could just merge them and release 1.2.19
>
> If the review would take noticeable time, you could just say:
> "sorry, I have no time for reviewing the change, please consider creating a
> new PMC for log4j 1.x".
>
> **everybody's** time is limited. If you have no time or desire to
> maintain/support/review/release 1.x,
> then just ask the others do to that (e.g. invite new people to PMC or give
> away 1.x to another PMC).
>
> It might be there will be 10PRs, and there will be *noone* willing to
> review and nobody willing to inherit 1.x
> Then the PRs would be just abandoned.
>
> For instance, the current LOG4J2 JIRA has 809 issues. I doubt you will ever
> fix all of them :)
> So I doubt the question of "what do you do with old issues" or "what if
> there are 100500 open PRs"
> add any value.
>
> WDYT?
>
> Vladimir
>

Re: [VOTE] Release log4net 2.0.14

[Dominik Psenner]

* old-log4net.snk.gpg has been the old key to sign binaries.
* @Matt, where is the root logging KEYS file located?

The changes in the release look good to me. +1

On Mon, 20 Dec 2021 at 07:34, Davyd McColl  wrote:

> Thanks Matt
>
> Since you've given a +1, I'll write up some sticky notes to address these
> points in the near future.
>
> -d
>
>
> On December 19, 2021 23:51:45 Matt Sicker  wrote:
>
> > +1
> >
> > Notes on the release:
> > * I’ve copied your release signing key to the root logging KEYS file for
> > easier discoverability.
> > * The copyright year in the NOTICE file is a few years out of date at
> this
> > point. I’ve updated this in master, though you’ll want to update this
> again
> > in a couple weeks when it’s outdated again.
> > * Some included files in the base directory of the source zip are
> missing
> > copyright headers or shouldn’t even be included in the tarball (e.g.,
> the
> > appveyor config file probably isn’t necessary)
> >   - Not sure what old-log4net.snk.gpg is in there for, either.
> >   - Gulp task source files missing headers
> > * Artifact signatures and sha512 hashes look good (checked with shasum
> > which is the Perl script version), contain appropriate LICENSE and
> NOTICE
> > (besides the outdated copyright year, but not a blocker), no binaries in
> > the source zip, appropriate files in the binary zip.
> >
> > --
> > Matt Sicker
> >
> >> On Dec 16, 2021, at 07:47, Davyd McColl  wrote:
> >>
> >> Hi all
> >>
> >> I'd like to raise a vote to release log4net 2.0.14. Changelog is up on
> the
> >> pre-release page at
> >> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1
> >>
> >> I have updated staging docs and I _think_ I've done the right thing with
> >> respect to getting binaries and source up to the dev repo at
> >> https://dist.apache.org/repos/dist/dev/logging, but the download links
> on
> >> the staging docs point to the release download area, so I'm not sure if
> I
> >> should rather upload there so that staging documentation "works as
> >> expected" for the vote to continue.
> >>
> >> Thanks Ralph for assisting me in being able to uplodate artifacts
> myself.
> >> Much appreciated.
> >>
> >> -d
> >>
> >> PS. This email is a duplicate of the one sent from my work email (
> >> davyd.mcc...@codeo.co.za) which I believe has been lost somewhere
> along the
> >> way. Please ignore the other if it pops up.
> >>
> >>
> >> --
> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >> If you say that getting the money is the most important thing
> >> You will spend your life completely wasting your time
> >> You will be doing things you don't like doing
> >> In order to go on living
> >> That is, to go on doing things you don't like doing
> >>
> >> Which is stupid.
> >>
> >> - Alan Watts
> >> https://www.youtube.com/watch?v=-gXTZM_uPMY
> >>
> >> *Quidquid latine dictum sit, altum sonatur. *
> >
>


-- 
Dominik Psenner

Re: [Lo4Net] Cyber Vulnerability Vendor Impact Assessment for Lo4Net

[Dominik Psenner]

Hi Milind,

log4net is not log4j and therefore the recent log4j vulnerability is
unrelated to log4net. Beyond that, the Apache Software Foundation is vendor
neutral.

Warm regards,
Dominik

On Fri, 17 Dec 2021 at 22:24, Milind Wankhede  wrote:

> Good Morning/Afternoon,
> As you may know, a cyber-vulnerability impacting Java Library: log4j was
> recently identified.
> DHS warns of critical flaw in widely used software - CNNPolitics<
> https://www.cnn.com/2021/12/11/politics/dhs-log4j-software-flaw-warning/index.html
> >
>
> As a result and to provide our regulators confidence in our management of
> the impact, we are engaging our vendors to determine both if they were
> impacted (Yes/No) and if "Yes" what "Actions were taken?"
>
> We ask you consider in your response any 3rd party vendors which your
> business may share SMBC data with as well.
>
> We are looking for impact on Log4Net project/Library.
>
> Vendor Reported Impact (Yes or No)
> Actions Taken (If Any or N/A)
> Impact to SMBC (Yes/No)
>
>
> Please reply to all on this mail.
>
> To ensure we are in compliance with regulatory obligations we ask that you
> please respond within 48 hours of this mail.
>
> Thank you,
>
>
> Thanks & Regards!
> Milind Wankhede
> SMBC Capital Markets, Inc.
> 277 Park Ave New York NY 10172
> Phone: (212) 224-5221 | Email:  mwankh...@smbc-cm.com mwankh...@smbc-cm.com>
>
> This message, including any attachments, may contain information that is
> privileged, confidential and/or protected by copyright, and is subject to
> the terms available at
> https://www.smbcgroup.com/americas/disclaimers/emaildisclaimer.html/
> If you are not the intended recipient, or have received this message in
> error, please notify the sender immediately and delete this message.
>


-- 
Dominik Psenner

Re: [VOTE] Release log4net 2.0.14

[Dominik Psenner]

Hi Davyd,

I checked the changes since 2.0.13 and it looks good to me. Have you also
updated the log4net site? I would like to verify that the log4net website
looks good in staging.

Cheers
Dominik

On Thu, 16 Dec 2021 at 15:09, Davyd McColl 
wrote:

> Hi all
>
> I'd like to raise a vote to release log4net 2.0.14. Changelog is up on the
> pre-release page at
> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1
>
> I have updated staging docs and I _think_ I've done the right thing with
> respect to getting binaries and source up to the dev repo at
> https://dist.apache.org/repos/dist/dev/logging, but the download links on
> the staging docs point to the release download area, so I'm not sure if I
> should rather upload there so that staging documentation "works as
> expected" for the vote to continue.
>
> Thanks Ralph for assisting me in being able to uplodate artifacts myself.
> Much appreciated.
>
> -d



-- 
Dominik Psenner

Re: Answering FAQ regarding recent CVEs, was: log4net

[Dominik Psenner]

See:

https://logging.apache.org/mailing-lists.html

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Tue, Dec 14, 2021, 21:24 Mayank Kumar  wrote:

> can someone help me unsubscribe to this email group ? I have tried
> manytimes , but not succeeded ?
>
> -Mayank
>
> On Tue, Dec 14, 2021 at 12:16 PM Dominik Psenner 
> wrote:
>
> > This question has been asked several times now. I'm proposing to update
> the
> > website so that it is more obvious that log4net and log4xx are not
> > affected.
> >
> > On Tue, 14 Dec 2021 at 17:48, Matt Sicker  wrote:
> >
> > > JNDI is a Java API (Java Naming and Directory Interface) for
> abstracting
> > > various networking APIs like LDAP, DNS, etc. It’s not present in .NET
> or
> > > C++ (or any non-JVM language), so it does not affect log4net or
> log4cxx.
> > > --
> > > Matt Sicker
> > >
> > > > On Dec 14, 2021, at 08:54, David Schwartz 
> > wrote:
> > > >
> > > > Hi Joe,
> > > >
> > > > Adding to what Davyd wrote.  I just searched the codebase and the
> > > JndiLookup class (where the log4j vulnerability was found) does not
> exist
> > > in log4net.  In fact, there is no code related to jndi at all as far
> as I
> > > can see.
> > > >
> > > > David
> > > >
> > > > -Original Message-
> > > > From: Davyd McColl mailto:dav...@gmail.com>>
> > > > Sent: Tuesday, December 14, 2021 4:10 PM
> > > > To: dev@logging.apache.org <mailto:dev@logging.apache.org>
> > > > Subject: [EXTERNAL] Re: log4net
> > > >
> > > > Hi Joe
> > > >
> > > > No, it shouldn't, particularly because we're very different projects,
> > on
> > > very different platforms, and I understand that the log4j vuln is
> largely
> > > linked to a  _dependency_ of log4j. The closest we've had was an xml
> vuln
> > > that was patched some time ago.
> > > >
> > > > That being said, I'm currently the only maintainer and I definitely
> > have
> > > written the least code in log4net, so if you or anyone else would like
> to
> > > audit for vulnerabilities (and, even better, PR mitigations), I'm all
> for
> > > it.
> > > >
> > > > -d
> > > >
> > > >
> > > > On December 14, 2021 16:03:39 Joe Kelly  wrote:
> > > >
> > > >> I was wondering if the log4net service has a similar vulnerability
> as
> > > >> log4j. There isn't any information on the log4net security page and
> > > >> the current version of 2.0.13 doesn't match the log4j version of
> > 2.16.0.
> > > >>
> > > >> Joe Kelly
> > > >> Information Security Analyst
> > > >> P: 405.763.5425
> > > >> F: 405.602.6337
> > > >>
> > https://urldefense.com/v3/__http://www.okcu.org__;!!FbZ0ZwI3Qg!6hdye55
> > > <
> https://urldefense.com/v3/__http://www.okcu.org__;!!FbZ0ZwI3Qg!6hdye55>
> > > >> e93GuHBF0X4qMKophICSr0Nb5ggI6RBgb2lJoysQv8jdWynWoouaTpixMWg$
> > > >> <
> > https://urldefense.com/v3/__https://www.okcu.org__;!!FbZ0ZwI3Qg!6hdye
> > > <https://urldefense.com/v3/__https://www.okcu.org__;!!FbZ0ZwI3Qg!6hdye
> >
> > > >> 55e93GuHBF0X4qMKophICSr0Nb5ggI6RBgb2lJoysQv8jdWynWoouYBYxYhmg$ >
> > > >>
> > > >> joe.ke...@okcu.org <mailto:joe.ke...@okcu.org>  > > joe.ke...@okcu.org <mailto:joe.ke...@okcu.org>> Oklahoma's Credit
> Union
> > > >> Happy to Help(r)
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> 
> > > >>
> > > >> NOTICE:
> > > >> This e-mail is intended solely for the use of the individual to whom
> > > >> it is addressed and may contain information that is privileged,
> > > >> confidential or otherwise exempt from disclosure. If the reader of
> > > >> this e-mail is not the intended recipient or the employee or agent
> > > >> responsible for delivering the message to the intended recipient,
> you
> > > >> are hereby notified that any dissemination, distribution, or copying
> > > >> of this communication is strictly prohibited. If you have received
> > > >> this communication in error, please immediately notify us by
> replying
> > > >> to the original message at the listed email address.
> > > >>
> > > >> Happy to Help
> > > >> Oklahoma's Credit Union
> > > >>
> > https://urldefense.com/v3/__http://www.okcu.org__;!!FbZ0ZwI3Qg!6hdye55
> > > <
> https://urldefense.com/v3/__http://www.okcu.org__;!!FbZ0ZwI3Qg!6hdye55>
> > > >> e93GuHBF0X4qMKophICSr0Nb5ggI6RBgb2lJoysQv8jdWynWoouaTpixMWg$
> > > >
> > > > INTERNAL - NI CONFIDENTIAL
> > >
> > >
> >
> > --
> > Dominik Psenner
> >
>
>
> --
> Regards
> Mayank
>

Answering FAQ regarding recent CVEs, was: log4net

[Dominik Psenner]

This question has been asked several times now. I'm proposing to update the
website so that it is more obvious that log4net and log4xx are not affected.

On Tue, 14 Dec 2021 at 17:48, Matt Sicker  wrote:

> JNDI is a Java API (Java Naming and Directory Interface) for abstracting
> various networking APIs like LDAP, DNS, etc. It’s not present in .NET or
> C++ (or any non-JVM language), so it does not affect log4net or log4cxx.
> --
> Matt Sicker
>
> > On Dec 14, 2021, at 08:54, David Schwartz  wrote:
> >
> > Hi Joe,
> >
> > Adding to what Davyd wrote.  I just searched the codebase and the
> JndiLookup class (where the log4j vulnerability was found) does not exist
> in log4net.  In fact, there is no code related to jndi at all as far as I
> can see.
> >
> > David
> >
> > -Original Message-
> > From: Davyd McColl mailto:dav...@gmail.com>>
> > Sent: Tuesday, December 14, 2021 4:10 PM
> > To: dev@logging.apache.org <mailto:dev@logging.apache.org>
> > Subject: [EXTERNAL] Re: log4net
> >
> > Hi Joe
> >
> > No, it shouldn't, particularly because we're very different projects, on
> very different platforms, and I understand that the log4j vuln is largely
> linked to a  _dependency_ of log4j. The closest we've had was an xml vuln
> that was patched some time ago.
> >
> > That being said, I'm currently the only maintainer and I definitely have
> written the least code in log4net, so if you or anyone else would like to
> audit for vulnerabilities (and, even better, PR mitigations), I'm all for
> it.
> >
> > -d
> >
> >
> > On December 14, 2021 16:03:39 Joe Kelly  wrote:
> >
> >> I was wondering if the log4net service has a similar vulnerability as
> >> log4j. There isn't any information on the log4net security page and
> >> the current version of 2.0.13 doesn't match the log4j version of 2.16.0.
> >>
> >> Joe Kelly
> >> Information Security Analyst
> >> P: 405.763.5425
> >> F: 405.602.6337
> >> https://urldefense.com/v3/__http://www.okcu.org__;!!FbZ0ZwI3Qg!6hdye55
> <https://urldefense.com/v3/__http://www.okcu.org__;!!FbZ0ZwI3Qg!6hdye55>
> >> e93GuHBF0X4qMKophICSr0Nb5ggI6RBgb2lJoysQv8jdWynWoouaTpixMWg$
> >> <https://urldefense.com/v3/__https://www.okcu.org__;!!FbZ0ZwI3Qg!6hdye
> <https://urldefense.com/v3/__https://www.okcu.org__;!!FbZ0ZwI3Qg!6hdye>
> >> 55e93GuHBF0X4qMKophICSr0Nb5ggI6RBgb2lJoysQv8jdWynWoouYBYxYhmg$ >
> >>
> >> joe.ke...@okcu.org <mailto:joe.ke...@okcu.org>  joe.ke...@okcu.org <mailto:joe.ke...@okcu.org>> Oklahoma's Credit Union
> >> Happy to Help(r)
> >>
> >>
> >>
> >>
> >>
> >> 
> >>
> >> NOTICE:
> >> This e-mail is intended solely for the use of the individual to whom
> >> it is addressed and may contain information that is privileged,
> >> confidential or otherwise exempt from disclosure. If the reader of
> >> this e-mail is not the intended recipient or the employee or agent
> >> responsible for delivering the message to the intended recipient, you
> >> are hereby notified that any dissemination, distribution, or copying
> >> of this communication is strictly prohibited. If you have received
> >> this communication in error, please immediately notify us by replying
> >> to the original message at the listed email address.
> >>
> >> Happy to Help
> >> Oklahoma's Credit Union
> >> https://urldefense.com/v3/__http://www.okcu.org__;!!FbZ0ZwI3Qg!6hdye55
> <https://urldefense.com/v3/__http://www.okcu.org__;!!FbZ0ZwI3Qg!6hdye55>
> >> e93GuHBF0X4qMKophICSr0Nb5ggI6RBgb2lJoysQv8jdWynWoouaTpixMWg$
> >
> > INTERNAL - NI CONFIDENTIAL
>
>

-- 
Dominik Psenner

Re: Cek's new log4j vs logback benchmark

[Dominik Psenner]

May a ringbuffer cache be a viable solution?

Knowing the resolution (ticks, microseconds, milliseconds, seconds,..), a
key could be generated to lookup and return a previously created formatted
string from a ringbuffer or create it on the fly and store it for later.
During bursts of log events, this could significantly improve performance.
The ringbuffer may even be very small, only depending on the requested
resolution.

Cheers
Dominik
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sat, Aug 28, 2021, 09:40 Ralph Goers  wrote:

> If you look at log4j-perf you will see both a TimeFormatBenchmark and a
> ClocksBenchmark. The time
> benchmark doesn’t include java.time’s formatter but I am pretty sure I
> added it to find that it was still
> slower than our formatters. However, the TimeFormat benchmark tests using
> System.currentTimeMillis
>  - it doesn’t use a Clock. So there really isn’t a perf test for all the
> various ways the Date Converter
> could be implemented.
>
> Actually, having a background thread for the date is an interesting idea
> but I don’t think I would have the
> thread create dates that might be used. Instead, I would look to see if
> there is a way to request the date
> be formatted asynchronously so that when the DateConverter actually needs
> it it is already available. The
> trick to this would be to know that a date is going to be requested
> similar to how we check whether
> location information is required. Then the async thread could add the
> formatted time to the log event.
> The only downside to this is that it assumes the date formatting thread
> will actually run before the Date
> Converter needs the data.
>
> The problem with pre-formatting is that we would have to determine the
> frequency with which log events
> arrive. It doesn’t do any good to format the next 32K milliseconds if
> logging occurs once per second. And
> it doesn’t do any good to format once per second just to have it suddenly
> start generating 10 events per
> second.
>
>
> Ralph
>
> > On Aug 27, 2021, at 11:16 PM, Ron Grabowski 
> wrote:
> >
> > Follow-up to "Formatting the date is expensive. The process of actually
> formatting a value is reasonable". Is this still an issue from LOG4J2-930:
> > %m %ex%n: 1,755,573 msg/sec%d %m %ex%n: 1,194,184 msg/sec
> > If so, isn't date rendering essentially a sequence we can generate ahead
> of time similar to how a local ID generator asks for an allocation of keys
> then uses that to quickly assign IDs to new objects? When its time to
> render %d we can just grab it via an index:
> >
> > 1)At startup calculate the next 32k formatted dates. If
> Clock.currentTimeMillis() were configured down to the second, 32000 seconds
> would pre-allocate %d for the next 8 hours.
> > 2)Apply math to Clock.currentTimeMillis() to get an index into the
> buffer. Seconds precision:
> > [10] = "2021-08-28 09:44:31,000"
> > [11] = "2021-08-28 09:44:32,000"[12] = "2021-08-28 09:44:33,000"[13] =
> "2021-08-28 09:44:34,000"[14] = "2021-08-28 09:44:35,000"[15] = "2021-08-28
> 09:44:36,000"...[31999] = "..."
> > 50ms precision:
> > [10] = "2021-08-28 09:44:31,050"[11] = "2021-08-28 09:44:31,075"[12] =
> "2021-08-28 09:44:31,100"[13] = "2021-08-28 09:44:31,150"[14] = "2021-08-28
> 09:44:31,175"[15] = "2021-08-28 09:44:31,200"...[31999] = "..."
> >
> > 3)Rendering %d{SEQ(DEFAULT,32000)} is just a index lookup into the
> sequence of 32000 pre-calculated %d{DEFAULT} values without the cost of
> formatting. I made up the "SEQ" notation, there's likely a better way to
> express the feature. Everything can read from the buffer without locking.
> > 4)Have a background thread casually keep the sequence filled in a ring
> so dates in the past are replaced with future dates so the structure
> consumes a consistent amount of memory.
> >On Friday, August 27, 2021, 10:07:59 PM EDT, Carter Kozak <
> cko...@ckozak.net> wrote:
> >
> > Thanks, Remko. The default '%d' uses FixedDateFormat with
> FixedFormat.DEFAULT. The FastDateFormat alternative does not support
> microseconds, so it doesn't suffer from the same problem. I think I can
> substantially reduce the frequency we re-format dates by checking
> FixedFormat.secondFractionDigits to determine if we meed to compare
> microseconds.
> >
> > On Fri, Aug 27, 2021, at 16:10, Remko Popma wrote:
> >> I remember looking at PatternLayout performance, I reported my findings
> here, hopefully they’re still useful:
> https://issues.apache.org/jira/browse/LOG4J2-930
> >>
> >> If %d is used in the pattern, does the FixedDateFormat get used?
> >>
> >>
> >>
> >>
> >>> On Aug 28, 2021, at 4:33, Ralph Goers 
> wrote:
> >>>
> >>> All of that agrees with my observations as well.
> >>>
> >>> Ralph
> >>>
>  On Aug 27, 2021, at 12:23 PM, Carter Kozak  wrote:
> 
>  I've identified a few things that seem impactful, but bear in mind
> that I haven't begun to drill down into them yet. I plan to file individual
> tickets and 

Re: [general] Recommended event log storage?

[Dominik Psenner]

Hi

I like Json as the transport format over mqtt. A few hundred lines of code
persist events to a postgresql database by calling a stored procedure that
handles the json directly. The stored procedure allows for plugging in some
fancy aggregation logic or distribution across tables or even retention
during persistency and if applied gradually with very little impact. This
has the benefit of no hours of downtime to delete millions of records that
would require a rebuild of the table otherwise. The stored procedure can
even be modified at runtime. And when the requirements become too tough for
the database to handle, the mqtt pub/sub system allows plugging in
additional processors like aggregators, alerters, ...

Warm regards,
Dominik
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Wed, Aug 4, 2021, 10:04 Volkan Yazıcı  wrote:

> We have our Redis-shielded ELK stack – Redis acts as a buffer for
> fluctuating Elasticsearch ingestion performance and downtime. Apps use
> log4j2-redis-appender , not
> the official Log4j one. This said, I am lobbying for replacing Redis with
> Google Cloud Pub/Sub – one less managed component to worry about. (Yes, my
> Google Cloud Pub/Sub appender PR is on the horizon!)
>
> I have heavily used Elasticsearch for both "search" (as in "Google search")
> and log sink purposes, professionally, for 5+ years. IMHO, in both use
> cases, it is the best tool in the F/OSS market that delivers. I did not
> understand your remark that Elasticsearch is geared toward "relatively
> short time period" retention. I have seen deployments spanning thousands of
> nodes with a couple of years of retention. It just works.
>
> If you are in the cloud, there are pretty good log sink solutions too,
> e.g., Google Cloud Logging. All your worries about retention and
> maintenance will be perfectly addressed there, granted you are willing to
> pay for that.
>
> If you need logging for auditing purposes, e.g., "mark this money transfer
> as completed", you are doing it wrong, I think. Most of the time, the
> shebang that happens after your log() statement is executed asynchronously
> at many layers, hence, failures don't propagate back. For one, all Log4j
> threads are daemon threads and will be killed upon a JVM exit without
> flushing their buffers. Indeed this is a controversial subject and one can
> possibly engineer a reliable logging infra, yet, again, I think this is the
> wrong tool for the job.
>
> Regarding DBMS log sinks, e.g., PostgreSQL, MySQL, MongoDB, Cassandra, they
> are good for persistence, scrolling through records, etc., but not for
> aggregation queries. I see two main issues that they fall short of
> addressing in my experience: 1) Many users reach out to queries combined
> with aggregations (e.g., show me a histogram of mdc.httpStatusCode in the
> last month for this long query of mine) and RDBMSes are tremendously slow
> compared to Elasticsearch/Lucene for such queries. One can argue that this
> is abusing logging for metrics. Yet, there it is. 2) Certain RDBMSes are
> darn difficult to (horizontally) scale, unless it is provided
> out-of-the-box.
>
> On Tue, Aug 3, 2021 at 6:50 PM Matt Sicker  wrote:
>
> > Hey all, I have a somewhat practical question related to logging here.
> > For those of you maintaining a structured event log or audit log of
> > some sort, what types of event log stores are you using to append them
> > to? I feel like solutions like Splunk, ELK, etc., are geared toward
> > diagnostic logs which don't necessarily need retention beyond a
> > relatively short time period. On the other hand, one of the more
> > natural append-only storage solutions I can think of is Kafka, though
> > that, too, isn't really geared toward long term storage (even if I can
> > theoretically fit the entire audit log on one machine). I've been
> > considering potentially using Cassandra here for durability and append
> > speed, but even that seems overkill since I don't want or need to be
> > able to ever update a log event after it's been stored. I've also
> > considered having Kafka as a layer in between, but that just feels
> > like overengineering as I don't expect event logs to populate nearly
> > as fast as, say, wind turbine sensor data where I last used that
> > architectural pattern.
> >
> > I'm curious if anyone has experience with building their own event log
> > storage service or using an existing one along with any advice.
> >
>

Re: Any plans to release log4j TCP server?

[Dominik Psenner]

Hi,

I would rather advise to not reinvent the wheel of tcp communication but
implement some simplistic mqtt appender that transports log events as json
serialized messages.

In combination with a broker like mosquitto it provides secure
communication, temporary peristent storage and many more advantages of
pub/sub systems like multiple log event consumers and such.

Cheers
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Tue, Jun 29, 2021, 20:46 Gary Gregory  wrote:

> FWIW, we use the server at work to listen to JSON log events. There is
> definitely value there.
>
> Gary
>
> On Tue, Jun 29, 2021, 13:29 Ralph Goers 
> wrote:
>
> > Right now the server is more or less a sample we expect you will want to
> > copy and modify,
> > so releasing it doesn’t have a lot of value.
> >
> > On the “Online Drinks” call this weekend I mentioned that I had been
> asked
> > about being
> > able to send logs from mobile devices to a backend collector securely
> > (https with OAuth
> > tokens). I’ve been thinking about enhancing the server to be able to
> > support this kind of
> > stuff as well as being able to provide something similar to JSON Template
> > Layout to
> > deserialize the log events.
> >
> > If that happens then I would expect the server would be something we
> would
> > want to
> > release and formally support.
> >
> > Ralph
> >
> > > On Jun 29, 2021, at 8:29 AM, Кон�тантин Кракович <
> > kosto@gmail.com> wrote:
> > >
> > > Hi Team,
> > >
> > > Could you please let me know if you have plans to release TCP server
> > from logging-log4j-tools project?
> > >
> > >
> > > Best regards,
> > > Kostyantyn
> > >
> >
> >
> >
>

Re: Revamping website design and logo

[Dominik Psenner]

Hi,

in the past some effort has been made to make all log4xxx project websites
look alike. If the site design should be changed, I propose to expand the
discussion to the other projects.

Greets,
Dominik
--
Sent from my phone.

On Wed, Mar 10, 2021, 18:33 Ralph Goers  wrote:

>
>
> > On Mar 10, 2021, at 9:07 AM, Volkan Yazıcı 
> wrote:
> >
> > My tentative plan is the following:
> >
> >   1. Get a brand new shiny logo!
>
> Why? Not that I am in love with our current logo but it was the winner of
> the logo contest.
>
> >   2. Get a brand new design
> >  - for the landing page (HTML, CSS, and images)
>
> >  - for internal pages directly accessed by the landing page (HTML,
> CSS)
> >  - for AsciiDoc-generated reference manual theme (CSS)
>
> I believe we used to use a custom skin. When I converted the web site to
> GitHub I believe it may have changed to the standard fluid skin since the
> prior skin was somehow embedded in the CMS. If we continue to use the Maven
> Site plugin the skin can be modified by following
> https://maven.apache.org/plugins/maven-site-plugin/examples/creatingskins.html
> <
> https://maven.apache.org/plugins/maven-site-plugin/examples/creatingskins.html
> >.
>
> >   3. Migrate all reference manual to AsciiDoc – we are almost there
>
> I know I ran into a problem with the logging in the cloud page which is
> why I left it markdown.
>
> >   4. Update AsciiDoc theme
> >   5. Restructure existing manual sections and content (this is big!)
> >   6. Create a landing website for Log4j using new designs and JBake,
> which
> >   we already use
> >   7. Make reference manual accessible in two flavors:
> >  1. /doc/reference/latest/index.html
> >  2. /doc/reference//index.html
> >
> > As you might guess, only the first two tasks will be done by the hired
> > professional. The rest is still on our shoulders.
> >
> > Note that the reference manual will still be built from the sources via
> > asciidoc-maven-plugin. Same applies to the landing page generation via
> > JBake. Hence I will only touch the content, not the mechanics.
>
> Actually, only the logging services site uses JBake. All the rest are
> currently using the Maven Site Plugin.
>
> I guess I should say I am assuming you are talking about the Log4j web
> site. If you are talking about the logging services web site then it does
> JBake and could most certainly use an upgrade (not that the log4j web site
> can’t be improved too).
>
> If you want to move Log4j to use JBake that would be a much bigger
> undertaking. As I said things like the Changelog page, Jira issues,
> javadocs, dependency info, etc are all generated by the site plugin.
> Invoking them outside of it might not work since some are only designed to
> work within it.
>
> Ralph

Re: Fwd: [NuGet Gallery] Message for owners of the package 'log4net'

[Dominik Psenner]

Dear Santosh,

please see the answer to Your request below. Please note that Apache
product discussions happen on mailing lists, in this case it is
dev@logging.apache.org. NuGet messages are not an ideal way to communicate
because they reach only a limited subset of the community.

Warm regards,
Dominik

On Fri, 23 Oct 2020 at 20:52, Davyd McColl  wrote:

> Hi Dominik
>
> iirc, this was fixed in 2.0.11. 2.0.12, with another fix for current user
> name on !win32, is waiting on one more +1 vote for release.
>
> -d
>
> On October 23, 2020 18:05:18 Dominik Psenner  wrote:
>
>> See the message below.
>> --
>> Sent from my phone.
>>
>> -- Forwarded message -
>> From: NuGet Gallery 
>> Date: Fri, Oct 23, 2020, 07:51
>> Subject: [NuGet Gallery] Message for owners of the package 'log4net'
>> To: 
>>
>> *User santoshkallatti > > sends the following message
>> to
>> the owners of Package 'log4net 2.0.10
>> <https://www.nuget.org/packages/log4net/2.0.10>'.*
>>
>> Hi,
>>
>> There is an assembly version mismatch in log4net 2.0.10. The assembly's
>> manifest definition contains 'log4net, Version=2.0.9.0'. May I know why
>> this version mismatch. Can I get log4net 2.0.10 nuget package with
>> manifest
>> definition contains 'log4net, Version=2.0.10.0'?
>>
>> Thanks & Regards Santosh K
>> --
>> * To stop receiving contact emails as an owner of this package, sign in to
>> the NuGet Gallery and change your email notification settings
>> <https://www.nuget.org/account>. *
>>
>> Privacy Statement <https://go.microsoft.com/fwlink/?LinkId=521839>
>> Microsoft Corporation
>> One Microsoft Way
>> Redmond, WA 98052 USA
>>
>

-- 
Dominik Psenner

Fwd: [NuGet Gallery] Message for owners of the package 'log4net'

[Dominik Psenner]

See the message below.
--
Sent from my phone.

-- Forwarded message -
From: NuGet Gallery 
Date: Fri, Oct 23, 2020, 07:51
Subject: [NuGet Gallery] Message for owners of the package 'log4net'
To: 


*User santoshkallatti > sends the following message to
the owners of Package 'log4net 2.0.10
'.*

Hi,

There is an assembly version mismatch in log4net 2.0.10. The assembly's
manifest definition contains 'log4net, Version=2.0.9.0'. May I know why
this version mismatch. Can I get log4net 2.0.10 nuget package with manifest
definition contains 'log4net, Version=2.0.10.0'?

Thanks & Regards Santosh K
--
* To stop receiving contact emails as an owner of this package, sign in to
the NuGet Gallery and change your email notification settings
. *


Privacy Statement 
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA

Re: [VOTE] [log4net] Release 2.0.11

[Dominik Psenner]

+1

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Tue, Sep 22, 2020, 08:37 Davyd McColl  wrote:

> Hi all
>
> I'd appreciate any more +1's (thanks, Remko!). I'd like to get this out
> the door because it fixes confusing versioning on the released binaries (in
> particular, nuget consumers)
>
> Thanks
> -d
> On 2020/09/20 22:33:49, Matt Sicker  wrote:
> I can use whatever.
>
> On Sun, 20 Sep 2020 at 15:26, Ralph Goers wrote:
> >
> > I don’t have google meet and I can’t use Skype since Microsoft hosed my
> authentication. I have zoom. My company uses Amazon Chime, which is fairly
> new, as part of our product offering. I’ve sent you both emails for a
> meeting using that.
> >
> > Ralph
> >
> > > On Sep 20, 2020, at 1:01 PM, Matt Sicker wrote:
> > >
> > > I sent a Google Meet invite to you.
> > >
> > > On Sun, 20 Sep 2020 at 14:26, Davyd McColl wrote:
> > >>
> > >> I'm happy to be available at 8am my side, if that works for everyone
> else.
> > >> It sounds like earlier would be better, but I'm doing the morning
> school
> > >> run from 7am and can't guarantee I'll be back significantly before
> 8am.
> > >>
> > >> How to do this? I have zoom and slack on my work machine, can install
> > >> Skype if that's more convenient, can do google meet, I assume, though
> > >> haven't ever tried, so may need a bit of a crash intro.
> > >>
> > >> If posting meeting details to the mailing list is not on, feel free to
> > >> email me directly (:
> > >>
> > >> -d
> > >>
> > >>
> > >> On September 20, 2020 20:58:29 Ralph Goers wrote:
> > >>
> > >>> 8am in Durban South Africa is 11pm the night before in Phoenix AZ.
> > >>> However, I frequently am up until midnight so that could work.
> 5-5:30 pm is
> > >>> 7:30-8 am in Phoenix. I usually am not in front of my computer on a
> weekday
> > >>> until 8 am but on occasion I can do earlier.
> > >>>
> > >>> Ralph
> > >>>
> >  On Sep 20, 2020, at 9:46 AM, Davyd McColl wrote:
> > 
> >  Any time 08h00 - 17h30 utc+2, except 13h00-14h00 (that's when I
> fetch my
> >  son from school)
> > 
> >  -d
> > 
> > 
> >  On September 20, 2020 18:44:19 Matt Sicker wrote:
> > 
> > > We’re not quite as strict as Debian for keys (though if you can
> find a
> > > Debian group locally, they’re great for key signing). The video
> call idea
> > > could work for exchanging keys. What times would you be available
> to do
> > > that?
> > >
> > > On Sun, Sep 20, 2020 at 03:09 Davyd McColl wrote:
> > >
> > >> Hi Ralph
> > >>
> > >>
> > >>
> > >> I think I miscommunicated: I'm not regenerating my signing key -
> just the
> > >>
> > >> nuget API key for package upload. This forces me to log in in
> nuget.org
> > >>
> > >> which has 2fa and then I only use that key on the cli for the
> immediate
> > >> upload.
> > >>
> > >>
> > >>
> > >> My gpg key as at https://GitHub.com/fluffynuts.gpg is the same
> that I
> > >> used
> > >>
> > >> last time.
> > >>
> > >>
> > >>
> > >> -d
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On September 20, 2020 09:01:36 Ralph Goers
> > >> wrote:
> > >>
> > >>
> > >>
> > >>> In the long run you don’t want to be regenerating your signing
> key for
> > >>
> > >>> every release. The point is that you would upload the key to a
> central
> > >>
> > >>> keystore and other people would sign it there. At ApacheCon we
> would
> > >> have a
> > >>
> > >>> key signing “party” where we recorded each others keys and then
> would
> > >> take
> > >>
> > >>> our list and update the central keystore. When people verify the
> key
> > >> they
> > >>
> > >>> can look at the keystore and see that it is signed by a number of
> > >> people,
> > >>
> > >>> who then have their keys by a number of people and so on so you
> are
> > >>
> > >>> building a web of trust. Sooner or later there will be someone
> in that
> > >> web
> > >>
> > >>> that you personally know and trust.
> > >>
> > >>>
> > >>
> > >>> Ralph
> > >>
> > >>>
> > >>
> >  On Sep 19, 2020, at 11:26 PM, Davyd McColl wrote:
> > >>
> > 
> > >>
> >  Thanks Matt, I've updated the artifacts on GitHub to have
> detached
> > >>
> >  signatures. I had previously also uploaded my key to
> sks-keyservers.net,
> > >>
> > >>
> >  but I've also uploaded to MIT, though search there always times
> out.
> > >>
> > 
> > >>
> >  The document you've linked mentions face-to-face interactions
> to get my
> > >> key
> > >>
> >  into the official KEYS file. Not sure how many apache people
> are at my
> > >> end
> > >>
> >  of the world (Durban, South Africa), but I can do an online
> meeting if
> > >> that
> > 

Fwd: [NuGet Gallery] Message for owners of the package 'log4net'

[Dominik Psenner]

See the message below. Apparently something went wrong during the last
release.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

-- Forwarded message -
From: NuGet Gallery 
Date: Fri, Sep 18, 2020, 12:10
Subject: [NuGet Gallery] Message for owners of the package 'log4net'
To: 


*User andyfisher100 >
sends the following message to the owners of Package 'log4net 2.0.10
'.*

When 2.0.10 was released, the version of the dlls was not changed to match
the package version. All of the dlls remain at version 2.0.9
--
* To stop receiving contact emails as an owner of this package, sign in to
the NuGet Gallery and change your email notification settings
. *


Privacy Statement 
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA

Re: [VOTE] [log4net] Release 2.0.10

[Dominik Psenner]

+1

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Fri, Sep 11, 2020, 08:08 Remko Popma  wrote:

> +1
> Remko.
>
>
>
> (Shameless plug) Every java main() method deserves http://picocli.info
>
> > On Sep 10, 2020, at 15:24, Davyd McColl  wrote:
> >
> > Hi all
> >
> > I realise that I'm causing a bit of a headache by sending mails from my
> work account. I'm trying to be more vigilant when sending from my mail
> client, but perhaps I need to find a better way, because I just managed to
> send again from that account this morning, and I understand that may mean
> that messages aren't getting through. I apologise, especially to Ralph,
> who, I understand, has had to manually marshal some of my mails through ):
> >
> > Please can we get a vote going on this release as it
> > a) sorts out the CVE that people have been so interested in
> > b) improves things significantly for netstandard 2.0 users
> >
> > Thanks
> > -d
> > On 2020/09/07 21:15:42, Davyd McColl  wrote:
> > Hi Dominik
> > No, it doesn't. Netstandard 2.0 support is added in addition to the
> existing netstandard 1.3 target.
> > Whilst I'd really like to diminish the target list of the package
> (particularly the client profile targets), I'd only be comfortable doing so
> on a major version change, and I think that mostly I just want to deprecate
> client profiles to enable easier cross-platform dev (those are the only
> targets I haven't had joy supporting on Linux so far)
> > -d
> >
> > On September 7, 2020 19:55:51 Dominik Psenner 
> wrote:
> > Hi
> > Does this break support for netstandard1.3 and enforces users to update
> all
> > their dependants?
> > Best regards
> > --
> > Sent from my phone. Typos are a kind gift to anyone who happens to find
> > them.
> > On Sun, Sep 6, 2020, 21:04 Davyd McColl  wrote:
> > Hi all
> >
> > I'd like to propose a vote to release 2.0.10 of log4net, with:
> > - updated netstandard 2.0 support from community member NicholasNoise
> > - cherry-picked fix for CVE-2018-1285 (I had to modify slightly since the
> > mechanism used there is outdated for netstandard 2.0, but the principle
> > stands
> >
> > I've created an RC release at
> > GitHub:
> https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1 [
> https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1] and
> > pushed updated site material to the `asf-staging` branch of the
> > logging-log4net-site repo.
> >
> > Thanks
> > -d
>

Re: [VOTE] [log4net] Release log4net 2.0.10

[Dominik Psenner]

Knowing that those changes are intentional I am confident that the next
release is better than the last. This is reason enough to move on. If
something breaks we can still address those issues with another future
release.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Thu, Sep 10, 2020, 09:20 Davyd McColl  wrote:

> Hi Dominik
>
> I have had a long look over the changes (both via the PR and locally, as I
> contributed to help with some infra changes) and I'm happy -- there's been
> a lot of clean-up and simplification and in addition, tests are now run
> against all targets -- so that's a good thing. Some of these changes are
> required to resolve issues for netstandard2.0 users who have upgraded to
> 2.0.9. Community member NicholasNoise put in a lot of work on this.
>
> If it helps, the original PR is here:
> https://github.com/apache/logging-log4net/pull/63 -- it makes viewing
> changes a lot simpler. Changes to a lot of the #ifdefs are updates from
> NETSTANDARD1_3 to simply NETSTANDARD as many of the changes required for
> netstandard2.0 are compatible. I contributed on that PR too, mainly around
> getting build to work as expected.
>
> You're welcome to use the npm-based build / test pipeline to verify: I've
> just updated master to automatically test across all platforms when running
> `npm test`, so it should be easy to verify that all things are functional:
> - install node if you don't have it yet (I suggest via nvm)
> - `npm ci`
> - `npm test`
>
> (assuming that you have all the required build targets -- there are helper
> .ps1 scripts to get the older targets -- netcore 1.1 and netfx35)
>
> -d
>
>
> On 2020/09/10 09:03:45, Dominik Psenner  wrote:
> Hi
>
> Sorry to not have responded earlier. Time is short and the days are busy. I
> looked at the diff and found several suspicious changes. Several hundred
> ifdefs have been removed/replaced along with tests. Therefore I have a bad
> feeling about those changes without further careful checking. I propose to
> release the cve fix alone and follow up a second release as soon as someone
> had the time to verify that the netstandard2 changes are ok.
>
> Best regards
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
>
> On Thu, Sep 10, 2020, 08:48 Davyd McColl wrote:
>
> > Hi
> >
> > Sorry to be a bother, but I haven't heard anything back on this apart
> from
> > Dominik's inquiry into netstandard 1.3 support. I'd really like to get
> this
> > out as:
> > a) it contains the CVE fix that has been asked about so much
> > b) it solves some issues affecting netstandard users
> >
> > Thanks
> > -d
> >
> > On 2020/09/06 20:51:38, Davyd McColl wrote:
> > Hi all
> >
> > I'd like to propose a vote to release 2.0.10 of log4net, with:
> > - updated netstandard 2.0 support from community member NicholasNoise
> > - cherry-picked fix for CVE-2018-1285 (I had to modify slightly since the
> > mechanism used there is outdated for netstandard 2.0, but the principle
> > stands
> >
> > I've created an RC release at GitHub:
> > https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1 and
> > pushed updated site material to the `asf-staging` branch of the
> > logging-log4net-site repo.
> >
> > Thanks
> > -d
>

Re: [VOTE] [log4net] Release log4net 2.0.10

[Dominik Psenner]

Hi

Sorry to not have responded earlier. Time is short and the days are busy. I
looked at the diff and found several suspicious changes. Several hundred
ifdefs have been removed/replaced along with tests. Therefore I have a bad
feeling about those changes without further careful checking. I propose to
release the cve fix alone and follow up a second release as soon as someone
had the time to verify that the netstandard2 changes are ok.

Best regards
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Thu, Sep 10, 2020, 08:48 Davyd McColl  wrote:

> Hi
>
> Sorry to be a bother, but I haven't heard anything back on this apart from
> Dominik's inquiry into netstandard 1.3 support. I'd really like to get this
> out as:
> a) it contains the CVE fix that has been asked about so much
> b) it solves some issues affecting netstandard users
>
> Thanks
> -d
>
> On 2020/09/06 20:51:38, Davyd McColl  wrote:
> Hi all
>
> I'd like to propose a vote to release 2.0.10 of log4net, with:
> - updated netstandard 2.0 support from community member NicholasNoise
> - cherry-picked fix for CVE-2018-1285 (I had to modify slightly since the
> mechanism used there is outdated for netstandard 2.0, but the principle
> stands
>
> I've created an RC release at GitHub:
> https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1 and
> pushed updated site material to the `asf-staging` branch of the
> logging-log4net-site repo.
>
> Thanks
> -d

Re: [NuGet Gallery] Message for owners of the package 'log4net'

[Dominik Psenner]

Unfortunately there was no option to do that. Nuget provides this mechanism
to establish a communication channel from the consumer to the owner of a
package. It would be great if there was an option to do so today.

Can infra subscribe nuget to a mailing list without the confirmation of the
owner of the mail?
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Tue, Sep 8, 2020, 20:21 Ralph Goers  wrote:

> I don’t disagree with that at all. But I am wondering if it would not have
> been better to not provide an email link from NuGet at all and force the
> user to follow the link to the web site.
>
> Ralph
>
> > On Sep 8, 2020, at 11:17 AM, Dominik Psenner  wrote:
> >
> > This reflects my impression that the volume of individuals that do not
> know
> > the mechanics of the mailing lists has increased. I observe that with the
> > increased number of messages that need to be moderated. Many come from
> > individuals that are not subscribes. Others come from individuals that
> send
> > messages from multiple email addresses. And others come from nuget. In
> all
> > cases we can improve the situation by improving the documentation.
> >
> > Despite that, I repeat that a moderator must act as an intelligent proxy
> > that keeps confidential information private and moves anything else to
> dev.
> > To me that choice cannot be made when moderating the message because a
> > reject from the moderator causes the  message to bounce and by asf rules
> it
> > would never have existed. That was the reasoning when I chose private as
> > the email when establishing the nuget organization.
> >
> > --
> > Sent from my phone. Typos are a kind gift to anyone who happens to find
> > them.
> >
> > On Tue, Sep 8, 2020, 20:04 Davyd McColl  wrote:
> >
> >> True that, but I tried to initiate a vote the other day from my work
> mail
> >> by mistake and the message was bounced, so I'm not sure what rules apply
> >> to
> >> this list. If it's fairly open, it might be a plan to update the
> >> associated
> >> email address on nuget to the dev list.
> >>
> >> -d
> >>
> >>
> >> On September 8, 2020 19:08:55 Matt Sicker  wrote:
> >>
> >>> That's this dev list! Though if we need a separate mailing list, we
> >>> can always create more.
> >>>
> >>> On Tue, 8 Sep 2020 at 11:54, Davyd McColl  wrote:
> >>>>
> >>>> What if there was another Apache email address that messages were sent
> >> to,
> >>>> and multiple people could observe that account? I don't mind being one
> >> of
> >>>> the lucky ones if it will help (:
> >>>>
> >>>> -d
> >>>>
> >>>>
> >>>> On September 8, 2020 17:47:57 Matt Sicker  wrote:
> >>>>
> >>>>> The main problem with sending nuget info to the PMC is that nobody in
> >>>>> the PMC are working on log4net besides validating releases ;)
> >>>>>
> >>>>> On Tue, 8 Sep 2020 at 04:37, Dominik Psenner 
> >> wrote:
> >>>>>>
> >>>>>> In the past security vulnerabilities were reported via nuget and it
> >> is not
> >>>>>> a good idea to publish those in an automated way.
> >>>>>>
> >>>>>> I suggest to update the nuget project documentation and prominently
> >> point
> >>>>>> to our mailing lists and discourage the communication via nuget.
> >> Users may
> >>>>>> continue sending messages via nuget to pmc but hopefully the volume
> >> is
> >>>>>> reduced. Unfortunately most users consume log4net via nuget and
> >> apparently
> >>>>>> do not care about the mailing list and/or the official project
> >> website.
> >>>>>>
> >>>>>> --
> >>>>>> Sent from my phone. Typos are a kind gift to anyone who happens to
> >> find
> >>>>>> them.
> >>>>>>
> >>>>>> On Tue, Sep 8, 2020, 08:34 Davyd McColl  wrote:
> >>>>>>
> >>>>>>> Ralph
> >>>>>>>
> >>>>>>> I understand that the emails provide a bit of workload, and I'm
> >> trying to
> >>>>>>> figure out a solution to help everyone -- obviously there are
> >> people who
> >>>>>>

Re: Fwd: [NuGet Gallery] Message for owners of the package 'log4net'

[Dominik Psenner]

This reflects my impression that the volume of individuals that do not know
the mechanics of the mailing lists has increased. I observe that with the
increased number of messages that need to be moderated. Many come from
individuals that are not subscribes. Others come from individuals that send
messages from multiple email addresses. And others come from nuget. In all
cases we can improve the situation by improving the documentation.

Despite that, I repeat that a moderator must act as an intelligent proxy
that keeps confidential information private and moves anything else to dev.
To me that choice cannot be made when moderating the message because a
reject from the moderator causes the  message to bounce and by asf rules it
would never have existed. That was the reasoning when I chose private as
the email when establishing the nuget organization.

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Tue, Sep 8, 2020, 20:04 Davyd McColl  wrote:

> True that, but I tried to initiate a vote the other day from my work mail
> by mistake and the message was bounced, so I'm not sure what rules apply
> to
> this list. If it's fairly open, it might be a plan to update the
> associated
> email address on nuget to the dev list.
>
> -d
>
>
> On September 8, 2020 19:08:55 Matt Sicker  wrote:
>
> > That's this dev list! Though if we need a separate mailing list, we
> > can always create more.
> >
> > On Tue, 8 Sep 2020 at 11:54, Davyd McColl  wrote:
> >>
> >> What if there was another Apache email address that messages were sent
> to,
> >> and multiple people could observe that account? I don't mind being one
> of
> >> the lucky ones if it will help (:
> >>
> >> -d
> >>
> >>
> >> On September 8, 2020 17:47:57 Matt Sicker  wrote:
> >>
> >> > The main problem with sending nuget info to the PMC is that nobody in
> >> > the PMC are working on log4net besides validating releases ;)
> >> >
> >> > On Tue, 8 Sep 2020 at 04:37, Dominik Psenner 
> wrote:
> >> >>
> >> >> In the past security vulnerabilities were reported via nuget and it
> is not
> >> >> a good idea to publish those in an automated way.
> >> >>
> >> >> I suggest to update the nuget project documentation and prominently
> point
> >> >> to our mailing lists and discourage the communication via nuget.
> Users may
> >> >> continue sending messages via nuget to pmc but hopefully the volume
> is
> >> >> reduced. Unfortunately most users consume log4net via nuget and
> apparently
> >> >> do not care about the mailing list and/or the official project
> website.
> >> >>
> >> >> --
> >> >> Sent from my phone. Typos are a kind gift to anyone who happens to
> find
> >> >> them.
> >> >>
> >> >> On Tue, Sep 8, 2020, 08:34 Davyd McColl  wrote:
> >> >>
> >> >> > Ralph
> >> >> >
> >> >> > I understand that the emails provide a bit of workload, and I'm
> trying to
> >> >> > figure out a solution to help everyone -- obviously there are
> people who
> >> >> > submit mails (and wonder where they went) and people who have to
> handle
> >> >> > those mails.
> >> >> >
> >> >> > We use Trello at work and have built our own custom solution which
> bridges
> >> >> > Trello and email (called Sendboard). It looks like
> >> >> >
> >> >>
> >>
> https://community.atlassian.com/t5/Jira-questions/create-ticket-from-email-in-jira/qaq-p/806165
> >> >> > gives an idea of how to do something similar for JIRA. Would that
> perhaps
> >> >> > help to make things flow a bit better?
> >> >> >
> >> >> > Unlike npmjs.com, nuget.org doesn't provide a mechanism for a
> quick link
> >> >> > to an issues board -- the best I can see is either the project url
> or the
> >> >> > associated email address (which is probably why most people reach
> out on
> >> >> > email). So the possible solutions I see here are to
> >> >> > - automate handling the email
> >> >> > - make the issue reporting url clearer on the project page.
> >> >> >
> >> >> > The project url links to logging.apache.org/log4net -- perhaps I
> should
> >> >> > update the landing page to include a more obvious li

Re: Fwd: [NuGet Gallery] Message for owners of the package 'log4net'

[Dominik Psenner]

In the past security vulnerabilities were reported via nuget and it is not
a good idea to publish those in an automated way.

I suggest to update the nuget project documentation and prominently point
to our mailing lists and discourage the communication via nuget. Users may
continue sending messages via nuget to pmc but hopefully the volume is
reduced. Unfortunately most users consume log4net via nuget and apparently
do not care about the mailing list and/or the official project website.

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Tue, Sep 8, 2020, 08:34 Davyd McColl  wrote:

> Ralph
>
> I understand that the emails provide a bit of workload, and I'm trying to
> figure out a solution to help everyone -- obviously there are people who
> submit mails (and wonder where they went) and people who have to handle
> those mails.
>
> We use Trello at work and have built our own custom solution which bridges
> Trello and email (called Sendboard). It looks like
> https://community.atlassian.com/t5/Jira-questions/create-ticket-from-email-in-jira/qaq-p/806165
> gives an idea of how to do something similar for JIRA. Would that perhaps
> help to make things flow a bit better?
>
> Unlike npmjs.com, nuget.org doesn't provide a mechanism for a quick link
> to an issues board -- the best I can see is either the project url or the
> associated email address (which is probably why most people reach out on
> email). So the possible solutions I see here are to
> - automate handling the email
> - make the issue reporting url clearer on the project page.
>
> The project url links to logging.apache.org/log4net -- perhaps I should
> update the landing page to include a more obvious link to reporting issues?
> There is already a link in the project's README.md which surfaces on
> GitHub. At the end of the day, I'd like the situation to be better for both
> the PMC and users. I'm open to any suggestions.
>
> -d
>
> On 2020/09/08 07:24:25, Davyd McColl  wrote:
> Hi Ralph
> I'll investigate this today. I'd like more information, particularly
> configuration and, eg if the ado.net [http://ado.net] appender is used,
> table structures.
> Joseph, please open a ticket at
> https://issues.apache.org/jira/browse/LOG4NET [
> https://issues.apache.org/jira/browse/LOG4NET] to help me track this.
> -d
>
> On September 7, 2020 23:35:12 Ralph Goers 
> wrote:
> For some reason all messages from NuGet are routed to the Apache Logging
> PMC list. This one clearly does not need to be private. Just know that the
> person who sent this is apparently not subscribed to the ASF mailing lists
> so won’t see a response unless he is cc’d.
> I’m not familiar with NuGet but it sure would be nice if they could be
> pointed to our mailing lists. The PMC has gotten a fair number of these
> that we have tried to respond to.
> Ralph
> Begin forwarded message:
> From: NuGet Gallery 
> Subject: [NuGet Gallery] Message for owners of the package 'log4net'
> Date: September 7, 2020 at 2:25:32 PM MST
> To: 
> Reply-To: "Logging PMC" 
> Reply-To: 
> User jmitola  sends the following message to the
> owners of Package 'log4net 2.0.8 <
> https://www.nuget.org/packages/log4net/2.0.8 [
> https://www.nuget.org/packages/log4net/2.0.8]>'.
> Has version 2.0.9 been thoroughly tested running in .Net framework 4.6? I
> ask because I recently upgraded from 2.0.8 which was working with no issues
> to version 2.0.9. Now, it completely crashes the application pool in IIS
> for any application running .Net framework v4.5 and higher which has
> referenced the log4net library v2.0.9. Furthermore, it will not output any
> error logs even with internal logging option turned on. Do you have any
> suggestions as to how I could debug this?
> Thanks, Joseph
> To stop receiving contact emails as an owner of this package, sign in to
> the NuGet Gallery and change your email notification settings <
> https://www.nuget.org/account [https://www.nuget.org/account]>.
> Privacy Statement  https://go.microsoft.com/fwlink/?LinkId=521839]>
> Microsoft Corporation
> One Microsoft Way
> Redmond, WA 98052 USA
>
>

Re: [VOTE] [log4net] Release 2.0.10

[Dominik Psenner]

Hi

Does this break support for netstandard1.3 and enforces users to update all
their dependants?

Best regards
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sun, Sep 6, 2020, 21:04 Davyd McColl  wrote:

> Hi all
>
>
> I'd like to propose a vote to release 2.0.10 of log4net, with:
>
> - updated netstandard 2.0 support from community member NicholasNoise
>
> - cherry-picked fix for CVE-2018-1285 (I had to modify slightly since the
> mechanism used there is outdated for netstandard 2.0, but the principle
> stands
>
>
> I've created an RC release at
> GitHub: https://github.com/apache/logging-log4net/releases/tag/v2.0.10-rc1 and
>
> pushed updated site material to the `asf-staging` branch of the
> logging-log4net-site repo.
>
>
> Thanks
>
> -d
>
>

Log4net: 2.0.9 release notes missing

[Dominik Psenner]

Hi

People noticed that the release notes of 2.0.9 are missing while they
should be documented here:

http://logging.apache.org/log4net/release/release-notes.html

Best regards
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

Log4net: Insecure site url on nuget

[Dominik Psenner]

Hi,

I noticed that the site url of the log4net nuget package is http instead of
https (http://logging.apache.org/log4net/) and propose to update it. See:

https://www.nuget.org/packages/log4net/

Best regards
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

Re: [VOTE] Release Log4Net 2.0.9

[Dominik Psenner]

Davyd, I added you as a collaborator. This should grant you the privilege
to manage packages. You can now submit new and update or unlist existing
packages.

It would be great to have at least one other member of the pmc listed as
administrator. The following documents the matrix of permissions. Note that
the amount of administrative tasks should be very limited:

https://docs.microsoft.com/en-us/nuget/nuget-org/organizations-on-nuget-org#managing-organization-members

Cheers
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sat, Aug 22, 2020, 21:54 Davyd McColl  wrote:

> Oh ok, well, mine is davydm (:
>
> -d
>
>
> On August 22, 2020 20:49:59 Dominik Psenner  wrote:
>
> > Apparently it cant be the email but must be the nuget accounts username,
> > apologies.
> >
> > --
> > Sent from my phone. Typos are a kind gift to anyone who happens to find
> > them.
> >
> > On Sat, Aug 22, 2020, 20:39 Davyd McColl  wrote:
> >
> >> I know I'm quite new, but I'm happy to push approved packages. My
> >> Microsoft
> >> account for nuget is this email address (dav...@gmail.com)
> >>
> >> -d
> >>
> >>
> >> On August 22, 2020 19:46:45 Dominik Psenner  wrote:
> >>
> >> > Hi
> >> >
> >> > I recall that we were forced to transform the nuget account
> >> Apache.Logging (
> >> > https://www.nuget.org/profiles/Apache.Logging) from a personal
> account
> >> into
> >> > an organization. I am currently the only member and administrator of
> that
> >> > organization. Please share with me (may also be in private) the nuget
> >> > account (most probably the email of your microsoft account) if you
> want
> >> me
> >> > to add you to the organization. Any member of the pmc may also become
> >> > administrator of that group if he wishes to.
> >> >
> >> > While I try to process your requests as fast as possible, please give
> me
> >> > some days. I am at the beach with the family and tend to swim and
> dive in
> >> > moments when I do not build sandcastles with the kids. ;-)
> >> >
> >> > Best regards
> >> > Dominik
> >> > --
> >> > Sent from my phone. Typos are a kind gift to anyone who happens to
> find
> >> > them.
> >> >
> >> > On Sat, Aug 22, 2020, 02:01 Ralph Goers 
> >> wrote:
> >> >
> >> >> And, FWIW, Nuget won’t let me register with my apache.org <
> >> >> http://apache.org/> email address saying it can’t be a work or
> school
> >> >> email.
> >> >>
> >> >> Ralph
> >> >>
> >> >> > On Aug 21, 2020, at 4:46 PM, Ralph Goers <
> ralph.go...@dslextreme.com>
> >> >> wrote:
> >> >> >
> >> >> > This gets better and better. I was able to decrypt the file but the
> >> >> credentials don’t work.  The Nuget.org <http://nuget.org/> site says
> >> >> “NuGet.org <http://nuget.org/> password login in no longer
> supported.
> >> >> Please use a Microsoft account to sign into NuGet gallery.”
> >> >> >
> >> >> > Ralph
> >> >> >
> >> >> >> On Aug 21, 2020, at 4:37 PM, Ralph Goers <
> ralph.go...@dslextreme.com
> >> >
> >> >> wrote:
> >> >> >>
> >> >> >> Going back through my old emails I see Dominik had the same
> problem
> >> in
> >> >> 2016. I forgot to update my files and now I see the instructions have
> >> >> changed.
> >> >> >>
> >> >> >> Ralph
> >> >> >>
> >> >> >>> On Aug 21, 2020, at 4:27 PM, Ralph Goers <
> >> ralph.go...@dslextreme.com>
> >> >> wrote:
> >> >> >>>
> >> >> >>> I figured out that the document is now at home.apache.org <
> >> >> http://home.apache.org/>. Unfortunately, that didn’t do me any good.
> >> gpg
> >> >> -d is failing with “No secret key”. That doesn’t seem too surprising
> >> since
> >> >> my key wasn’t used to sign the document.
> >> >> >>>
> >> >> >>> Ralph
> >> >> >>>
> >> >> >>>> On Aug 21, 2020, at 3:53 PM, Ralph Goers <
> >> ralph.go...

Re: [VOTE] Release Log4Net 2.0.9

[Dominik Psenner]

Apparently it cant be the email but must be the nuget accounts username,
apologies.

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sat, Aug 22, 2020, 20:39 Davyd McColl  wrote:

> I know I'm quite new, but I'm happy to push approved packages. My
> Microsoft
> account for nuget is this email address (dav...@gmail.com)
>
> -d
>
>
> On August 22, 2020 19:46:45 Dominik Psenner  wrote:
>
> > Hi
> >
> > I recall that we were forced to transform the nuget account
> Apache.Logging (
> > https://www.nuget.org/profiles/Apache.Logging) from a personal account
> into
> > an organization. I am currently the only member and administrator of that
> > organization. Please share with me (may also be in private) the nuget
> > account (most probably the email of your microsoft account) if you want
> me
> > to add you to the organization. Any member of the pmc may also become
> > administrator of that group if he wishes to.
> >
> > While I try to process your requests as fast as possible, please give me
> > some days. I am at the beach with the family and tend to swim and dive in
> > moments when I do not build sandcastles with the kids. ;-)
> >
> > Best regards
> > Dominik
> > --
> > Sent from my phone. Typos are a kind gift to anyone who happens to find
> > them.
> >
> > On Sat, Aug 22, 2020, 02:01 Ralph Goers 
> wrote:
> >
> >> And, FWIW, Nuget won’t let me register with my apache.org <
> >> http://apache.org/> email address saying it can’t be a work or school
> >> email.
> >>
> >> Ralph
> >>
> >> > On Aug 21, 2020, at 4:46 PM, Ralph Goers 
> >> wrote:
> >> >
> >> > This gets better and better. I was able to decrypt the file but the
> >> credentials don’t work.  The Nuget.org <http://nuget.org/> site says
> >> “NuGet.org <http://nuget.org/> password login in no longer supported.
> >> Please use a Microsoft account to sign into NuGet gallery.”
> >> >
> >> > Ralph
> >> >
> >> >> On Aug 21, 2020, at 4:37 PM, Ralph Goers  >
> >> wrote:
> >> >>
> >> >> Going back through my old emails I see Dominik had the same problem
> in
> >> 2016. I forgot to update my files and now I see the instructions have
> >> changed.
> >> >>
> >> >> Ralph
> >> >>
> >> >>> On Aug 21, 2020, at 4:27 PM, Ralph Goers <
> ralph.go...@dslextreme.com>
> >> wrote:
> >> >>>
> >> >>> I figured out that the document is now at home.apache.org <
> >> http://home.apache.org/>. Unfortunately, that didn’t do me any good.
> gpg
> >> -d is failing with “No secret key”. That doesn’t seem too surprising
> since
> >> my key wasn’t used to sign the document.
> >> >>>
> >> >>> Ralph
> >> >>>
> >> >>>> On Aug 21, 2020, at 3:53 PM, Ralph Goers <
> ralph.go...@dslextreme.com>
> >> wrote:
> >> >>>>
> >> >>>> Dominik,
> >> >>>>
> >> >>>> The README file says that the keys can be found at
> >> https://people.apache.org/keys/group/logging-pmc.asc <
> >> https://people.apache.org/keys/group/logging-pmc.asc>.  That url
> returns
> >> a 404. Any idea where it moved to?
> >> >>>>
> >> >>>> Ralph
> >> >>>>
> >> >>>>> On Aug 17, 2020, at 9:39 AM, Dominik Psenner 
> >> wrote:
> >> >>>>>
> >> >>>>> I guess that would be a nuget publish.
> >> >>>>>
> >> >>>>>
> https://docs.microsoft.com/en-us/nuget/nuget-org/publish-a-package
> >> >>>>>
> >> >>>>> The credentials to that account are stored in the private repos of
> >> logging
> >> >>>>> pmc. Most members of the pmc should be in the set of recipients
> with
> >> their
> >> >>>>> gpg key.
> >> >>>>> --
> >> >>>>> Sent from my phone. Typos are a kind gift to anyone who happens to
> >> find
> >> >>>>> them.
> >> >>>>>
> >> >>>>> On Mon, Aug 17, 2020, 08:56 Davyd McColl 
> wrote:
> >> >>>>>
> >> >>>>>> Great!
> >&

Re: [VOTE] Release Log4Net 2.0.9

[Dominik Psenner]

Hi

I recall that we were forced to transform the nuget account Apache.Logging (
https://www.nuget.org/profiles/Apache.Logging) from a personal account into
an organization. I am currently the only member and administrator of that
organization. Please share with me (may also be in private) the nuget
account (most probably the email of your microsoft account) if you want me
to add you to the organization. Any member of the pmc may also become
administrator of that group if he wishes to.

While I try to process your requests as fast as possible, please give me
some days. I am at the beach with the family and tend to swim and dive in
moments when I do not build sandcastles with the kids. ;-)

Best regards
Dominik
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sat, Aug 22, 2020, 02:01 Ralph Goers  wrote:

> And, FWIW, Nuget won’t let me register with my apache.org <
> http://apache.org/> email address saying it can’t be a work or school
> email.
>
> Ralph
>
> > On Aug 21, 2020, at 4:46 PM, Ralph Goers 
> wrote:
> >
> > This gets better and better. I was able to decrypt the file but the
> credentials don’t work.  The Nuget.org <http://nuget.org/> site says
> “NuGet.org <http://nuget.org/> password login in no longer supported.
> Please use a Microsoft account to sign into NuGet gallery.”
> >
> > Ralph
> >
> >> On Aug 21, 2020, at 4:37 PM, Ralph Goers 
> wrote:
> >>
> >> Going back through my old emails I see Dominik had the same problem in
> 2016. I forgot to update my files and now I see the instructions have
> changed.
> >>
> >> Ralph
> >>
> >>> On Aug 21, 2020, at 4:27 PM, Ralph Goers 
> wrote:
> >>>
> >>> I figured out that the document is now at home.apache.org <
> http://home.apache.org/>. Unfortunately, that didn’t do me any good. gpg
> -d is failing with “No secret key”. That doesn’t seem too surprising since
> my key wasn’t used to sign the document.
> >>>
> >>> Ralph
> >>>
> >>>> On Aug 21, 2020, at 3:53 PM, Ralph Goers 
> wrote:
> >>>>
> >>>> Dominik,
> >>>>
> >>>> The README file says that the keys can be found at
> https://people.apache.org/keys/group/logging-pmc.asc <
> https://people.apache.org/keys/group/logging-pmc.asc>.  That url returns
> a 404. Any idea where it moved to?
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On Aug 17, 2020, at 9:39 AM, Dominik Psenner 
> wrote:
> >>>>>
> >>>>> I guess that would be a nuget publish.
> >>>>>
> >>>>> https://docs.microsoft.com/en-us/nuget/nuget-org/publish-a-package
> >>>>>
> >>>>> The credentials to that account are stored in the private repos of
> logging
> >>>>> pmc. Most members of the pmc should be in the set of recipients with
> their
> >>>>> gpg key.
> >>>>> --
> >>>>> Sent from my phone. Typos are a kind gift to anyone who happens to
> find
> >>>>> them.
> >>>>>
> >>>>> On Mon, Aug 17, 2020, 08:56 Davyd McColl  wrote:
> >>>>>
> >>>>>> Great!
> >>>>>>
> >>>>>> How do we get the nupkg to nuget.org? This is the final step that
> most
> >>>>>> users are going to be interested in.
> >>>>>>
> >>>>>> Having a look at what's at the url you posted, I have ideas on how
> to
> >>>>>> streamline future releases, so the next time I'm in that area, I'm
> >>>>>> definitely implementing those ideas. I don't see changes to the
> Release
> >>>>>> Notes area -- if I were to try to streamline that into a release,
> would a
> >>>>>> CHANGELOG file be useful? Or is there a better way?
> >>>>>>
> >>>>>> -d
> >>>>>> On 2020/08/16 23:26:07, Matt Sicker  wrote:
> >>>>>> I committed them to dist already. I don't know how long we should
> wait
> >>>>>> for any mirroring to catch up, though on my end, I see updated
> >>>>>> artifacts on https://downloads.apache.org/logging/log4net/ other
> than
> >>>>>> the release notes.
> >>>>>>
> >>>>>> On Sun, 16 Aug 2020 at 15:09, Ralph Goers wrote:
> >>>>>>>
> >>>>>>> +1 to that!
> >>>>>

Re: [VOTE] Release Log4Net 2.0.9

[Dominik Psenner]

Is there an option to trust a ci machine and automate the publish with a
push of a tag after a successful vote? With this, anyone having the
possibility to push a tag can forge a release with almost no effort.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Mon, Aug 17, 2020, 19:21 Davyd McColl  wrote:

> Correct, nuget publish. An option, once I'm trusted, is to allow me to
> publish. My nuget login is done via Microsoft credentials for
> dav...@gmail.com, and is secured by 2FA, so the only real risk is how
> dodgy
> I am (:
>
> If it's of interest to anyone, my profile is at
> https://www.nuget.org/profiles/davydm
>
> -d
>
>
> On August 17, 2020 18:46:50 Dominik Psenner  wrote:
>
> > I guess that would be a nuget publish.
> >
> > https://docs.microsoft.com/en-us/nuget/nuget-org/publish-a-package
> >
> > The credentials to that account are stored in the private repos of
> logging
> > pmc. Most members of the pmc should be in the set of recipients with
> their
> > gpg key.
> > --
> > Sent from my phone. Typos are a kind gift to anyone who happens to find
> > them.
> >
> > On Mon, Aug 17, 2020, 08:56 Davyd McColl  wrote:
> >
> >> Great!
> >>
> >> How do we get the nupkg to nuget.org? This is the final step that most
> >> users are going to be interested in.
> >>
> >> Having a look at what's at the url you posted, I have ideas on how to
> >> streamline future releases, so the next time I'm in that area, I'm
> >> definitely implementing those ideas. I don't see changes to the Release
> >> Notes area -- if I were to try to streamline that into a release, would
> a
> >> CHANGELOG file be useful? Or is there a better way?
> >>
> >> -d
> >> On 2020/08/16 23:26:07, Matt Sicker  wrote:
> >> I committed them to dist already. I don't know how long we should wait
> >> for any mirroring to catch up, though on my end, I see updated
> >> artifacts on https://downloads.apache.org/logging/log4net/ other than
> >> the release notes.
> >>
> >> On Sun, 16 Aug 2020 at 15:09, Ralph Goers wrote:
> >> >
> >> > +1 to that!
> >> >
> >> > Let me know when these are published. I can update the web site to
> >> reflect that it is no longer dormant.
> >> >
> >> > Ralph
> >> >
> >> > > On Aug 16, 2020, at 11:54 AM, Matt Sicker wrote:
> >> > >
> >> > > Thanks so much for your help in releasing this!
> >> > >
> >> > > On Sun, 16 Aug 2020 at 13:53, Davyd McColl wrote:
> >> > >>
> >> > >> I'll make changes to the automated build to affect all changes you
> >> have
> >> > >> made (and perhaps will make) automatically to future releases for
> the
> >> next
> >> > >> release. Apologies for making this more difficult than it needs to
> be
> >> (:
> >> > >>
> >> > >> -d
> >> > >>
> >> > >>
> >> > >> On August 16, 2020 20:37:01 Matt Sicker wrote:
> >> > >>
> >> > >>> Just a simple copy of the LICENSE and NOTICE file into the
> binaries
> >> > >>> zip, and a rename of the files to include "apache" in the name.
> I've
> >> > >>> uploaded them to dist along with updating the KEYS file for
> log4net,
> >> > >>> though that should probably be merged together with the
> project-wide
> >> > >>> KEYS file in the parent directory. There's an outdated
> README.html in
> >> > >>> the directory still containing the old release notes, but we can
> >> > >>> address that next.
> >> > >>>
> >> > >>> On Sun, 16 Aug 2020 at 13:12, Matt Sicker wrote:
> >> > >>>>
> >> > >>>> One issue I found in one of the artifacts that I can address
> before
> >> > >>>> uploading since it wasn't signed is the binaries zip is missing
> the
> >> > >>>> LICENSE file. I'm not sure if there's a standard way to include
> that
> >> > >>>> in the nupkg file, but I did see that in its metadata, it
> explicitly
> >> > >>>> says the code is Apache2 licensed at least.
> >> > >>>>
> >> > >>>> On Sun, 16 Aug 2020 at 13:03, Matt Sicker wrote:
> >> > >>>&g

Re: [VOTE] Release Log4Net 2.0.9

[Dominik Psenner]

I guess that would be a nuget publish.

https://docs.microsoft.com/en-us/nuget/nuget-org/publish-a-package

The credentials to that account are stored in the private repos of logging
pmc. Most members of the pmc should be in the set of recipients with their
gpg key.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Mon, Aug 17, 2020, 08:56 Davyd McColl  wrote:

> Great!
>
> How do we get the nupkg to nuget.org? This is the final step that most
> users are going to be interested in.
>
> Having a look at what's at the url you posted, I have ideas on how to
> streamline future releases, so the next time I'm in that area, I'm
> definitely implementing those ideas. I don't see changes to the Release
> Notes area -- if I were to try to streamline that into a release, would a
> CHANGELOG file be useful? Or is there a better way?
>
> -d
> On 2020/08/16 23:26:07, Matt Sicker  wrote:
> I committed them to dist already. I don't know how long we should wait
> for any mirroring to catch up, though on my end, I see updated
> artifacts on https://downloads.apache.org/logging/log4net/ other than
> the release notes.
>
> On Sun, 16 Aug 2020 at 15:09, Ralph Goers wrote:
> >
> > +1 to that!
> >
> > Let me know when these are published. I can update the web site to
> reflect that it is no longer dormant.
> >
> > Ralph
> >
> > > On Aug 16, 2020, at 11:54 AM, Matt Sicker wrote:
> > >
> > > Thanks so much for your help in releasing this!
> > >
> > > On Sun, 16 Aug 2020 at 13:53, Davyd McColl wrote:
> > >>
> > >> I'll make changes to the automated build to affect all changes you
> have
> > >> made (and perhaps will make) automatically to future releases for the
> next
> > >> release. Apologies for making this more difficult than it needs to be
> (:
> > >>
> > >> -d
> > >>
> > >>
> > >> On August 16, 2020 20:37:01 Matt Sicker wrote:
> > >>
> > >>> Just a simple copy of the LICENSE and NOTICE file into the binaries
> > >>> zip, and a rename of the files to include "apache" in the name. I've
> > >>> uploaded them to dist along with updating the KEYS file for log4net,
> > >>> though that should probably be merged together with the project-wide
> > >>> KEYS file in the parent directory. There's an outdated README.html in
> > >>> the directory still containing the old release notes, but we can
> > >>> address that next.
> > >>>
> > >>> On Sun, 16 Aug 2020 at 13:12, Matt Sicker wrote:
> > 
> >  One issue I found in one of the artifacts that I can address before
> >  uploading since it wasn't signed is the binaries zip is missing the
> >  LICENSE file. I'm not sure if there's a standard way to include that
> >  in the nupkg file, but I did see that in its metadata, it explicitly
> >  says the code is Apache2 licensed at least.
> > 
> >  On Sun, 16 Aug 2020 at 13:03, Matt Sicker wrote:
> > >
> > > I'll sign and publish the artifacts today.
> > >
> > > On Mon, 3 Aug 2020 at 17:43, Ralph Goers wrote:
> > >>
> > >> Thanks Remko. That makes 3 +1 votes from PMC members.
> > >>
> > >> Ralph
> > >>
> > >>> On Aug 3, 2020, at 2:12 PM, Remko Popma wrote:
> > >>>
> > >>> +1 Remko.
> > >>>
> > >>> On Tue, Aug 4, 2020 at 1:04 AM Matt Sicker wrote:
> > >>>
> >  +1 from me. We can handle the release signing afterwards as
> Ralph
> >  suggests.
> > 
> >  On Mon, 3 Aug 2020 at 10:30, Ralph Goers
> >  wrote:
> > >
> > > Can other PMC members please review this? It has been more
> than 72
> >  hours.
> > >
> > > Ralph
> > >
> > >> On Jul 30, 2020, at 11:17 PM, Davyd McColl
> >  wrote:
> > >>
> > >> Hi all, I've never done this before, so bear with me if I
> fluff it:
> > >>
> > >> This is a proposed vote to release log4net 2.0.9 from PR
> >  https://github.com/apache/logging-log4net/pull/61
> > >>
> > >> Release artifacts (including source zip) are at:
> > 
> > 
> https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/34063235/artifacts
> > >> Source can be checked out from
> >  https://github.com/fluffynuts/logging-log4net/logging-log4net,
> tag rel/
> >  2.0.9. I can't push tags to the upstream, but this tag is
> exactly the
> >  same commit as the last in the PR mentioned above, which was
> >  accepted into
> >  master a few days ago.
> > >>
> > >> Please check out the artifacts & if everyone is ok with
> what's there,
> >  please can someone with the rights to publish to nuget do so.
> > >>
> > >> Once I've seen how this process works, I'd like to tackle the
> CVE that
> >  has been brought up on this list more than once -- it's a
> simple change
> >  which was already committed to the develop branch some time
> ago, so
> >  there
> >  are a 

Re: [VOTE] Log4Net dormant release

[Dominik Psenner]

I agree. People have to learn the mailing list mechanics. In this case I
deliberately chose to accept the message because I valued it worthy for the
readers of dev at logging.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Thu, Jul 30, 2020, 19:07 Ralph Goers  wrote:

> Unfortunately, I had to moderate the message you just responded to so I am
> not sure if they will see the response. That said, I don’t think we should
> be cc’ing posters. They should subscribe.
>
> Ralph
>
> > On Jul 30, 2020, at 9:14 AM, Dominik Psenner  wrote:
> >
> > Hi Shushi Kant,
> >
> > There is no maintainer to release binaries for You. A source only release
> > was made some time ago, also to signal the dormant state of the project.
> > This was aimed to be a signal to interesting parties to get involved in
> the
> > project. I see at least these options:
> >
> > Option 1 is to get involved and drive forward a release of binaries along
> > others who have chimed in.
> >
> > Option 2 is to consume log4net sources, building a head revision that
> > includes the fix.
> >
> > Option 3 is to fork and do what You see fit and is allowed according to
> the
> > license agreement.
> >
> > Best Regards,
> > Dominik
> > --
> > Sent from my phone. Typos are a kind gift to anyone who happens to find
> > them.
> >
> > On Thu, Jul 30, 2020, 17:56 Nallapu, Shashi Kanth <
> > shashikanth.nall...@ehi.com> wrote:
> >
> >> Dear Team,
> >> Can you please provide an update on the below query. This is about the
> >> 2.1.0 release for issue LOG4NET-575.
> >> Currently we have a XXE vulnerability raised for log4net in our
> >> application. Our application uses log4net version 2.0.8 and Microsoft
> .net
> >> framework 4.5.2.
> >> By default, .net framework will disable external entities but I think
> this
> >> has been overridden in log4net. I can see this issue was already been
> fixed
> >> on Jan 08, 2018 by log4net team and it should be available in the
> version
> >> 2.1.0 (which is not released yet)
> >> Jira Link: https://issues.apache.org/jira/browse/LOG4NET-575.
> >> We have been using this package in most of the applications. Can you
> >> please provide an update whether you have any plans to release this
> patch
> >> or not.
> >> Thanks and Regards,
> >> Shashikanth N.
> >>
> >> On 2020/07/30 07:41:43, Satish Rathore  wrote:
> >>> Hi,>
> >>>
> >>> Do we have any further update on this, any plan for releasing 2.1.0>
> >>>
> >>> Thanks,>
> >>> Satish>
> >>>
> >>> On 2020/04/04 22:24:59, Ralph Goers 
> wrote:
> >>>
> >>>> I have modified the STATUS.txt and README.txt for Log4Net, tagged the
> >> source, zipped it and then published it to
> >> https://dist.apache.org/repos/dist/dev/logging/log4net/ <
> >> https://dist.apache.org/repos/dist/dev/logging/log4net/>.>
> >>
> >>>>>
> >>>> This is a vote to move those artifacts to the distribution release
> >> directory. >
> >>>>>
> >>>> This vote will remain open for 72 hours.>
> >>>>>
> >>>> Ralph>
> >>>
> >>
> >> 
> >>
> >> CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential
> >> and may contain information that is privileged. If you are not the named
> >> recipient, or responsible for delivering the message to the named
> >> recipient, you must not disclose, distribute, forward, copy, store or
> use
> >> this e-mail or its attachments in any form. If you have received this
> >> communication in error, please accept our apologies and promptly inform
> the
> >> sender by e-mail or by telephoning the above number. Please also
> >> immediately delete this message and any attachments from your systems.
> >>
> >> To the extent permitted by law, we may monitor electronic communications
> >> for the purposes of ensuring compliance with our legal and regulatory
> >> obligations and internal policies. Although this e-mail and its
> attachments
> >> have been checked by an up-to-date virus-checking program before
> >> transmission, it is your responsibility as recipient to ensure they are
> >> actually virus free when received.
> >>
> >> Enterprise Rent-A-Car UK Limited is registered in England and Wales with
> >> registered number 2946689. The company's registered office is Enterprise
> >> House, Melburne Park, Vicarage Road, Egham Surrey TW20 9FB.
> >>
> >>
> >>
>
>
>

Re: [VOTE] Log4Net dormant release

[Dominik Psenner]

Hi Shushi Kant,

There is no maintainer to release binaries for You. A source only release
was made some time ago, also to signal the dormant state of the project.
This was aimed to be a signal to interesting parties to get involved in the
project. I see at least these options:

Option 1 is to get involved and drive forward a release of binaries along
others who have chimed in.

Option 2 is to consume log4net sources, building a head revision that
includes the fix.

Option 3 is to fork and do what You see fit and is allowed according to the
license agreement.

Best Regards,
Dominik
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Thu, Jul 30, 2020, 17:56 Nallapu, Shashi Kanth <
shashikanth.nall...@ehi.com> wrote:

> Dear Team,
> Can you please provide an update on the below query. This is about the
> 2.1.0 release for issue LOG4NET-575.
> Currently we have a XXE vulnerability raised for log4net in our
> application. Our application uses log4net version 2.0.8 and Microsoft .net
> framework 4.5.2.
> By default, .net framework will disable external entities but I think this
> has been overridden in log4net. I can see this issue was already been fixed
> on Jan 08, 2018 by log4net team and it should be available in the version
> 2.1.0 (which is not released yet)
> Jira Link: https://issues.apache.org/jira/browse/LOG4NET-575.
> We have been using this package in most of the applications. Can you
> please provide an update whether you have any plans to release this patch
> or not.
> Thanks and Regards,
> Shashikanth N.
>
> On 2020/07/30 07:41:43, Satish Rathore  wrote:
> > Hi,>
> >
> > Do we have any further update on this, any plan for releasing 2.1.0>
> >
> > Thanks,>
> > Satish>
> >
> > On 2020/04/04 22:24:59, Ralph Goers  wrote:
> >
> > > I have modified the STATUS.txt and README.txt for Log4Net, tagged the
> source, zipped it and then published it to
> https://dist.apache.org/repos/dist/dev/logging/log4net/ <
> https://dist.apache.org/repos/dist/dev/logging/log4net/>.>
>
> > > >
> > > This is a vote to move those artifacts to the distribution release
> directory. >
> > > >
> > > This vote will remain open for 72 hours.>
> > > >
> > > Ralph>
> >
>
> 
>
> CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential
> and may contain information that is privileged. If you are not the named
> recipient, or responsible for delivering the message to the named
> recipient, you must not disclose, distribute, forward, copy, store or use
> this e-mail or its attachments in any form. If you have received this
> communication in error, please accept our apologies and promptly inform the
> sender by e-mail or by telephoning the above number. Please also
> immediately delete this message and any attachments from your systems.
>
> To the extent permitted by law, we may monitor electronic communications
> for the purposes of ensuring compliance with our legal and regulatory
> obligations and internal policies. Although this e-mail and its attachments
> have been checked by an up-to-date virus-checking program before
> transmission, it is your responsibility as recipient to ensure they are
> actually virus free when received.
>
> Enterprise Rent-A-Car UK Limited is registered in England and Wales with
> registered number 2946689. The company's registered office is Enterprise
> House, Melburne Park, Vicarage Road, Egham Surrey TW20 9FB.
>
>
>

Re: [CVE-2018-1285] XXE vulnerability in Apache log4net

[Dominik Psenner]

An important note to make is that even if the file is loaded from a trusted
source, it should reference only files that come from trusted sources. DTD
statements may slip through in this consideration. Note further that
"https://; is not a warranty for a trusted source, it only guarantees a
secure transportation of information. The contents that are transported may
be tampered with.

On Wed, 17 Jun 2020 at 17:13, Matt Sicker  wrote:

> It's not an issue if the config file is a trusted source. It's
> generally not a good idea to do that in the first place, either.
>
> On Wed, 17 Jun 2020 at 09:56, Venkamsetty, VenkataRao
>  wrote:
> >
> > Why this is an issue if the configuration file is loaded from trusted
> source?
> >
> > On 2020/05/25 16:28:20, Suthish Nair  wrote:
> > > Hi,>
> > >
> > > Good Day!>
> > >
> > > Is there any mitigation or vulnerability fix available for .NET Core>
> > > frameworks?>
> > >
> > > Please let me know.>
> > >
> > > Regards>
> > > Suthish>
> > >
>
>
>
> --
> Matt Sicker 
>


-- 
Dominik Psenner

Re: [CVE-2018-1285] XXE vulnerability in Apache log4net

[Dominik Psenner]

The fix has been committed for some time now and is available with all
branches that I know. You are affected by this CVE if your application
consumes configuration files from untrusted sources, especially in dtd
statements.

1. You should assert that your deployment does not rely on dtd processing
2. You should not allow your application to consume configuration files
from untrusted sources

At this point it is actually an optional to build log4net from source and
update the library such that it does no longer allow any dtd processing.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Mon, May 25, 2020, 19:04 Andrew Marlow  wrote:

> The project page says:
>
> As of April 1, 2020 Log4Net is a dormant project of Apache Logging
> Services. The dormant status means the project has been classified as
> inactive since it has had no recent development activity and there are no
> active volunteers to perform code reviews, commit code, or perform
> releases.
>
> The CVE applies to version 2.0.8 and below and since 2.0.8 is the latest
> version I think you are going to be out of luck.
>
>
> On Mon, 25 May 2020 at 17:29, Suthish Nair 
> wrote:
>
> > Hi,
> >
> > Good Day!
> >
> > Is there any mitigation or vulnerability fix available for .NET Core
> > frameworks?
> >
> > Please let me know.
> >
> > Regards
> > Suthish
> >
>
>
> --
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk
>

Re: [log4net] CI server question

[Dominik Psenner]

Mileage may vary, but I see no point in supporting ancient frameworks.
Better support only few valuable targets well and offload maintenance
efforts to whoever needs other targets that are hard to support. For
instance, whoever builds against client profile could fork and build
log4net from source. Patches to make it work are valuable and always
welcome, now and anytime in the future. Those patches may not be mergable
into develop/master either as they could live in their own branch if
necessary.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Mon, Apr 27, 2020, 21:13 Davyd McColl  wrote:

> Thanks, I've already tried using mono for cross-compilation, but older
> targets (and specifically client profile) make this option a bit of a
> non-starter. I got it mostly working, but mostly isn't all the way.
>
> CircleCI provides a good build environment, which I'm probably going to
> try
> to replicate in docker, though that would still require a windows host.
>
> -d
>
>
> On April 27, 2020 21:07:50 Dominik Psenner  wrote:
>
> > As apache folks, we have the benefit of sponsored msdn subscriptions and
> > thus some sponsored computing time in azure. May that be an option?
> >
> > I dont know about the tasks involved.
> >
> > I can also think of cross compiling on ubuntu inside docker by leveraging
> > dotnet-sdk and linking against the reference assemblies shipped with mono
> > or other requirements that can be provided with Dockerfile's, github
> > actions or other build infrastructure. This [1] is a reference project
> that
> > works and may serve as a minimalistic sample that, to be honest, is pure
> > net core/netstandard and therefore lacks mono.
> >
> > [1] https://github.com/dpsenner/event-sorcery
> > --
> > Sent from my phone. Typos are a kind gift to anyone who happens to find
> > them.
> >
> > On Mon, Apr 27, 2020, 16:48 Matt Sicker  wrote:
> >
> >> Looks like AppVeyor is another option. Is that comparable to CircleCI?
> >>
> >> (For context, I'm mostly familiar with Jenkins as I work on that
> >> project at $dayjob)
> >>
> >> On Mon, 27 Apr 2020 at 09:36, Matt Sicker  wrote:
> >> >
> >> > Seems like I missed some other services:
> >> https://infra.apache.org/services.html
> >> >
> >> > If nothing on there is appropriate, I think we need to create a Jira
> >> > ticket in https://issues.apache.org/jira/browse/INFRA
> >> >
> >> > On Mon, 27 Apr 2020 at 01:28, Davyd McColl  wrote:
> >> > >
> >> > > What would need to be done to make other CI systems talk with Apache
> >> Infra?
> >> > >
> >> > > I ask because I've spend around a day now trying to convince Travis
> CI
> >> to build log4net successfully, without a lot of joy, particularly
> because
> >> the Travis Windows build environment is quite out of date, having been
> >> launched as a beta service in 2018, with tooling from 2015. I can get
> >> vs2019 installed via chocolatey packages, which solves most of the
> >> requirements, but haven't had joy in getting .net 3.5 to install on the
> >> build machine yet, resulting in predictable build failures. In addition,
> >> the installation of vs2019 tooling adds a few minutes to build.
> >> > >
> >> > > In contrast, build at CircleCI has been simple, quick, and, best of
> >> all, works. I've also figured out artifact publishing, so, with the
> >> addition of some scripting, one possible solution might be for an Apache
> >> Jenkins build job to simply download the nuget package from CircleCI and
> >> publish it -- meaning that Apache nuget keys don't have to leave secure
> >> premises, which is a good thing (: For example, a parameterised build
> which
> >> is given only a build number could be manually kicked off when a release
> >> has been approved by all involved. This build could download the .nupkg
> >> from CircleCI and publish to nuget.org.
> >> > >
> >> > > If this (or something similar) seems like a viable option, I may be
> in
> >> a position to raise a PR (after cleaning up some git history -- I
> probably
> >> have 50 or 100 commits which are only attempts at getting TravisCI to
> build
> >> with varying approaches.
> >> > >
> >> > > -d
> >> > > On 2020-04-25 22:15:36, Matt Sicker  wrote:
> >> > > The only external build systems that are set up for Apache right now
> >> >

Re: [log4net] CI server question

[Dominik Psenner]

As apache folks, we have the benefit of sponsored msdn subscriptions and
thus some sponsored computing time in azure. May that be an option?

I dont know about the tasks involved.

I can also think of cross compiling on ubuntu inside docker by leveraging
dotnet-sdk and linking against the reference assemblies shipped with mono
or other requirements that can be provided with Dockerfile's, github
actions or other build infrastructure. This [1] is a reference project that
works and may serve as a minimalistic sample that, to be honest, is pure
net core/netstandard and therefore lacks mono.

[1] https://github.com/dpsenner/event-sorcery
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Mon, Apr 27, 2020, 16:48 Matt Sicker  wrote:

> Looks like AppVeyor is another option. Is that comparable to CircleCI?
>
> (For context, I'm mostly familiar with Jenkins as I work on that
> project at $dayjob)
>
> On Mon, 27 Apr 2020 at 09:36, Matt Sicker  wrote:
> >
> > Seems like I missed some other services:
> https://infra.apache.org/services.html
> >
> > If nothing on there is appropriate, I think we need to create a Jira
> > ticket in https://issues.apache.org/jira/browse/INFRA
> >
> > On Mon, 27 Apr 2020 at 01:28, Davyd McColl  wrote:
> > >
> > > What would need to be done to make other CI systems talk with Apache
> Infra?
> > >
> > > I ask because I've spend around a day now trying to convince Travis CI
> to build log4net successfully, without a lot of joy, particularly because
> the Travis Windows build environment is quite out of date, having been
> launched as a beta service in 2018, with tooling from 2015. I can get
> vs2019 installed via chocolatey packages, which solves most of the
> requirements, but haven't had joy in getting .net 3.5 to install on the
> build machine yet, resulting in predictable build failures. In addition,
> the installation of vs2019 tooling adds a few minutes to build.
> > >
> > > In contrast, build at CircleCI has been simple, quick, and, best of
> all, works. I've also figured out artifact publishing, so, with the
> addition of some scripting, one possible solution might be for an Apache
> Jenkins build job to simply download the nuget package from CircleCI and
> publish it -- meaning that Apache nuget keys don't have to leave secure
> premises, which is a good thing (: For example, a parameterised build which
> is given only a build number could be manually kicked off when a release
> has been approved by all involved. This build could download the .nupkg
> from CircleCI and publish to nuget.org.
> > >
> > > If this (or something similar) seems like a viable option, I may be in
> a position to raise a PR (after cleaning up some git history -- I probably
> have 50 or 100 commits which are only attempts at getting TravisCI to build
> with varying approaches.
> > >
> > > -d
> > > On 2020-04-25 22:15:36, Matt Sicker  wrote:
> > > The only external build systems that are set up for Apache right now
> > > are Travis and some limited GitHub Action experiments. Other CI
> > > systems may need to talk with Apache Infra.
> > >
> > > On Sat, 25 Apr 2020 at 14:47, Davyd McColl wrote:
> > > >
> > > > Thanks for the reply (:
> > > >
> > > > Would external build systems like circleci be acceptable too?
> > > >
> > > > -d
> > > >
> > > >
> > > >
> > > > On April 25, 2020 21:03:01 Matt Sicker wrote:
> > > >
> > > > > Info about our existing infra is documented here:
> > > > > https://cwiki.apache.org/confluence/display/INFRA/Jenkins
> > > > >
> > > > > On Sat, 25 Apr 2020 at 13:38, Davyd McColl wrote:
> > > > >>
> > > > >> Hi
> > > > >>
> > > > >> Quick question: what operating system does the available CI
> server run?
> > > > >> Even if docker is an option, the host system is matters.
> > > > >>
> > > > >> Thanks
> > > > >> -d
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Matt Sicker
> > > >
> > > >
> > >
> > >
> > > --
> > > Matt Sicker
> >
> >
> >
> > --
> > Matt Sicker 
>
>
>
> --
> Matt Sicker 
>

Re: [Log4Net]: resurrection

[Dominik Psenner]

I must mention that the Dockerfiles are invoked from the Jenkinsfile and
uses nant and the nant build scripts to build the project. nant is a
deadend road and should be replaced. The dockerfiles could stay, providing
the future build requisites for the future build scripts. If the project is
migrated to the new SDK style, it would be supported by the dotnet
commandline tool and as such the following targets can be built by using
the dotnet build command:

https://docs.microsoft.com/en-us/dotnet/standard/frameworks
https://docs.microsoft.com/it-it/dotnet/core/tools/dotnet-build

This would greatly integrate with msbuild inline tasks which could be used
to build site and other non-code assemblies:

https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-inline-tasks?view=vs-2019

Cheers,
Dominik

On Sun, 19 Apr 2020 at 10:41, Dominik Psenner  wrote:

> You may find the develop and other branches useful:
>
> https://github.com/apache/logging-log4net/tree/develop/buildtools/docker
> <https://github.com/apache/logging-log4net/tree/feature/netstandard-2.0/buildtools/docker>
>
> There are dockerfiles along with shell scripts that used to work for
> building several of the targets.
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
>
> On Sat, Apr 18, 2020, 17:02 Davyd McColl  wrote:
>
>> A short update (not much to report):
>>
>> - resolved Client profile builds
>> - can manually build a .nupkg, without any warnings
>>   - have updated  to , using the term Apache-2.0, as
>> per the url it was pointing to
>>   - have updated  to point at the same feather.png the package
>> used to point to online, renamed within the project to package-icon.png for
>> clarity
>>
>> Next up:
>> dotnet core tooling wants sdks for net20 and net35 to be installed on the
>> host. Alternatively, we could install all of Build Tools 2019 on the host.
>> I think the former might be neater. At any rate, I now have to figure out
>> enough docker to be dangerous and get a standalone build environment up and
>> running.
>>
>> -d
>
>

-- 
Dominik Psenner

Re: [Log4Net]: resurrection

[Dominik Psenner]

You may find the develop and other branches useful:

https://github.com/apache/logging-log4net/tree/develop/buildtools/docker


There are dockerfiles along with shell scripts that used to work for
building several of the targets.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sat, Apr 18, 2020, 17:02 Davyd McColl  wrote:

> A short update (not much to report):
>
> - resolved Client profile builds
> - can manually build a .nupkg, without any warnings
>   - have updated  to , using the term Apache-2.0, as
> per the url it was pointing to
>   - have updated  to point at the same feather.png the package
> used to point to online, renamed within the project to package-icon.png for
> clarity
>
> Next up:
> dotnet core tooling wants sdks for net20 and net35 to be installed on the
> host. Alternatively, we could install all of Build Tools 2019 on the host.
> I think the former might be neater. At any rate, I now have to figure out
> enough docker to be dangerous and get a standalone build environment up and
> running.
>
> -d

Re: log4net: resurrection

[Dominik Psenner]

nt (and what that
> means).
> >>>>>>>>>>> I've been told that the team has been looking for outside help
> for
> >>>>>>>>>> around 2
> >>>>>>>>>>> years, with no-one forthcoming. Unfortunately, as I say, this
> is the
> >>>>>>>>>> first
> >>>>>>>>>>> I've heard of it. I'd like to keep log4net alive because it's
> used
> >>>>>>>>>>> ubiquitously and I think it's a valuable project.
> >>>>>>>>>>> I publish my own nuget packages (
> https://www.nuget.org/profiles/davydm)
> >>>>>>>>>>> though obviously, not with the same methodologies of the
> existing log4net
> >>>>>>>>>>> infrastructure. I see that there's a 2.0.9 release that could
> potentially
> >>>>>>>>>>> happen (as per the source), whilst 2.0.8 is still the current
> release, so
> >>>>>>>>>>> I'm assuming there's something holding that up. I also see 34
> pull
> >>>>>>>>>> requests
> >>>>>>>>>>> on GitHub which are in different states of activity, but many
> have been
> >>>>>>>>>>> dormant since 2018.
> >>>>>>>>>>> I'd like to help, but I'm not sure where to start with the
> log4net infra
> >>>>>>>>>> (I
> >>>>>>>>>>> hear there's Jira (I've had little experience) and Jenkins
> (I've had
> >>>>>>>>>>> reasonable experience, but not with pipelines)). I'm not even
> sure what
> >>>>>>>>>> the
> >>>>>>>>>>> state of play is for that infra. I'm sure there are good
> reasons for
> >>>>>>>>>> making
> >>>>>>>>>>> the project dormant -- some of those may include the desire to
> free up
> >>>>>>>>>>> infra which could be used elsewhere (or just not paid for).
> >>>>>>>>>>> As I say, I'd like to keep log4net alive. I see a few options
> here:
> >>>>>>>>>>> 1. I learn your infra and your processes. I integrate and try
> to keep
> >>>>>>>>>>> things pretty-much as they were (though I'm sure some things
> would have
> >>>>>>>>>> to
> >>>>>>>>>>> change -- all things do). I don't mind spending the time
> learning the
> >>>>>>>>>>> domain, if that's agreeable to everyone and the project
> retains it's
> >>>>>>>>>>> original branding and status. One thing I'm concerned about
> here is the
> >>>>>>>>>>> dormant backlog
> >>>>>>>>>>> 2. As above, with a bit of a clean-slate philosophy: I'd like
> to remove
> >>>>>>>>>> all
> >>>>>>>>>>> backlog items that aren't critical and start with the least
> outstanding
> >>>>>>>>>>> stuff possible. If a report is important, it will be reported
> again.
> >>>>>>>>>> Trying
> >>>>>>>>>>> to trace down the authors and origins of 2+year-old reports is
> going to
> >>>>>>>>>> be
> >>>>>>>>>>> frustrating. Issues which aren't attended to just become noise
> in the
> >>>>>>>>>>> backlog, imo.
> >>>>>>>>>>> 3. I fork and perform the "clean slate" approach of above,
> inviting
> >>>>>>>>>> others
> >>>>>>>>>>> to use my variant and log issues there. Uptake will naturally
> be slow (if
> >>>>>>>>>>> even noticeable), which will give me time to deal with
> incoming issues.
> >>>>>>>>>> On
> >>>>>>>>>>> the other hand, I'd have full control and no need to bother
> anyone else.
> >>>>>>>>>> I
> >>>>>>>>>>> would have to come up with a new name and make it clear that
> it's a fork,
> >>>>>>>>>>> though also make it clear I'd be standing on the shoulders of
> giants.
> >>>>>>>>>>> Personally, I'd like (1) because it keeps the project that
> people rely on
> >>>>>>>>>>> alive. Since I'm new to the mailing list, I can't discern yet
> the
> >>>>>>>>>> sentiment
> >>>>>>>>>>> towards the project, except that everyone was quite happy to
> have it made
> >>>>>>>>>>> dormant, so it feels like there's not a lot of desire to keep
> it going --
> >>>>>>>>>>> which is ok: everything comes to an end at some point, and, as
> stated
> >>>>>>>>>>> earlier, I'm sure there are good reasons for making log4net
> dormant. As a
> >>>>>>>>>>> consumer of log4net, I'd much rather not have to switch over
> to another
> >>>>>>>>>>> framework once there's an issue which affects me more than my
> logged one
> >>>>>>>>>>> (inability to flush logs -- it was on a proof-of-concept
> project, so it
> >>>>>>>>>>> isn't _that_ important to have the functionality right now).
> >>>>>>>>>>> Apologies for the rambling message. I was prompted to reach
> out by Ralph
> >>>>>>>>>>> Goers in the discussion for LOG4NET-606, so I hope I haven't
> been a
> >>>>>>>>>> bother.
> >>>>>>>>>>> -d
> >>>>>>>>>>> --
> >>>>>>>>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>>>>>>>>>> If you say that getting the money is the most important thing
> >>>>>>>>>>> You will spend your life completely wasting your time
> >>>>>>>>>>> You will be doing things you don't like doing
> >>>>>>>>>>> In order to go on living
> >>>>>>>>>>> That is, to go on doing things you don't like doing
> >>>>>>>>>>> Which is stupid.
> >>>>>>>>>>> - Alan Watts
> >>>>>>>>>>> https://www.youtube.com/watch?v=-gXTZM_uPMY
> >>>>>>>>>>> *Quidquid latine dictum sit, altum sonatur. *
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Matt Sicker
> >>
> >>
> >
> >
> > --
> > Matt Sicker
>
>
>

-- 
Dominik Psenner

Re: Log4Net

[Dominik Psenner]

Thanks Ralph for taking care of this.

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sun, Apr 5, 2020, 02:28 Ralph Goers  wrote:

> The steps to mark Log4jNet as inactive were:
>
> 1. Create a tag of the source.
> 2. Create an archive of the source to be placed in the logging
> distribution directory.
> 3. Modify the Log4Net web site to indicate it is dormant.
> 4. Modify the web site to include Log4Net in a list of dormant projects
> along with a description of what being dormant means.
> 5. Mark all LOG4NET issues as wont fix in Jira.
> 6. Ask INFRA to prevent new LOG4NET issues from being created.
>
> You should have received a VOTE email for items 1 & 2.
> I have completed item 3 with the exception of updating the download page
> to link to the source archive.
> I have completed item 4 and additionally added Log4j 1.x and Log4j extras
> as dormant sites.
> I added a comment to all open LOG4NET jira issues but I am not going to
> manually modify 218 issues.
> I created https://issues.apache.org/jira/browse/INFRA-20075 <
> https://issues.apache.org/jira/browse/INFRA-20075> for Jira to lock down
> Log4Net issues.
>
> Once the vote completes I will update the download page.
>
> Ralph

Re: [VOTE] Log4Net dormant release

[Dominik Psenner]

+1

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sun, Apr 5, 2020, 09:21 Volkan Yazıcı  wrote:

> +1
>
> On Sun, 5 Apr 2020, 00:25 Ralph Goers  wrote:
>
> > I have modified the STATUS.txt and README.txt for Log4Net, tagged the
> > source, zipped it and then published it to
> > https://dist.apache.org/repos/dist/dev/logging/log4net/ <
> > https://dist.apache.org/repos/dist/dev/logging/log4net/>.
> >
> > This is a vote to move those artifacts to the distribution release
> > directory.
> >
> > This vote will remain open for 72 hours.
> >
> > Ralph
>

Re: [VOTE] Move Log4net to dormant state

[Dominik Psenner]

+1

--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Mon, Mar 30, 2020, 16:44 Volkan Yazıcı  wrote:

> +1
>
> On Mon, Mar 30, 2020 at 12:23 AM Ralph Goers 
> wrote:
>
> > Seeing as there have been no volunteers after my last message regarding
> > Log4Net, I propose that it be moved to a dormant status.  This would
> simply
> > entail:
> > 1. Create a tag of the source.
> > 2. Create an archive of the source to be placed in the logging
> > distribution directory.
> > 3. Modify the Log4Net web site to indicate it is dormant.
> > 4. Modify the web site to include Log4Net in a list of dormant projects
> > along with a description of what being dormant means.
> > 5. Mark all LOG4NET issues as wont fix in Jira.
> > 6. Ask INFRA to prevent new LOG4NET issues from being created.
> >
> > This vote will be open for 72 hours.
> >
> > Ralph
> >
>

Re: [Discuss] Retire Log4net to the attic.

[Dominik Psenner]

On Sun, 22 Mar 2020 at 04:45, Brown, Michael  wrote:

> Are there better replacements for Log4net? What would it take to migrate
> to them?


It depends how far log4net is integrated into a codebase. There are good
interfaces available [1] to write code against. Dependency injection
frameworks have also become very popular [2]. If code is written against
these or any other generic interfaces, the underlying logging framework
implementation can be replaced easily. Of course there are also issues
relating to logging framework configuration files and others if parts of
the logging framework (i.e. log events via remote appender) have been
integrated into monitoring or application logic. This can be a challenging
task if the interfaces between the various parts of an application are
unclear. This situation may be a good moment to improve an existing
codebase. Or it could be a good reason to become the maintainer of log4net.
The PMC does support if at least three individuals step forward now. Please
note that the codebase of log4net does not disappear. It is still there,
hopefully for the public good.

[1]
https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.logging.ilogger?view=dotnet-plat-ext-3.1
[2]
https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.dependencyinjection?view=dotnet-plat-ext-3.1
-- 
Dominik Psenner

Re: Problem in RollingFileAppender and ConsoleAppender .net core log4net

[Dominik Psenner]

Hi Shubham Jain,

welcome to this mailing list. Plese consider subscribing to avoid future
manual interventions by a human moderator.

The application works with consoleappender enabled when run from console.
This indicates to me that the issue is related to the environment in
headless mode. The symptoms disappear when the consoleappender is disabled
in headless mode. This further indicates to me that the underlying root
cause is related to writing output to console when in headless mode.
Console output via the consoleappender is most probably not what you want
the application to do in headless mode anyway. Therefore consider windows
event logs or other sinks / appenders like databases or files when in
headless mode.

I can imagine that the root cause may be related to permission issues on
your server machine. For concrete clues you may even have to debug the
situation.

Good luck and let us know about your findings. Future readers are going to
be thankful for any valuable information they can get.

Dominik
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sun, Nov 3, 2019, 14:39 Shubham Jain  wrote:

> Hi,
>
> I am facing issue when trying to use both RollingFileAppender and
> ConsoleAppender in .net core log4net. We are launching a console
> application (.net core 3.0) from apache server. When we are launching the
> application from command prompt then everything works fine but when we
> launch the application from server, the application hangs at log.info()
> method after logging few lines.
>
> When I remove the   ConsoleAppender from log4net.config and relaunch the
> application from server then everything works perfectly.
>
> So, I came to the conclusion that this problem is happening due to multi
> appender use or some configuration issues.
>
> Our requirement is to logging on both file and console.Please help or
> suggest something to solve this problem.
>
> Thanks
> Shubham Jain
>

Re: Log4Net Extensions for ASPNet Core

[Dominik Psenner]

The codebase of your project could certainly be integrated into the apache
log4net project or apache logging family. This would further lay the path
to publish the project on nuget under the umbrella of Apache.Logging when a
formal release of that project is made. Brian, are you interested in
joining this community and as such become a maintainer of log4net? I ask
because the project is short on human resources and joint efforts would be
a great contribution!

On Wed, 30 Oct 2019 at 21:13, Matt Sicker  wrote:

> I'm not even sure how log4net is published on nuget, though any
> projects published under Apache there would have to be Apache
> projects. Perhaps another organization for extras or something would
> be useful here? There used to be something like that for log4j at
> least.
>
> On Wed, 30 Oct 2019 at 10:59, Brian Mello  wrote:
> >
> > I have written a small project that hooks log4net into asp net core
> architecture and am looking to publish the package to nuget under the
> apache foundation.
> >
> > Brian
> >
> >
> > Sent from Outlook<http://aka.ms/weboutlook>
>
>
>
> --
> Matt Sicker 
>


-- 
Dominik Psenner

Re: Is Log4Net project abandoned?

[Dominik Psenner]

Streamlining the architectures across the different log4* implementations
has been discussed earlier. It would make sense to split log4net into
several libraries (api, configuration, several appender.xxx, etc). Further
make these assemblies all available over nuget. I could imagine this to
become part of a not yet existing 3.0 milestone if the community is willing
to contribute. I see also more important things to flesh out (getting a
release out of the door, reimplement the rolling file appender, replace
nant to improve builds and their automation, automate deployments to nuget,
..).

On Tue, 17 Sep 2019 at 17:31, Matt Sicker  wrote:

> SLF4J is an earlier alternative to log4j-api, but it's not a
> replacement. If the other log4* projects adopt similar architectures
> to log4j2, they can all have API/implementation separation and
> potentially compatible config files, though that's not really planned
> by anyone that I know of.
>
> On Mon, 16 Sep 2019 at 23:15, Brown, Michael A  wrote:
> >
> > Any action on slf* as log4* replacement?
> >
> > I don’t have any issues with log4* or know a great deal about slf* but
> some of what I read indicates some developers moving in that direction.
> >
> > Any comments?
> >
> > Mike
> >
> > Get Outlook for iOS<https://aka.ms/o0ukef>
> > 
> > From: Dominik Psenner 
> > Sent: Monday, September 16, 2019 5:10:50 PM
> > To: dev@logging.apache.org 
> > Subject: Re: Is Log4Net project abandoned?
> >
> > I had this message in draft for quite some time now and just now I
> decided
> > to send it in a slightly modified version.
> >
> > While log4net has been around for a while it may have come the point in
> > time when it has reached end of life. A good indicator to me is the
> number
> > of active contributors. This means that the decision is obviously
> community
> > driven. So long people step up and get involved the project is healthy.
> Me
> > being the only one to do releases, review and apply PR, etc does not
> scale.
> > Any contribution is welcome!
> >
> > Best regards
> > --
> > Dominik Psenner
> >
> > On Sat, Jun 29, 2019, 20:00 Kabilan VK  wrote:
> >
> > > The last commit was on 2017 so, its becoming a less favor to new
> startup
> > > projects. I tried to contribute by adding latest .net framework
> support so,
> > > at least need a PR review support to get this on track.
> > > Thanks for understanding.
> > >
> > > Regards,
> > > Kabilan
> > >
> > > On Sat, 29 Jun, 2019, 4:31 AM Jochen Wiedmann, <
> jochen.wiedm...@gmail.com>
> > > wrote:
> > >
> > > > On Sat, Jun 29, 2019 at 1:21 PM Dominik Psenner 
> > > > wrote:
> > > > > We could also push log4net back to incubation. What do you think?
> > > >
> > > > If availability of people is an issue, then this would be an
> excellent
> > > > way of exhausting those even more.
> > > >
> > > > Jochen
> > > >
> > >
> > >
>
>
>
> --
> Matt Sicker 
>


-- 
Dominik Psenner

Re: Is Log4Net project abandoned?

[Dominik Psenner]

I had this message in draft for quite some time now and just now I decided
to send it in a slightly modified version.

While log4net has been around for a while it may have come the point in
time when it has reached end of life. A good indicator to me is the number
of active contributors. This means that the decision is obviously community
driven. So long people step up and get involved the project is healthy. Me
being the only one to do releases, review and apply PR, etc does not scale.
Any contribution is welcome!

Best regards
--
Dominik Psenner

On Sat, Jun 29, 2019, 20:00 Kabilan VK  wrote:

> The last commit was on 2017 so, its becoming a less favor to new startup
> projects. I tried to contribute by adding latest .net framework support so,
> at least need a PR review support to get this on track.
> Thanks for understanding.
>
> Regards,
> Kabilan
>
> On Sat, 29 Jun, 2019, 4:31 AM Jochen Wiedmann, 
> wrote:
>
> > On Sat, Jun 29, 2019 at 1:21 PM Dominik Psenner 
> > wrote:
> > > We could also push log4net back to incubation. What do you think?
> >
> > If availability of people is an issue, then this would be an excellent
> > way of exhausting those even more.
> >
> > Jochen
> >
>
>

Re: Is Log4Net project abandoned?

[Dominik Psenner]

Hey,

Thanks Matt for providing feedback on the project. I am better at the
moment but still have hard limits in place regarding the time I spend in
front of computers because it does me good.

Given the limited resources I am donating to the project there won't be
noticable progress in the foreseeable future.

To repopulate the set of developers we could lower the bar for adding new
committers. We could also push log4net back to incubation. What do you
think?
--
Dominik Psenner

On Fri, Jun 28, 2019, 17:22 Matt Sicker  wrote:

> It is not abandoned; it is in need of more developers. One of the more
> active developers of that project is currently ill, however, and most
> of the rest of us here aren't that familiar with .NET. I do have
> intentions to try and make a release soon, though, but I'm not that
> familiar with the codebase for PRs.
>
> On Fri, 28 Jun 2019 at 09:47, Kabilan VK  wrote:
> >
> > Is it abandoned, why no one responds for any review or contribution
> > questions?
> >
> > Regards,
> > Kabilan
>
>
>
> --
> Matt Sicker 
>

Re: Filename too long

[Dominik Psenner]

Thanks Thorsten! I was not aware of these changes. Finally a step into the
right direction. I wonder when the (not so) "special" characters ":?" will
become acceptable in file and directory names..
--
Dominik Psenner

On Thu, Feb 21, 2019, 11:22 Thorsten Schöning  Guten Tag Dominik Psenner,
> am Sonntag, 2. Dezember 2018 um 08:58 schrieben Sie:
>
> > Unfortunately windows in the year
> > 2018 still has a fixed path limit of something along 260 characters.
>
> It doesn't:
>
> > The Windows API has many functions that also have Unicode versions
> > to permit an extended-length path for a maximum total path length of
> > 32,767 characters.
>
>
> https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#maximum-path-length-limitation
>
> In case of legacy software which doesn't care about long Unicode paths
> being available for decades:
>
> > Starting in Windows 10, version 1607, MAX_PATH limitations have been
> > removed from common Win32 file and directory functions. However, you
> > must opt-in to the new behavior.
>
> > HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type:
> REG_DWORD)
> > Computer Configuration > Administrative Templates > System > Filesystem
> > Enable NTFS long paths
>
>
> https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#maximum-path-length-limitation
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
>
> Telefon...05151-  9468- 55
> Fax...05151-  9468- 88
> Mobil..0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
>

Re: [log4net] RollingFileAppender extension that backs up only a last specified period (days, hours, etc.)

[Dominik Psenner]

On 2018-12-19 20:55, Farhan Nasim wrote:

1. Thanks for informing about the 'next generation' RollingFileAppender. I
have been going through your feature branch and it seems to be the right
futuristic path. I'd like to contribute to it.


Awesome! Let me know if I can help you in any way.


2. However, I have queries regarding the faster way to make my appender to
productio. Putting together the subset of RollingFileAppender
functionalities in its NG counterpart will take some time and the NG
appender will take some time to be popular too.
The NG counterpart should explicitly provide only a very small subset of 
the original functionality. Less is more. To provide people a migration 
path, it should support custom rolling strategies. The coupling between 
the rolling strategy and the appender should be as small as possible.


On the other hand, the appender I am proposing (derived from
RollingFileAppender) is nearly complete. RollingFileAppender has many
issues, but still it is the most popular I think and is quite acceptable in
low-strain conditions. How about reusing RollingFileAppender for now and
working on the NG at the same time, for future releases? Or is it the
resolution across log4net that "no more extensions to RollingFileAppender"?
:D


The RollingFileAppender has a long history and survived several futile 
attempts to improve it. Some of those attempts even caused collateral 
damage for the many use cases that it has grown to be used for. It 
should be touched with outermost care.



3. In order to contribute, shall I create a new branch from the NG feature
branch, make changes, and send pull requests into the NG branch? Or can I
commit directly to NG branch?


That's up to you.

1. If you want to help writing the next generation RFA, the branch to 
base your contribution on is probably feature/RollingFileAppender-NG. 
You should merge develop into that branch to avoid these branches drift 
apart.


2. If you are going to contribute to the existing RollingFileAppender, 
the branch feature/rfa-configurable-rolling-mutex is probably the right 
place. That branch however needs proper testing to be merged into 
develop. It would be great if you could help us with testing, too. :-)


3. You probably also noticed that there's a release branch, tracking 
what changes are going to be part of the next release 2.1.0. That branch 
also needs proper testing, possibly by using the binaries that jenkins 
builds for us. The plan is to use those binaries in the release process 
but the lack of testing is a blocker for the release process of 2.1.0. I 
feel uncomfortable with publishing binaries built by jenkins for the 
first time without a basic test for every published binary. I thought of 
pushing several sample projects to github that both serve as templates 
but also as testing sandboxes of more realistic environments. Help from 
the community is of course greatly appreciated.


Cheers,
Dominik

Re: [log4net] RollingFileAppender extension that backs up only a last specified period (days, hours, etc.)

[Dominik Psenner]

Hi Farhan,

it's great to see your interest in the logging framework log4net. I'm 
commenting inline below ..


On 2018-12-13 23:31, Farhan Nasim wrote:

Have encountered a scenario in many projects where log files covering only
a last user specified period is needed (e.g. last 5 days, last 3 hours,
etc.) So far, Log4net doesn't provide any such appender out of the box; the
RollingFileAppender only supports backing up a number of last files
(maxSizeRollBackups).


This is a valid usecase.


1. I am writing an appender (made some progress in fact) that derives
from *RollingFileAppender
*and serves the purpose. It takes a string denoting a TimeSpan as parameter
and keeps files falling only in this period. It follows Log4net conventions
and it is tested for minutes to days periods. Is Log4net willing to include
any similar appender?


The RollingFileAppender is probably not the ideal base to start off your 
work. I already put
effort into re-writing the RollingFileAppender where the rolling 
strategy is pluggable. Would
you like to continue or derive from that work? The branch is 
feature/RollingFileAppender-NG [1].
Unfortunately I had so far not the time to complete this. We do observe 
that a major part of
reported issues is related to the current implementation of the 
RollingFileAppender and would like
to improve this situation. The next generation rolling file appender 
should probably only provide
a subset of the functionality that its predecessor offered but should 
become more stable.



2. I need some critical feedbacks on naming and conventions. Am I supposed
to submit my changes as a pull request or have them discussed here?


A good place to discuss source code contributions is github in the form 
of a pull request. You'll
also benefit from the continuous integration. Jenkins builds each pull 
requests and you can examine
the build outputs etc. Please try to keep your pull requests short and 
concise to allow easy reviews.


[1] 
https://github.com/apache/logging-log4net/tree/feature/RollingFileAppender-NG

Re: Filename too long

[Dominik Psenner]

As a guideline I recommend my fellow developers to not have reduntant names
in the directory paths of a repository. In your example I counted 4 times
hadoop-yarn which is 3 times too many. Unfortunately windows in the year
2018 still has a fixed path limit of something along 260 characters.

--
Dominik Psenner

On Sun, Dec 2, 2018, 07:22 Ralph Goers  Never mind. Figured out the solution.
>
> Ralph
>
> > On Dec 1, 2018, at 11:06 PM, Ralph Goers 
> wrote:
> >
> > Gary, when I clone the git repo to my Windows VM I am getting the error
> message
> >
> > error: unable to create file
> log4j-1.2-api/src/test/resources/config-1.2/hadoop/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-unmanaged-am-launcher/src/test/resources/log4j.properties:
> Filename too long
> >
> > How are you dealing with this?
> >
> > Ralph
> >
>
>
>

Fwd: log4net / .ner core 2.1 / SmtpAppender

[Dominik Psenner]

Apparently I forgot to add dev at logging dot apache dot org to the
recipients. Here comes the last message as a forward.

-- Forwarded message -
From: Dominik Psenner 
Date: Mon, 22 Oct 2018 at 13:57
Subject: Re: log4net / .ner core 2.1 / SmtpAppender
To: Michael Karmazin (public) 



On 2018-10-22 12:36, Michael Karmazin (public) wrote:
> As for getting involved: I'd be happy too... when I've got time. As the
> first and minimum thing, I can start using the release branch now. I
> understand it's the 'release/2.1.0' branch - ok I'll build and hook it up.

Awesome. Thanks. Do not hesitate to try the binaries built against
different frameworks. Note
that the binaries are also available from nightly builds over here [1].

> BTW here is the first problem to report with the documentation - sorry
> doing it here rather than using jira, I promise will do the bug tracker
for
> any subsequent problems...
>
> [image: image.png]
> This is the first code snippet from the Introduction page, and the first
> method in the snippet... is just not there in the library :-/
> Yes it's not there for .NET Core only, but I guess the current most
popular
> flavour of .NET family can't be ignored in such a way in the doco. Just
> imaging how puzzled would be a newcomer.
> https://logging.apache.org/log4net/release/manual/introduction.html
>
> I think that the Intro page really needs to be adapted to the current
> limitation of the used .NET Core version, as well as in all places where
> this simplest form of GetLogger is mentioned in the manual. Or maybe find
a
> way to return it into LogManager even for .NET Core 1.x? This would be the
> ideal I guess.

As pointed out in the previous mail, I would like to have the
netstandard-1.3 target improved before
tackling netstandard-2.0. The documentation and site is in the
repository and definitely needs to be
improved. This again brings us back to the project needs for human
resources.

I assume that those developers notice any discrepancies between
"documentation" vs "code" when
targeting the netstandard build of log4net. If there's any documentation
missing I will gladly accept
any contribution - be it a patch or pull request on github - that
improves the situation.

> Also, it would help if all appenders that are not in the .NET Core would
be
> clearly marked as such everywhere in the documentation where they're
> mentioned.

Memory may betray me now, but as far as I can recall there should be a
compatbility table, chart or something
similar somewhere. I would mention the source if I had the possibility
to look it up for the readers out there.

>
> Anyway, like I said I will start using the 2.1 branch version, and will
> file any issues into Jira if I find anything.

Do not hesitate to ping back on the mailing list or jira - whatever
transport fits best the kind of question you have.
I am here to guide wherever I can.

[1] https://builds.apache.org/job/logging-log4net/

Re: log4net / .ner core 2.1 / SmtpAppender

[Dominik Psenner]

Hi Michael,

it's great to see your interest in log4net. I'm responding inline ..


On 2018-10-22 04:14, Michael Karmazin (public) wrote:

Hi Dominik,

I've got your email from the log4net repo on GitHub - sorry if it's a wrong
way to contact the log4net team, but I did not find any other.


There's a mailing list, see [1] for more information. As an alternative 
there's also the issue tracker, see [2]

for more information.


I was happily using log4net for years under the classic .NET framework
(log4net is an awesome logging tool btw), but now I moved to .NET Core 2.1,
and seems not everything is supported there which is a bit disappointing.

Is there any plans to support SmtpAppender in log4net under .NET? I
understand it's not supported now because log4net 2.0.8 is built for .NET
Core 1.x which does not support SmtpClient.


If support for netstandard-2.0 is added, adding the SmtpAppender is just 
a precompiler directive.



So, is there any chance we'll see soon a log4net release targeting .NET
Core 2.1??


There are plans but the project needs human resources to get the plans 
done. We have a release branch
open since several months now without much progress. However, before 
adding another framework target
I want to get 2.1.0 released to provide people with an upgrade path. 
Then we can continue working on the

netstandard-2.0 branch.

This said I'm glad you're reaching out to the community. Would you like 
to get involved? We need people to test
the current release branch, review the documentation, work through open 
issues, ..


[1] https://logging.apache.org/log4net/mail-lists.html
[2] https://logging.apache.org/log4net/issue-tracking.html

LOG4NET: LOG4NET-611

[Dominik Psenner]

Hi,

Heads up developers that have built or run applications with medium trust.
I just pushed a change into a feature branch to fix the given issue and
request for comments.

Is the change ok for you? Does it break your applications? Have you
insights that you want to share?

Here's the diff:
https://github.com/apache/logging-log4net/commit/e769e01b85db9a8afe22ff8fdd6cc4d8f0c8ee34

I am inclined to drop support for partially trusted environments also for
the other targets. If that's not a path that you can walk, then we should
talk.

Cheers
-- 
Dominik Psenner

Re: Vacation

[Dominik Psenner]

Please install a radio jammer and enjoy the time! :-)


On 2018-09-17 02:57, Gary Gregory wrote:

I've been told all beach umbrellas form a mesh network. No escape.

Gary

On Sun, Sep 16, 2018 at 6:38 PM Remko Popma  wrote:


Don’t the beaches have Wi-Fi?

Just kidding. :-)
Enjoy!




On Sep 17, 2018, at 9:03, Gary Gregory  wrote:

Enjoy!

Gary


On Sun, Sep 16, 2018, 17:30 Ralph Goers 

wrote:


Just to let you know, I am on vacation in Hawaii so. I should have some
free time while I am here but responses to email will be delayed during

the

next 10 days.

Ralph

Re: Build failed in Jenkins: logging-log4net » PR-24 #1

[Dominik Psenner]

In theory, yes. Creating a (windows) docker container that provides nant 
by downloading it from the internet should be straight forward. I 
pointed out the windows docker option to Chris when he first announced 
the new windows-2016 nodes. But so far I have only very limited 
experience with windows docker containers and I am not sure whether we 
should rather drop the support for ancient frameworks and only target 
log4net against netstandard-2.0 in the future. This however will drop 
support for quite a few appenders that are windows specific and again 
needs a ton of refactoring in the codebase. It resembles much on what 
was already done with modularizing log4j into api, core etc.


On 2018-07-31 15:09, Matt Sicker wrote:

Is it possible to run nant in a Docker container? I’m not too familiar with
Windows containers.

On Tue, Jul 31, 2018 at 06:55, Dominik Psenner  wrote:


I assume that nant was purged from this node with the last
infrastructure update. I can well understand this decision because nant
is an abandoned tool that is heavily outdated. We should have moved away
from it already. Unfortunately this means rewriting all the build
scripts that automate building, testing, generating the assembly version
files, generating the website, .. a total of about 3000 lines of code in
xml format. This is definitely a major task that takes days if not weeks
of development and testing. *sigh*


On 2018-07-30 20:13, Matt Sicker wrote:

Oh no, this is similar to the java 10 errors in log4j2.

On Mon, 30 Jul 2018 at 11:27, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:


See <


https://builds.apache.org/job/logging-log4net/job/PR-24/1/display/redirect

--
Branch indexing
Connecting to https://api.github.com using dpsenner/** (dpsenner at
github)
Loading trusted files from base branch master at
c04a774240fd4500ed3206124aba5b4bc8bc4933 rather than
42ddcc6379c1e007bba5bb9395aa1432a0be5d35
Obtained Jenkinsfile from c04a774240fd4500ed3206124aba5b4bc8bc4933
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] node
Running on windows-2016-1 in


f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-24-ZGRT4SQ4XLNPR46J4HOG7YQVBJMEQEYWIESHIXY2YXRL6LFYGWWA

[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://github.com/apache/logging-log4net.git
   > git init


f:\jenkins\jenkins-slave\workspace\logging-log4net_PR-24-ZGRT4SQ4XLNPR46J4HOG7YQVBJMEQEYWIESHIXY2YXRL6LFYGWWA

# timeout=10
Fetching upstream changes from
https://github.com/apache/logging-log4net.git
   > git --version # timeout=10
using GIT_ASKPASS to set credentials dpsenner at github
   > git fetch --no-tags --progress
https://github.com/apache/logging-log4net.git
+refs/pull/24/head:refs/remotes/origin/PR-24
+refs/heads/master:refs/remotes/origin/master
   > git config remote.origin.url
https://github.com/apache/logging-log4net.git # timeout=10
   > git config --add remote.origin.fetch
+refs/pull/24/head:refs/remotes/origin/PR-24 # timeout=10
   > git config --add remote.origin.fetch
+refs/heads/master:refs/remotes/origin/master # timeout=10
   > git config remote.origin.url
https://github.com/apache/logging-log4net.git # timeout=10
Fetching without tags
Fetching upstream changes from
https://github.com/apache/logging-log4net.git
using GIT_ASKPASS to set credentials dpsenner at github
   > git fetch --no-tags --progress
https://github.com/apache/logging-log4net.git
+refs/pull/24/head:refs/remotes/origin/PR-24
+refs/heads/master:refs/remotes/origin/master
Merging remotes/origin/master commit
c04a774240fd4500ed3206124aba5b4bc8bc4933 into PR head commit
42ddcc6379c1e007bba5bb9395aa1432a0be5d35
   > git config core.sparsecheckout # timeout=10
   > git checkout -f 42ddcc6379c1e007bba5bb9395aa1432a0be5d35
   > git merge c04a774240fd4500ed3206124aba5b4bc8bc4933 # timeout=10
   > git rev-parse "HEAD^{commit}" # timeout=10
Merge succeeded, producing 42ddcc6379c1e007bba5bb9395aa1432a0be5d35
Checking out Revision 42ddcc6379c1e007bba5bb9395aa1432a0be5d35 (PR-24)
   > git config core.sparsecheckout # timeout=10
   > git checkout -f 42ddcc6379c1e007bba5bb9395aa1432a0be5d35
Commit message: "Fixed Spelling."
First time build. Skipping changelog.
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] timeout
Timeout set to expire in 1 hr 0 min
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Tool Install)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Checkout)
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] tool
[Pipeline] envVarsForTool
[Pipeline] withEnv
[Pipeline] {
[Pipeline] checkout

Re: Build failed in Jenkins: Log4j 2 3.x #148

[Dominik Psenner]

Jenkins slaves currently have very low disk space. This may be a out of
disk space in disguise.

On Sat, 21 Jul 2018, 14:12 Rob Tompkins,  wrote:

> Looks like Jenkins timed out on checkout or something.
>
> > On Jul 20, 2018, at 1:08 PM, Ralph Goers 
> wrote:
> >
> > No idea.
> >
> > Ralph
> >
> >> On Jul 20, 2018, at 9:56 AM, Gary Gregory 
> wrote:
> >>
> >> Could this be a corrupt local repo or an out of disk space issue?
> >>
> >> Gary
> >>
> >> On Fri, Jul 20, 2018 at 10:44 AM Apache Jenkins Server <
> >> jenk...@builds.apache.org> wrote:
> >>
> >>> See <
> https://builds.apache.org/job/Log4j%202%203.x/148/display/redirect>
> >>>
> >>> --
> >>> Started by an SCM change
> >>> [EnvInject] - Loading node environment variables.
> >>> Building remotely on H35 (ubuntu xenial) in workspace <
> >>> https://builds.apache.org/job/Log4j%202%203.x/ws/>
>  git rev-parse --is-inside-work-tree # timeout=10
> >>> Fetching changes from the remote Git repository
>  git config remote.origin.url
> >>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git #
> timeout=10
> >>> Cleaning workspace
>  git rev-parse --verify HEAD # timeout=10
> >>> Resetting working tree
>  git reset --hard # timeout=10
> >>> ERROR: Error fetching remote repo 'origin'
> >>> hudson.plugins.git.GitException: Failed to fetch from
> >>> https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
> >>>   at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:888)
> >>>   at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1155)
> >>>   at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186)
> >>>   at hudson.scm.SCM.checkout(SCM.java:504)
> >>>   at
> hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
> >>>   at
> >>>
> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
> >>>   at
> >>> jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
> >>>   at
> >>>
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
> >>>   at hudson.model.Run.execute(Run.java:1794)
> >>>   at
> >>> hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
> >>>   at
> >>> hudson.model.ResourceController.execute(ResourceController.java:97)
> >>>   at hudson.model.Executor.run(Executor.java:429)
> >>> Caused by: hudson.plugins.git.GitException: Command "git reset --hard"
> >>> returned status code 128:
> >>> stdout:
> >>> stderr: fatal: unable to read tree
> 0ea7b3d65fb95137b65531d1c9277951123986a6
> >>>
> >>>   at
> >>>
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2002)
> >>>   at
> >>>
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1970)
> >>>   at
> >>>
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1966)
> >>>   at
> >>>
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1597)
> >>>   at
> >>>
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.reset(CliGitAPIImpl.java:463)
> >>>   at
> >>>
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:786)
> >>>   at hudson.plugins.git.GitAPI.clean(GitAPI.java:311)
> >>>   at sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source)
> >>>   at
> >>>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>>   at java.lang.reflect.Method.invoke(Method.java:498)
> >>>   at
> >>>
> hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:929)
> >>>   at
> >>>
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:903)
> >>>   at
> >>>
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:855)
> >>>   at hudson.remoting.UserRequest.perform(UserRequest.java:212)
> >>>   at hudson.remoting.UserRequest.perform(UserRequest.java:54)
> >>>   at hudson.remoting.Request$2.run(Request.java:369)
> >>>   at
> >>>
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> >>>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> >>>   at
> >>>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> >>>   at
> >>>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> >>>   at java.lang.Thread.run(Thread.java:748)
> >>>   Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote
> >>> call to H35
> >>>   at
> >>> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741)
> >>>   at
> >>>
> hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
> >>>   at hudson.remoting.Channel.call(Channel.java:955)
> >>>   at
> >>>
> 

Re: Fwd: [NuGet Gallery] Message for owners of the package 'log4net'

[Dominik Psenner]

On 2018-07-19 22:17, sean.co...@gmail.com wrote:

Dominik,

There are a number of issues in your tracker that are directly related to 
sticking with NetStandard 1.3.  That was an early release and must have been 
painful to try to do a full implementation of Log4Net.  2 issues dear to me are 
Variable Expansion (Environment.GetEnvironmentVariable was not implemented in 
1.3, but was in 1.4) and Line Numbers (StackTrace in 1.3 was not fully 
implemented, but was added by 1.5).

Personally I see NetStandard 2.0 as the first release where a large project could be 
ported, or started from scratch in .Net Core.  It finally has the features and the 
performance to be a contender with .Net and other languages (NodeJs, Java, etc).  We're 
coding on Windows/Mac and deploying on RHEL 7.  Having a full implementation of log4net 
is very important.  NetStandard 1.3 implemented "most" of log4net.  NetStandard 
could bring the rest of the missing features.

BTW, some list of what is missing might be good.  Unless i missed it, it's left 
up to the user to discover.


Hi Sean,

I love to see your interest in log4net and I'll gladly help with 
information and guidance where ever I can.


The netstandard-1.3 target came in as a patch. I'm afraid the original 
contributor will not maintain that contribution. Personally, I would 
drop the support for the netstandard-1.3 target and replace it with 
netstandard-2.0. I also see netstandard-2.0 as a good candidate to 
become the one and only supported target framework. This would greatly 
reduce the maintenance hell we're currently in because of the dozens of 
framework targets that log4net currently supports. Unfortunately such a 
decision would break compatibility with previous releases and would also 
drop the support for long living targets like net-2.0. Further it is far 
beyond the reach of any future release with the human resources that the 
project has available at the moment. This means that it is left up to 
the community to decide about the future of log4net. As stated in a 
previous comment about this topic, I also envision to re-shape log4net 
into a core assembly along with various satellite assemblies that 
provide appenders and other functionality. Such a move can be made when 
the community decides to break backwards compatibility.


I'm willing to invest time into these topics and am intrigued to look 
forward to the future of this project. At the same time I see it as a 
requirement that more people step up to help shaping the future of 
log4net. Until today I've invested into reducing the number of hurdles 
developers have to face when starting to contribute to log4net, for 
example by improving the continuous integration. Unfortunately this has 
not yet produced the results that I hoped for but I'll keep that task up 
with the time that I can donate to the community.


Cheers,
Dominik

Re: AdoNetAppenderIssue Multithreaded Application Freeze

[Dominik Psenner]

Hi Sebastian,

this is spot on. If you're not subscribed to the mailing list yet, it's a
good time to do so now.

At first sight I would argue that in a typical deployment, database tables
are created by the system administrator during setup. I cannot recommend to
create them later on the fly. If a system administrator is a bit of
nitpicky kind he will most likely even revoke the privileges of an
application to create or drop tables. When 64 threads try to create the
same table at the same time as you describe it here I would expect 63
threads to fail with an exception. I do not know how the adonetappender
reacts to such a situation. If it fails with an exception, the logging
system should fail stop and output an error log to the internal logging.

Please note that from an architecture point of view you may want to buffer
events before flushing them to the database and you will further want to
filter events such that the throughput stays well below 500 to 1000 events
per second. These numbers obviously depend on the infrastructure of your
database server and application etc but I would not require the database to
chew more than that when it should do also other things beyond persisting
log events.

Best regards,
Dominik

Am Do., 12. Juli 2018 um 18:14 Uhr schrieb Morgenbesser, Sebastian <
sebastian.morgenbes...@rubicon.eu>:

> Hi,
>
>
>
> I am Sebastian and working for a Software company in Vienna.
>
> I recently noticed a strange issue with log4net and the AdoNetAppender and
> it would be nice if anyone could comment on this.
>
>
>
> Its quite an Edge Case I know but the implication is that the Application
> will freeze and no Exception is thrown which is kind of scary.
>
> I have made a small example C# project to illustrate the issue which I can
> provide, but first I want to explain the issue.
>
>
>
> The scenario is like this:
>
> · Visual Studio C# Console Application. Log4net (latest version)
> embedded as dll, MS SQL Server 2016 (but I guess this doesn’t matter), .NET
> Framework > 4.5
>
> · The Application starts and the Logger is initialized
> (containing a AdoNetAppender pointing to an existing Database on MS SQL
> Server – localhost)
>
> o   The code is something like this:
>
> o
>
> · After that happened, the Application is going to DROP the
> Database containing the Table that log4net will log to and recreates the
> database with all tables
>
> o   This happens because every time the console starts the Log-Database
> should be empty  (I know there are other ways like truncate oder Drop Table
> but lets stay with me to understand the problem)
>
> · So at this point the Database containing the Log Table has been
> recreated.
>
> · Now the Application starts a number Threads (in my example 64,
> but I guess it works with less) and waits for them to finish
>
> · In the Do() Method of the Thread, the thread simply tries to
> log an Error Message to the previously initialized logger
>
> · The Result is that the Application freezes and will never
> return (0% CPU). Also no log messages arrive in the database.
>
> · I am guessing there is some kind of deadlock situation inside
> log4net if multiple threads try to “initialize” the database connection to
> the recreated database again but in detail I have no idea what happens.
>
> · No exception is thrown, the threads just never finish there
> Do() Method
>
>
>
> So if I skip the part where I Recreate the database (with DROP und CREATE
> Database), then it works.
>
> Also if put a log statement after the recreation of the database but
> BEFORE the multithreaded part starts, it also works.
>
>
>
> Please advise what to do, is this the right place to address such an issue
> or should it be posted as an issue on jira?
>
>
>
> Greets
>
> Sebastian Morgenbesser
>
>
>
>
>


-- 
Dominik Psenner

Fwd: [NuGet Gallery] Message for owners of the package 'log4net'

[Dominik Psenner]

Hi Bart,

thanks for your interest in log4net. There's an issue for this and we 
have an open pull request that adds this target. We have however no plan 
yet of when this should happen. By targeting log4net against 
netstandard-1.3 it can be referenced from that netstandard and any 
netstandard from that onwards. Therefore we do not see any functional 
requirement that explains of why we should add netstandard-2.0 as a 
target. Would you like to join the mailing list (dev@logging.apache.org) 
to explain further why you would like to have log4net add the 
netstandard-2.0 target on top of netstandard-1.3?


Best regards,
Dominik



 Forwarded Message 
Subject:[NuGet Gallery] Message for owners of the package 'log4net'
Date:   Wed, 27 Jun 2018 22:01:04 +
From:   NuGet Gallery 
Reply-To: 	Logging PMC , bartsipes 


To: Apache.Logging 



_User bartsipes [disclosed-email] sends the following message to the 
owners of Package '[log4net 2.0.8](https://www.nuget.org/packages/log4net/2.0.8)'._

Hi, will you be updating log4net to target .NET Standard 2.0 any time soon?

Thanks, Bart.

---

To stop receiving contact emails as an owner of this package, sign in to 
the NuGet Gallery and
[change your email notification settings](https://www.nuget.org/account).

Re: [log4net] crafting the next release

[Dominik Psenner]

On Mon, 18 Jun 2018, 09:12 Stefan Bodewig,  wrote:

> On 2018-06-17, Dominik Psenner wrote:
>
> > Am Fr., 15. Juni 2018 um 10:53 Uhr schrieb Stefan Bodewig <
> > bode...@apache.org>:
>
> >> On 2018-06-13, Dominik Psenner wrote:
>
> >>> That is possible. I restricted access to the github token to the
> log4net
> >>> build job only. Stefan, would you like to try whether you can gain
> access
> >>> to that token? I can guide you to where you can find it off-list.
>
> >> Sorry, still travelling. Even if I don't manage to see the token, it is
> >> only going to prove to me that I'm not skilled enough :-)
>
> > I'm sure that wouldn't be the case. All popular ci systems provide secret
> > environment variables as a feature. Without that most devops usecases
> > wouldn't be possible.
>
> Access to most of the CI systems used for said devops use cases is
> controlled much more tightly then to our Jenkins, though.
>
> >> Personally I'd want to verify the contents of the archive anyway (as
> >> part of vetting the relase) and don't see any problem with signing them
> >> offline on my own machine at that point in time (or anybody else of us
> >> doing so). To me signing and uploading the ZIPs to dist.a.o doesn't have
> >> to be automated, YMMV.
>
> > We can agree to keep a few manual steps as long as these steps are as few
> > as possible. Signing and uploading to dist.a.o and nuget can be one of
> them.
>
> Fine with me.
>
> > If there are no objections I would freeze the codebase in 72h from now by
> > creating a release branch from whatever commit develop points to on
> > 2018-06-17 at 21:30 CEST (19:30 UTC).
>
> Do you know how to create the oldkeys binaries?  Or will we just no
> longer provide them (I could live with that).
>

I have no idea, yet. :-) people had a long time to adapt to newkey
binaries. If they have not migrated yet, they can as well do now.

Do you have preferences on the version? I opt for 2.1.0 but would be fine
with 2.0.9 too.

Re: [VOTE] Migrate git repositories to gitbox

[Dominik Psenner]

Moving to gitbox would give github users ci outputs and thus provide
automated feedbacks from ci when pull requests are built.

https://issues.apache.org/jira/plugins/servlet/mobile#issue/INFRA-14492/comment/16516065

On Thu, 14 Jun 2018, 16:57 Matt Sicker,  wrote:

> I haven't had a chance to follow up with Infra (since I know this will take
> a bit of collaboration to change). I'm thinking to start backwards from any
> repos that don't have any upcoming or recent releases, then progressing
> forward until all of them have been moved.
>
> On 13 June 2018 at 20:19, Ralph Goers  wrote:
>
> > Whatever happened with this?
> >
> > Ralph
> >
> > > On May 7, 2018, at 8:38 AM, Matt Sicker  wrote:
> > >
> > > And here is my +1.
> > >
> > > This vote passes with 5 +1s binding and 1 +1 non-binding. I'll follow
> up
> > > with the migration details over the next couple days.
> > >
> > > On 30 April 2018 at 07:04, Apache  wrote:
> > >
> > >> +1
> > >>
> > >> Ralph
> > >>
> > >>
> > >>> On Apr 29, 2018, at 7:38 PM, Ílson Bolzan 
> wrote:
> > >>>
> > >>> +1
> > >>>
> > >>>> On Sun, Apr 29, 2018 at 3:20 PM, Matt Sicker 
> > wrote:
> > >>>>
> > >>>> Good point on the clarification. I said all git repos, and that
> > actually
> > >>>> entails:
> > >>>>
> > >>>> * chainsaw
> > >>>> * log4cxx
> > >>>> * log4j2 and all its repos
> > >>>> * log4net
> > >>>> * log4php
> > >>>> * parent pom
> > >>>>
> > >>>> In fact, the only repos this doesn't cover are the old log4j 1 svn
> > repos
> > >>>> that we have.
> > >>>>
> > >>>>> On 29 April 2018 at 05:08, Dominik Psenner 
> > wrote:
> > >>>>>
> > >>>>> +1
> > >>>>>
> > >>>>> Also for the log4net repository.
> > >>>>>
> > >>>>>> On Sat, 28 Apr 2018, 23:59 Remko Popma, 
> > >> wrote:
> > >>>>>>
> > >>>>>> +1
> > >>>>>>
> > >>>>>> On Sat, Apr 28, 2018 at 11:48 PM, Gary Gregory <
> > >> garydgreg...@gmail.com
> > >>>>>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> +1
> > >>>>>>>
> > >>>>>>> Gary
> > >>>>>>>
> > >>>>>>>> On Sat, Apr 28, 2018, 17:12 Matt Sicker 
> wrote:
> > >>>>>>>>
> > >>>>>>>> This is a vote to migrate from the existing git-wip-us
> > >>>> infrastructure
> > >>>>>> to
> > >>>>>>>> the currently supported gitbox infrastructure that Infra
> advocates
> > >>>>> for
> > >>>>>>>> using nowadays. Using gitbox will allow our projects to
> integrate
> > >>>>>> better
> > >>>>>>>> with GitHub including the ability to merge PRs directly from the
> > >>>> site
> > >>>>>> and
> > >>>>>>>> the ability to push commits to GitHub and have them be
> > >>>> automatically
> > >>>>>>>> mirrored back to Apache. Not only that, but new Apache projects
> > >>>>> cannot
> > >>>>>>> use
> > >>>>>>>> the old git-wip-us infrastructure anymore, so it makes sense to
> > >>>>> migrate
> > >>>>>>> to
> > >>>>>>>> the best supported option going forward.
> > >>>>>>>>
> > >>>>>>>> The migration process will entail the following:
> > >>>>>>>>
> > >>>>>>>> * Marking existing git repo as read-only
> > >>>>>>>> * Moving repo to gitbox
> > >>>>>>>> * Update website and pom.xml with new SCM URLs
> > >>>>>>>> * Update local git clones with the new remote URL(s)
> > >>>>>>>>
> > >>>>>>>> Note that this vote only applies to the source code. I'm not
> > >>>>>> considering
> > >>>>>>>> using GitHub Issues instead of Jira, for example. Note also that
> > >>>> this
> > >>>>>>> vote
> > >>>>>>>> does not apply to the use of subversion for publishing the site
> > >>>>>>> (svnpubsub)
> > >>>>>>>> nor the use of it for publishing releases (only available via
> > svn),
> > >>>>>>> though
> > >>>>>>>> moving the sites from svnpubsub to gitpubsub (i.e., storing the
> > >>>>>> generated
> > >>>>>>>> site in a branch called "asf-site", similar to the "gh-pages"
> > >>>> branch
> > >>>>>>>> feature on GitHub) would be a related topic to cover separately.
> > >>>>>>>>
> > >>>>>>>> Please vote +1, +0, -0, or -1.
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Matt Sicker 
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Matt Sicker 
> > >>>>
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > Matt Sicker 
> >
> >
> >
>
>
> --
> Matt Sicker 
>

Re: [log4net] crafting the next release

[Dominik Psenner]

Am Fr., 15. Juni 2018 um 10:53 Uhr schrieb Stefan Bodewig <
bode...@apache.org>:

> On 2018-06-13, Dominik Psenner wrote:
>
> > That is possible. I restricted access to the github token to the log4net
> > build job only. Stefan, would you like to try whether you can gain access
> > to that token? I can guide you to where you can find it off-list.
>
> Sorry, still travelling. Even if I don't manage to see the token, it is
> only going to prove to me that I'm not skilled enough :-)
>

I'm sure that wouldn't be the case. All popular ci systems provide secret
environment variables as a feature. Without that most devops usecases
wouldn't be possible.


>
> Personally I'd want to verify the contents of the archive anyway (as
> part of vetting the relase) and don't see any problem with signing them
> offline on my own machine at that point in time (or anybody else of us
> doing so). To me signing and uploading the ZIPs to dist.a.o doesn't have
> to be automated, YMMV.
>

We can agree to keep a few manual steps as long as these steps are as few
as possible. Signing and uploading to dist.a.o and nuget can be one of them.

If there are no objections I would freeze the codebase in 72h from now by
creating a release branch from whatever commit develop points to on
2018-06-17 at 21:30 CEST (19:30 UTC). I would then like to proceed with the
release and I hope that more people will join in and test the binaries
while we prepare the release. Thinking about what Gary did lately with
log4j auditing, it may be a good idea to start one or more github projects
that implement sample usecases for log4net. Everyone could then use those
projects to do a thorough testing of a release.
-- 
Dominik Psenner

Re: [log4net] crafting the next release

[Dominik Psenner]

That is possible. I restricted access to the github token to the log4net
build job only. Stefan, would you like to try whether you can gain access
to that token? I can guide you to where you can find it off-list.

On Wed, 13 Jun 2018, 17:40 Ralph Goers,  wrote:

> Jenkins does have a way of storing credentials. However, I don’t know if
> there is a way to limit which jobs can use the credentials.
>
> Ralph
>
> > On Jun 13, 2018, at 6:48 AM, Stefan Bodewig  wrote:
> >
> > On 2018-06-13, Dominik Psenner wrote:
> >
> >> As far as I can tell, the secrets stored in jenkins.a.o are
> >> trustworthy. For instance I used a github access token generated from
> >> my github account that grants jenkins access to the log4net-logging
> >> repository on github. I am convinced that nobody else can steal that
> >> token without logging in to jenkins using my credentials. Stefan,
> >> would you please elaborate the reasonings of why you do not trust pgp
> >> signatures issued by builds.a.o?
> >
> > Maybe just because I'm paranoid. How would you store the private part of
> > a PGP key in Jenkins in a way that cannot be compromised by people who
> > log in to Jenkins or a malicious Jenkins addon that gets installed?
> >
> > Stefan
> >
>
>
>

Re: [log4net] crafting the next release

[Dominik Psenner]

My previous mail was strongly biased by what we should do with the old 
key binaries but that is another topic we have to get consensus about.


As far as the gpg signing of the artifacts goes, it will have to stay a 
manual process. Just like updating the site and publishing artifacts is 
also a manual step that needs to be done by the release moderator after 
the poll has completed. I would however prefer an automated process.


As far as I can tell, the secrets stored in jenkins.a.o are trustworthy. 
For instance I used a github access token generated from my github 
account that grants jenkins access to the log4net-logging repository on 
github. I am convinced that nobody else can steal that token without 
logging in to jenkins using my credentials. Stefan, would you please 
elaborate the reasonings of why you do not trust pgp signatures issued 
by builds.a.o?


Binaries shipped via NuGet are not pgp signed and people will have to 
hash check the binaries against the hash of official binaries available 
via apache mirrors in case they want to verify that these binaries are 
genuine.



On 2018-06-13 13:33, Matt Sicker wrote:

Yes, I was talking about GPG, totally forgot about other artifact signing.
Even Java supports that despite barely anyone using it. And I’ve created
dedicated GPG keys in the past for continuous deployment to Maven Central,
but not in a public Jenkins instance.

On Wed, Jun 13, 2018 at 06:58, Stefan Bodewig  wrote:


[Sorry for the top post]

I think Matt and you are talking about different "signing" processes.

.NET assemblies can be signed (strong named) and for some releases now
we've used a key that is checked into git for one distribution archive
(no credential needed, everything is in git) that is labeled as
"newkey". These are the assemblies used inside the nuget package as well
and CI already builds them,

The other zip (oldkey) is signed by a different key that we keep secret
deliberately. A pgp encrypted version of the key is inside the git
repo. So far every release manager had to decrypt that locally and build
the releases locally.

Matt, I think, has been talking about the PGP signature on the resulting
ZIPs. At least I wouldn't trust any key that can be used by Jenkins :-)

Stefan

On 2018-06-12, Dominik Psenner wrote:


That's an interesting question to ask. As I see it, ci should produce

good

and final artifacts. This means that ci should also sign them in the
pipeline. We can inject required keys and credentials with secret

variables

to make it work. These credentials are then only accessible to whoever

has

access to jenkins. I have right now no idea how the binaries are signed
today. There surely are targets to do so but I have not found them, yet.
Stefan, can you point me into the right direction?
Thanks matt for pointing out yet another thing that we are probably

missing

in the ci pipeline.
On Tue, 12 Jun 2018, 18:54 Matt Sicker,  wrote:

Will you be signing and uploading them locally or via Jenkins?
On Tue, Jun 12, 2018 at 10:05, Dominik Psenner 
wrote:

Hi,
our CI is ready to supply us with binaries along with the log4net
website. This will be the first time that binaries from the CI are
shipped as a release. Therefore we seek out for volunteers who evaluate
the CI binaries [1]. Doing so is a great help and allows us to take the
next steps of shipping the next release of log4net.
Best regards,
Dominik
[1]


https://builds.apache.org/job/logging-log4net/job/develop/lastSuccessfulBuild/artifact/



--

Matt Sicker 

--

Matt Sicker 

Re: [log4net] crafting the next release

[Dominik Psenner]

That's an interesting question to ask. As I see it, ci should produce good
and final artifacts. This means that ci should also sign them in the
pipeline. We can inject required keys and credentials with secret variables
to make it work. These credentials are then only accessible to whoever has
access to jenkins. I have right now no idea how the binaries are signed
today. There surely are targets to do so but I have not found them, yet.
Stefan, can you point me into the right direction?

Thanks matt for pointing out yet another thing that we are probably missing
in the ci pipeline.

On Tue, 12 Jun 2018, 18:54 Matt Sicker,  wrote:

> Will you be signing and uploading them locally or via Jenkins?
>
> On Tue, Jun 12, 2018 at 10:05, Dominik Psenner 
> wrote:
>
> > Hi,
> >
> > our CI is ready to supply us with binaries along with the log4net
> > website. This will be the first time that binaries from the CI are
> > shipped as a release. Therefore we seek out for volunteers who evaluate
> > the CI binaries [1]. Doing so is a great help and allows us to take the
> > next steps of shipping the next release of log4net.
> >
> > Best regards,
> > Dominik
> >
> > [1]
> >
> >
> https://builds.apache.org/job/logging-log4net/job/develop/lastSuccessfulBuild/artifact/
> >
> >
> > --
> Matt Sicker 
>

[log4net] crafting the next release

[Dominik Psenner]

Hi,

our CI is ready to supply us with binaries along with the log4net 
website. This will be the first time that binaries from the CI are 
shipped as a release. Therefore we seek out for volunteers who evaluate 
the CI binaries [1]. Doing so is a great help and allows us to take the 
next steps of shipping the next release of log4net.


Best regards,
Dominik

[1] 
https://builds.apache.org/job/logging-log4net/job/develop/lastSuccessfulBuild/artifact/ 

[log4net] ci pipeline

[Dominik Psenner]

Hi,

I've got great news to share! The ci pipeline finally runs again and builds
all currently supported targets. The last push got picked up and both the
develop branch and a few of the pending merge requests were built. See [1]
for more information. This means we could finally craft a release using ci
built binaries.

One inconvenience is still left. The netstandard-1.3 target is built and
the tests are run too, but unfortunately that step fails with the following
message:

 [exec] The active test run was aborted. Reason:
 [exec]
 [exec] Test Run Aborted.


Test diagnostics logs show that the tests are run but the test process gets
stuck after completion. This causes the dotnet test command to abort the
test run and the test results are discarded. I tried to get feedback on the
nunit mailing list but so far there is no conclusive answer to this
problem. It would be great if there was anyone out there who knows what we
could do to improve or even fix this situation. We could move away from
nunit but this appears to me as a major task.

As Stefan Bodewig pointed out this is not necessarily a release blocker
because these tests were not run on the last release either.

Cheers
-- 
Dominik Psenner

Re: [log4net] dotnet test host process crashes or hangs when run by jenkins docker container

[Dominik Psenner]

Hi!

I've got an update on this topic. In the past days I had the chance to work
on the build pipeline and today I have diagnostical test logs at hand.
Unfortunately I've no idea what causes the following output:

```

runtests-netstandard-1.3:

 [exec] Build started, please wait...
 [exec] Build completed.
 [exec]
 [exec] Test run for
/home/jenkins/jenkins-slave/workspace/log4net_feature_cd-pipeline-76KUCPODUF6LCE45226EBUR4GNVLYPMYVC23Z4ITBOMNJT3CA2WA/netstandard/1.3/log4net.tests/bin/Debug/netcoreapp2.0/log4net.tests.dll(.NETCoreApp,Version=v2.0)
 [exec] Microsoft (R) Test Execution Command Line Tool Version 15.7.0
 [exec] Copyright (c) Microsoft Corporation.  All rights reserved.
 [exec]
 [exec] Starting test execution, please wait...
 [exec] Logging Vstest Diagnostics in file:
/home/jenkins/jenkins-slave/workspace/log4net_feature_cd-pipeline-76KUCPODUF6LCE45226EBUR4GNVLYPMYVC23Z4ITBOMNJT3CA2WA/netstandard/1.3/log4net.tests/test.diagnostics.log
 [exec] The active test run was aborted. Reason:
 [exec]
 [exec] Test Run Aborted.
 [exec] 
/home/jenkins/jenkins-slave/workspace/log4net_feature_cd-pipeline-76KUCPODUF6LCE45226EBUR4GNVLYPMYVC23Z4ITBOMNJT3CA2WA/tests/nant.build(869,10):
 [exec] External Program Failed: dotnet (return code was 1)
 [move] 3 files moved.

BUILD SUCCEEDED - 1 non-fatal error(s), 2 warning(s)

```

The following location [1] contains the diagnostical logfiles for the build
that produced the output and I would greatly appreciate any help with
diagnosing what's going wrong here.

Cheers,
Dominik

[1]
https://builds.apache.org/job/logging-log4net/job/feature%252Fcd-pipeline/lastSuccessfulBuild/artifact/package/tests/bin/netstandard/1.3/log4net.tests/

2018-02-09 14:23 GMT+01:00 Dominik Psenner <dpsen...@gmail.com>:

> *bump*
>
> Has anyone out there an idea how we could troubleshoot the issue or any
> ideas what else we could do?
>
>
>
> On 2018-02-03 11:51, Dominik Psenner wrote:
>
>> The first message was rejected by the mailing list, please see the
>> forward.
>> Please cc the dev at logging.apache.org mailing list.
>>
>> -- Forwarded message --
>> From: "Dominik Psenner" <dpsen...@apache.org>
>> Date: 3 Feb 2018 11:47 a.m.
>> Subject: [log4net] dotnet test host process crashes or hangs when run by
>> jenkins docker container
>> To: <nunit-disc...@googlegroups.com>
>> Cc: <dev@logging.apache.org>
>>
>> Hi,
>>
>> I am reaching out to you wearing the hat of the apache log4net community.
>> I'll give you some context first.
>>
>> We are in the process of automating the builds and tests for our various
>> targeted frameworks. We still struggle with gettibg the netstandard-1.3
>> tests to work. Some time ago I already had a conversation with Rob Prouse
>> about this. I was able to find a good combination of arguments to get the
>> test results logged into a trx fike that can be consumed by jenkins. The
>> tests are run on a ubuntu machine that starts up a docker container based
>> on microsoft/dotnet:1.1-sdk.
>>
>> What we observe is that the test suite is run and when a test fails, the
>> tedt process does not terminate and hangs there until jenkins kills the
>> pipeline after the 4 hour timeout. The last lifesign is this message:
>>
>>  [exec] The active test run was aborted. Reason: Unable to
>> communicate with test host process.
>> Sending interrupt signal to process
>> Cancelling nested steps due to timeout
>> After 10s process did not stop
>>
>>
>> Unfortunately we are unable to reproduce the issue when running the test
>> locally and we have yet found no way to find out what actually goes wrong
>> or what we could do to avoid the issue. Would you please help us
>> troubleshoot and find a solution to this situation?
>>
>> The source can be found here: https://github.com/
>> apache/logging-log4net/tree/feature/cd-pipeline
>>
>> The pipeline configuration is in the Jenkinsfile. The test is run via
>> nant.
>> So the build target can be found at the very end of this file:
>> https://github.com/apache/logging-log4net/blob/feature/cd-pipeline/tests/
>> nant.build
>>
>> And last but not least, the full jenkins build console output can be found
>> here: https://builds.apache.org/job/logging-log4net/job/feature%
>> 252Fcd-pipeline/192/console
>>
>> Best regards,
>> Dominik
>>
>> --
>> Dominik Psenner
>>
>>

Re: Async Appenders

[Dominik Psenner]

That's great! I'm looking forward to hearing from you.

2018-05-11 5:10 GMT+02:00 William Davis <william.j.dav...@gmail.com>:

> Well, I cant speak for the entire test suite, but we having been running
> log4net in production on dotnet core since it was released and my ELK stack
> seems to be getting lots of logs :) I'll reach out to Nick at SE and see if
> he can expound upon his previous message.
>
> On Thu, May 10, 2018 at 5:55 PM, Dominik Psenner <dpsen...@gmail.com>
> wrote:
>
> > Interesting discussion in that pull request, yet it's missing links to
> hard
> > facts what these functionalities, new features, smaller install area, no
> > downsides etc actually are. Have you links to that information?
> >
> > I've said numerous times now that we don't even run the test suite
> against
> > netstandard-1.3. It's no point to add netstandard-2.0 if we don't even
> know
> > whether netstandard-1.3 actually works. And there's an issue somewhere -
> > sorry, no link at the moment - that appears to be a regression related to
> > that target.
> >
> > 2018-05-10 23:09 GMT+02:00 William Davis <william.j.dav...@gmail.com>:
> >
> > > Not a bad conversation to have. I would direct you to read this PR from
> > the
> > > SE.Redis library where I argued against netstandard 2.0 inclusion at
> one
> > > point.
> > > https://github.com/StackExchange/StackExchange.Redis/pull/767
> > >
> > > It would probably be worth while to provide explicit support for it.
> > (with
> > > out any additional effort)
> > >
> > > On Thu, May 10, 2018 at 2:42 PM, Dominik Psenner <dpsen...@gmail.com>
> > > wrote:
> > >
> > > > Sure. This will however block by itself and take care of preserving
> > > > compatibility with the ancient frameworks. With this mentioned, today
> > > might
> > > > be a good day to start a poll on what frameworks log4net should
> > continue
> > > to
> > > > support. In the last days I once more spent numerous hours with the
> > build
> > > > infrastructure and am fed up by the insane build process caused by
> the
> > > > numerous supported frameworks. If we focus on netstandard-1.3 as the
> > base
> > > > framework almost every recent framework can reference log4net. There
> > was
> > > > also a proposal to support netstandard-2.0 but thinking about it I
> see
> > no
> > > > reason to add another framework if we do not need any of the apis
> that
> > > the
> > > > framework provides. If we need netstandard-2.0 functionality we might
> > as
> > > > well provide that functionality as a separate nuget library. Yes,
> > > splitting
> > > > up log4net into several smaller assemblies sounds like a plan to me.
> > > >
> > > > 2018-05-10 18:00 GMT+02:00 William Davis <william.j.dav...@gmail.com
> >:
> > > >
> > > > > Perhaps, but looking at that implementation I see that it is
> locking
> > > in a
> > > > > few places on append. Could this be made a little better by using
> > built
> > > > in
> > > > > ConcurrentCollection types like the ConcurrentQueue?
> > > > >
> > > > > On Thu, May 10, 2018 at 1:23 AM, Dominik Psenner <
> dpsen...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > This proposal sounds like the bufferingforwardingappender.
> > > > > >
> > > > > > On Thu, 10 May 2018, 04:48 William Davis, <
> > > william.j.dav...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Agreed, this is what ill be submitting next.
> > > > > > >
> > > > > > > On Wed, May 9, 2018, 9:47 PM Remko Popma <
> remko.po...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > Perhaps a reasonable approach would be to work like log4j‘s
> > > > > > > AsyncAppender:
> > > > > > > >
> > > > > > > > This is a class that implements the appender interface by
> > simply
> > > > > adding
> > > > > > > > log events to a ConcurrentQueue and returning immediately.
> When
> > > > this
> > > > > > > > appender is started it starts a background thread that blocks
> > > until
> > > >

Re: Async Appenders

[Dominik Psenner]

This proposal sounds like the bufferingforwardingappender.

On Thu, 10 May 2018, 04:48 William Davis, <william.j.dav...@gmail.com>
wrote:

> Agreed, this is what ill be submitting next.
>
> On Wed, May 9, 2018, 9:47 PM Remko Popma <remko.po...@gmail.com> wrote:
>
> > Perhaps a reasonable approach would be to work like log4j‘s
> AsyncAppender:
> >
> > This is a class that implements the appender interface by simply adding
> > log events to a ConcurrentQueue and returning immediately. When this
> > appender is started it starts a background thread that blocks until
> events
> > become available in the queue. When the queue contains an event, the
> > background thread pops it off the queue and appends it to one or more
> > underlying appenders.
> >
> > Note that on the producer (application) side, this looks like any other
> > appender. The consumer side (the background thread) is likely where the
> > async/await api would be used.
> >
> > An AsyncAppender must be configured with one or more underlying
> appenders.
> > (In log4j these appenders must precede the AsyncAppender in the
> > configuration so the list of underlying appenders can be immutable).
> >
> > Hope this helps,
> > Remko
> >
> > (Shameless plug) Every java main() method deserves http://picocli.info
> >
> > > On May 10, 2018, at 4:04, Matt Sicker <boa...@gmail.com> wrote:
> > >
> > > One resource I have about fibers is this Java library:
> > > https://github.com/puniverse/quasar
> > >
> > > And the future Java feature: http://openjdk.java.net/projects/loom/
> > >
> > > As for continuations, if you're familiar with functional programming,
> are
> > > essentially deferred functions to be executed along with any curried
> > state.
> > > It essentially allows you to pause a computation, but you can't use
> > things
> > > like locks and notifications since those are implemented via threads,
> and
> > > fibers don't get their own execution context like threads do (hence why
> > > they're much faster where applicable due to less context switching and
> > data
> > > copying needed).
> > >
> > >
> > >> On 9 May 2018 at 13:41, Dominik Psenner <dpsen...@gmail.com> wrote:
> > >>
> > >> Btw, here is an example of async file io, note that this is a wpf
> client
> > >> application that stays responsive even though there is a "blocking"
> > await
> > >> in the button handler:
> > >>
> > >>
> >
> https://docs.microsoft.com/en-us/dotnet/standard/io/asynchronous-file-i-o
> > >>
> > >> and here is an example of async network io which also explains more
> > >> in-depth details of how it works:
> > >>
> > >> https://docs.microsoft.com/en-us/dotnet/csharp/programming-
> > >> guide/concepts/async/
> > >>
> > >> As a starting point it surely takes time to grasp and caused me some
> > >> headache. :-)
> > >>
> > >> 2018-05-09 20:33 GMT+02:00 Dominik Psenner <dpsen...@gmail.com>:
> > >>
> > >>> I don't know about fibers or continuations but am interested. Can you
> > >>> provide me with some link?
> > >>>
> > >>> AFAIK, LMAX disruptor intelligently uses hot spins on the cpu where
> it
> > >>> estimates that hot spinning pays off because an async operation will
> > >> finish
> > >>> soon. When this is not the case after a few hot spins it will yield
> and
> > >>> cause a context switch. When I read this up I quickly came to the
> > >>> conclusion that such a way makes it very hard to implement something
> > >> that's
> > >>> reliably fast and stable at the same time.
> > >>>
> > >>> I can't provide the following with backup information, but as far as
> I
> > >>> understood the async/await approach it works so well because the
> > hardware
> > >>> provides interrupts to the operating system when data arrives which
> in
> > >> turn
> > >>> is published to an application via events. As noticed earlier, libuv
> > is a
> > >>> cross platform library that provides these event api's to an
> > application.
> > >>> In the dotnet world since the invention of Task and async/await a
> libuv
> > >> has
> > >>> mostly become futile. The kestrel w

Re: Async Appenders

[Dominik Psenner]

Btw, here is an example of async file io, note that this is a wpf client
application that stays responsive even though there is a "blocking" await
in the button handler:

https://docs.microsoft.com/en-us/dotnet/standard/io/asynchronous-file-i-o

and here is an example of async network io which also explains more
in-depth details of how it works:

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/

As a starting point it surely takes time to grasp and caused me some
headache. :-)

2018-05-09 20:33 GMT+02:00 Dominik Psenner <dpsen...@gmail.com>:

> I don't know about fibers or continuations but am interested. Can you
> provide me with some link?
>
> AFAIK, LMAX disruptor intelligently uses hot spins on the cpu where it
> estimates that hot spinning pays off because an async operation will finish
> soon. When this is not the case after a few hot spins it will yield and
> cause a context switch. When I read this up I quickly came to the
> conclusion that such a way makes it very hard to implement something that's
> reliably fast and stable at the same time.
>
> I can't provide the following with backup information, but as far as I
> understood the async/await approach it works so well because the hardware
> provides interrupts to the operating system when data arrives which in turn
> is published to an application via events. As noticed earlier, libuv is a
> cross platform library that provides these event api's to an application.
> In the dotnet world since the invention of Task and async/await a libuv has
> mostly become futile. The kestrel web server, as far as I know, uses libuv
> under the hoods and is used by some microsoft devs as playground to
> improve the performance of implementations of the async api's provided by
> netstandard. Future versions of asp.netcore will probably no longer feature
> the kestrel webserver with libuv transports but transports that are based
> upon .netstandard System.Net.Sockets.
>
> 2018-05-09 20:17 GMT+02:00 Matt Sicker <boa...@gmail.com>:
>
>> I'm not too familiar with how it's implemented, but that sounds similar to
>> the problems that LMAX was fixing in lock-free queues. The problem with
>> typical async/await is lock contention which is addressed in a lower level
>> fashion in disruptor queues. I think this would all be far easier with
>> something like fibers or continuations, but I didn't design Java. :)
>>
>> On 9 May 2018 at 13:09, Dominik Psenner <dpsen...@gmail.com> wrote:
>>
>> > Disclaimer: so far I never had to use a library like LMAX disruptor.
>> After
>> > a lot of brain that I spent into the new async/await approach that's
>> > available today I even think that a truely high performance .net
>> > application has no need for such library. The following hopefully
>> explains
>> > the why's.
>> >
>> > To me there are mainly two aspects of asynch operations. One is the
>> asynch
>> > nature of multithreading where computational expensive operations are
>> > offloaded to background threads. The other is async io which allows the
>> cpu
>> > to continue doing other tasks when the, compared to the cpu cycling on
>> its
>> > calculations, vry slow io like networking is involved.
>> >
>> > Asyc/await with tasks provides, from an api point of view, both.
>> > Traditionally an io operation would either block the cpu while waiting
>> for
>> > the io to complete or be buffered/offloaded to a background thread and
>> > finished there. The downside of such an approach is that this involves
>> > cross thread synchronization points. The actual problem we need to
>> solve is
>> > that we do want the cpu to wait for the slow io. This is where the
>> > async/await comes into play. async/await allows the io operation to
>> start
>> > and the cpu to continue its task. When the async io is complete an event
>> > fired by the io will trigger the cpu to continue its work on a
>> > synchronization point that is chosen with an await. While this works
>> best
>> > with io, it also works with cpu intensive tasks that need to be run on
>> > background threads. But using this for computational expensive cpu tasks
>> > only pays off it the costs of synchronization and context switches is
>> > insignificant with respect to the actual task.
>> >
>> > This said, if an appender involves IO, a client application could
>> > ultimately choose to either fire and forget, wait for the io or continue
>> > and synchronize later if we provided an async api. This however
>> requires us
>

Re: Async Appenders

[Dominik Psenner]

I don't know about fibers or continuations but am interested. Can you
provide me with some link?

AFAIK, LMAX disruptor intelligently uses hot spins on the cpu where it
estimates that hot spinning pays off because an async operation will finish
soon. When this is not the case after a few hot spins it will yield and
cause a context switch. When I read this up I quickly came to the
conclusion that such a way makes it very hard to implement something that's
reliably fast and stable at the same time.

I can't provide the following with backup information, but as far as I
understood the async/await approach it works so well because the hardware
provides interrupts to the operating system when data arrives which in turn
is published to an application via events. As noticed earlier, libuv is a
cross platform library that provides these event api's to an application.
In the dotnet world since the invention of Task and async/await a libuv has
mostly become futile. The kestrel web server, as far as I know, uses libuv
under the hoods and is used by some microsoft devs as playground to improve
the performance of implementations of the async api's provided by
netstandard. Future versions of asp.netcore will probably no longer feature
the kestrel webserver with libuv transports but transports that are based
upon .netstandard System.Net.Sockets.

2018-05-09 20:17 GMT+02:00 Matt Sicker <boa...@gmail.com>:

> I'm not too familiar with how it's implemented, but that sounds similar to
> the problems that LMAX was fixing in lock-free queues. The problem with
> typical async/await is lock contention which is addressed in a lower level
> fashion in disruptor queues. I think this would all be far easier with
> something like fibers or continuations, but I didn't design Java. :)
>
> On 9 May 2018 at 13:09, Dominik Psenner <dpsen...@gmail.com> wrote:
>
> > Disclaimer: so far I never had to use a library like LMAX disruptor.
> After
> > a lot of brain that I spent into the new async/await approach that's
> > available today I even think that a truely high performance .net
> > application has no need for such library. The following hopefully
> explains
> > the why's.
> >
> > To me there are mainly two aspects of asynch operations. One is the
> asynch
> > nature of multithreading where computational expensive operations are
> > offloaded to background threads. The other is async io which allows the
> cpu
> > to continue doing other tasks when the, compared to the cpu cycling on
> its
> > calculations, vry slow io like networking is involved.
> >
> > Asyc/await with tasks provides, from an api point of view, both.
> > Traditionally an io operation would either block the cpu while waiting
> for
> > the io to complete or be buffered/offloaded to a background thread and
> > finished there. The downside of such an approach is that this involves
> > cross thread synchronization points. The actual problem we need to solve
> is
> > that we do want the cpu to wait for the slow io. This is where the
> > async/await comes into play. async/await allows the io operation to start
> > and the cpu to continue its task. When the async io is complete an event
> > fired by the io will trigger the cpu to continue its work on a
> > synchronization point that is chosen with an await. While this works best
> > with io, it also works with cpu intensive tasks that need to be run on
> > background threads. But using this for computational expensive cpu tasks
> > only pays off it the costs of synchronization and context switches is
> > insignificant with respect to the actual task.
> >
> > This said, if an appender involves IO, a client application could
> > ultimately choose to either fire and forget, wait for the io or continue
> > and synchronize later if we provided an async api. This however requires
> us
> > to provide both a "normal" api and an async api. But doing so rewards
> with
> > a truely async io.
> >
> > Note that this is something what nginx makes heavy use of. libuv is a
> > library that provides a few aspects of io as an event based api.
> >
> > On Wed, 9 May 2018, 16:56 Matt Sicker, <boa...@gmail.com> wrote:
> >
> > > I'd be interesting in hearing about high performant .NET applications
> > that
> > > would necessitate the creation of libraries like LMAX Disruptor. AFAIK,
> > > that's generally a C++ and Java world.
> > >
> > > On 9 May 2018 at 08:47, Remko Popma <remko.po...@gmail.com> wrote:
> > >
> > > > In the log4j world, async logging means adding the information to be
> > > > logged to some data structure, whereupon the applicat

Re: Async Appenders

[Dominik Psenner]

Disclaimer: so far I never had to use a library like LMAX disruptor. After
a lot of brain that I spent into the new async/await approach that's
available today I even think that a truely high performance .net
application has no need for such library. The following hopefully explains
the why's.

To me there are mainly two aspects of asynch operations. One is the asynch
nature of multithreading where computational expensive operations are
offloaded to background threads. The other is async io which allows the cpu
to continue doing other tasks when the, compared to the cpu cycling on its
calculations, vry slow io like networking is involved.

Asyc/await with tasks provides, from an api point of view, both.
Traditionally an io operation would either block the cpu while waiting for
the io to complete or be buffered/offloaded to a background thread and
finished there. The downside of such an approach is that this involves
cross thread synchronization points. The actual problem we need to solve is
that we do want the cpu to wait for the slow io. This is where the
async/await comes into play. async/await allows the io operation to start
and the cpu to continue its task. When the async io is complete an event
fired by the io will trigger the cpu to continue its work on a
synchronization point that is chosen with an await. While this works best
with io, it also works with cpu intensive tasks that need to be run on
background threads. But using this for computational expensive cpu tasks
only pays off it the costs of synchronization and context switches is
insignificant with respect to the actual task.

This said, if an appender involves IO, a client application could
ultimately choose to either fire and forget, wait for the io or continue
and synchronize later if we provided an async api. This however requires us
to provide both a "normal" api and an async api. But doing so rewards with
a truely async io.

Note that this is something what nginx makes heavy use of. libuv is a
library that provides a few aspects of io as an event based api.

On Wed, 9 May 2018, 16:56 Matt Sicker, <boa...@gmail.com> wrote:

> I'd be interesting in hearing about high performant .NET applications that
> would necessitate the creation of libraries like LMAX Disruptor. AFAIK,
> that's generally a C++ and Java world.
>
> On 9 May 2018 at 08:47, Remko Popma <remko.po...@gmail.com> wrote:
>
> > In the log4j world, async logging means adding the information to be
> > logged to some data structure, whereupon the application thread returns
> > immediately to do other work.
> > In the background, another thread reads the information to be logged from
> > the data structure, potentially transforms it, then renders it to the
> > configured layout format and writes it to the configured appender(s).
> >
> > The data structure may be a standard queue, in which case the
> “information
> > to be logged” is often a LogEvent instance, or it could be a data
> structure
> > that is optimized for non-blocking inter-thread handovers, like the LMAX
> > Disruptor. I don’t know what the equivalent of the latter is in the .NET
> > world.
> >
> > It seems that concurrent queues in .net may use Async/await under the
> > hood. (Based on what I see on SO, like https://stackoverflow.com/
> > questions/7863573/awaitable-task-based-queue)
> >
> > Not sure if lock-free mechanisms like the lmax disruptor exist. Be aware
> > that the background thread needs to employ some waiting strategy until
> work
> > arrives. The simplest thing is to use some block-notify mechanism: the
> > background thread is suspended and woken up by the operating system when
> > notified. I assume this is what async/await uses. To be completely
> > lock-free, an alternative wait strategy is to busy-spin but this means
> > dedicating a core to logging which is a hefty price. In the disruptor
> this
> > is configurable so if log4j users really want to they can have lock-free
> > logging in return for dedicating a cpu core. You may not want or need to
> go
> > that far.
> >
> > Remko
> >
> > (Shameless plug) Every java main() method deserves http://picocli.info
> >
> > > On May 9, 2018, at 22:06, Dominik Psenner <dpsen...@gmail.com> wrote:
> > >
> > > When implementing the async/await paradigm it would have to be provided
> > as a logging event api and continuously invoked with async down to the
> > appender implementations in order for the application code to benefit
> from
> > true async behavior. Or am I wrong here?
> > >
> > >
> > >> On 2018-05-09 13:48, William Davis wrote:
> > >> Jochen, I dont believe that appender has been ported to Log

Re: Async Appenders

[Dominik Psenner]

When implementing the async/await paradigm it would have to be provided 
as a logging event api and continuously invoked with async down to the 
appender implementations in order for the application code to benefit 
from true async behavior. Or am I wrong here?



On 2018-05-09 13:48, William Davis wrote:

Jochen, I dont believe that appender has been ported to Log4Net. Maybe
thats what we should do first? Im sure there are other uses cases out there
though, which is why we've seen several people roll async appenders in the
first place (although it could be a fundamental lack of understanding)

On Wed, May 9, 2018 at 7:00 AM, Jochen Wiedmann 
wrote:


On Mon, May 7, 2018 at 2:15 PM William Davis 
wrote:


I've noticed that there are several Async implementations of standard
appenders out in the wild. Is there a reason none of these have made

there

way into the core product? Is it just b/c no one has taken the time to do

a

pull request, or is there some other reason?

I wonder, why one would create a special async version, when all you need
to do is to put a standard async logger in front of the sync logger [1]?

Jochen

1: https://logging.apache.org/log4j/2.x/manual/async.html#MixedSync-Async

Re: Async Appenders

[Dominik Psenner]

+1 :-)

I only have very limited time frames available to hack on log4net but am
happy to help wherever help is needed.

For instance we have to fix the build pipeline to have something to rely on
and allow contributions to be sanity checked by tests.

On 8 May 2018 5:05 p.m., "Matt Sicker"  wrote:

Please feel free! Our bandwidth for log4net is a bit less since there are
less developers here familiar with C#, but we love contributions. :)


On 7 May 2018 at 17:52, William Davis  wrote:

> I gotcha, if there is interest Id like to get a pr started.
>
> On Mon, May 7, 2018, 1:25 PM Matt Sicker  wrote:
>
> > Log4j and Log4net don't share any code, just similar architectures. As
> for
> > why we haven't merged that into log4net, that may because it either was
> > never noticed or the authors never attempted to donate it upstream in
the
> > first place.
> >
> > On 7 May 2018 at 12:22, William Davis 
> wrote:
> >
> > > Ok then, so are the same Async Appenders available in Log4Net that are
> in
> > > Log4j ?
> > > Here are some one I'm using:
> > > https://github.com/cjbhaines/Log4Net.Async
> > > (my .net standard port: https://github.com/wjdavis5/Log4Net.Async)
> > > Also been looking into an Async Buffering Appender. Just seems we
could
> > get
> > > so much more value out of the core product if these were rolled in.
> (And
> > I
> > > wouldnt have to struggle to get .net core support from ill maintained
> > > repos.)
> > >
> > >
> > >
> > > On Mon, May 7, 2018 at 10:04 AM, Matt Sicker  wrote:
> > >
> > > > Oh, no worries, you're on the correct list!
> > > >
> > > > On 7 May 2018 at 09:02, William Davis 
> > > wrote:
> > > >
> > > > > Sorry I meant to send this to the Log4Net distro
> > > > >
> > > > > On Mon, May 7, 2018 at 9:47 AM, Matt Sicker 
> > wrote:
> > > > >
> > > > > > Like the Kafka appender's async option? Or like the async logger
> > and
> > > > > > appenders?
> > > > > >
> > > > > > On 7 May 2018 at 07:38, Remko Popma 
> wrote:
> > > > > >
> > > > > > > Log4j core provides about 4 flavours of async logging, several
> of
> > > > which
> > > > > > > use non-blocking data structures.
> > > > > > >
> > > > > > > Can you link to the ones you think should be included?
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > Remko
> > > > > > >
> > > > > > > (Shameless plug) Every java main() method deserves
> > > > http://picocli.info
> > > > > > >
> > > > > > > > On May 7, 2018, at 14:15, William Davis <
> > > > william.j.dav...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > I've noticed that there are several Async implementations of
> > > > standard
> > > > > > > > appenders out in the wild. Is there a reason none of these
> have
> > > > made
> > > > > > > there
> > > > > > > > way into the core product? Is it just b/c no one has taken
> the
> > > time
> > > > > to
> > > > > > > do a
> > > > > > > > pull request, or is there some other reason?
> > > > > > > >
> > > > > > > > I've had several projects where we need the non-blocking
> nature
> > > of
> > > > > > these
> > > > > > > > appenders to achieve desired performance.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Matt Sicker 
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker 
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker 
> >
>



-- 
Matt Sicker 

Re: NuGet package ID prefix reservation

[Dominik Psenner]

Thanks for sharing this idea! I'm a great fan of this. Please do not
misunderstand my late response, lately spare time has become really rare,
sorry. Further I hope that in the near future, we may decide to split up
log4net into multiple packages. This trend can be observed about
everywhere, also log4j2, which is where log4net originally came from. To
make this plan more concrete, let me note that I envision something like:

log4net
log4net.Appenders.File
log4net.Appenders.Console
log4net.Appenders.AdoNet
log4net.Appenders.MQTT
[...]

This allows to keep only very few dependencies of the log4net core library,
allowing to become the core library as portable and backwards compatible as
possible. Such a structure further indicates a usecase for multiple places
for an .Extensions prefix open to third party contributors:

log4net.Extensions (this could be a place for generic interfaces to
frameworks like asp.net core, more log event filters, ..)
log4net.Appenders.Extensions (this could be a place for more appenders,
i.e. the previously mentioned MQTT, ..)

Is this something that the community would like to see happen?

I'm however unsure where there would arise trademark issues. Package names
are more like namespaces. So long the extensions do not claim to be part of
the ASF, it should be fine. Even on the contrary. Clearly defined rules and
conventions create room for transparency on what comes from where.

Please note further that if we decide to reserve all prefixes, we will need
to find a solution for all the existing packages that match the pattern
log4net* and this involves a bit of communication with the package
maintainers. For instance, all existing extensions to log4net would have to
be renamed. A hypothetical log4net.foobar extension would have to be
renamed to log4net.Extensions.foobar or log4net.Appenders.foobar if the
extension was only about an appender that supports foobar. This could also
be a great opportunity to attract the developers of the extensions to
become more involved with the community behind log4net here at apache. I
feel that this is something that the .net part of the apache logging family
really needs.

On 29 Apr 2018 8:32 p.m., "Matt Sicker"  wrote:

It certainly sounds like a good idea. As for sub prefixes, that's an
interesting question because there would be Apache trademark issues there
potentially, though I'm not entirely sure about that and would need to
investigate further.


On 28 April 2018 at 00:27, Sean Rose  wrote:

> Now that NuGet has package ID prefix reservation (
> https://docs.microsoft.com/en-us/nuget/reference/id-prefix-reservation)
> are there plans to reserve the log4net.* prefix?
>
> If so, will a particular sub prefix be left available for community
> created packages?
>
> For example:
> -  log4net.Community.*  (like AutoFixture, https://github.com/
> AutoFixture/AutoFixture/issues/863)
> -  log4net.Contrib.*  (like SpecFlow, http://specflow.org/2017/
> nuget-packages-reserved-id-naming-conventions/)
> -  log4net.Ext.*  (like some existing packages, https://www.nuget.org/
> packages?q=log4net.Ext)
> -  log4net.Extensions.*  (like some existing packages,
> https://www.nuget.org/packages?q=log4net.Extensions)
>
> Thanks,
> Sean Rose




-- 
Matt Sicker 

Re: [VOTE] Migrate git repositories to gitbox

[Dominik Psenner]

+1

Also for the log4net repository.

On Sat, 28 Apr 2018, 23:59 Remko Popma,  wrote:

> +1
>
> On Sat, Apr 28, 2018 at 11:48 PM, Gary Gregory 
> wrote:
>
> > +1
> >
> > Gary
> >
> > On Sat, Apr 28, 2018, 17:12 Matt Sicker  wrote:
> >
> > > This is a vote to migrate from the existing git-wip-us infrastructure
> to
> > > the currently supported gitbox infrastructure that Infra advocates for
> > > using nowadays. Using gitbox will allow our projects to integrate
> better
> > > with GitHub including the ability to merge PRs directly from the site
> and
> > > the ability to push commits to GitHub and have them be automatically
> > > mirrored back to Apache. Not only that, but new Apache projects cannot
> > use
> > > the old git-wip-us infrastructure anymore, so it makes sense to migrate
> > to
> > > the best supported option going forward.
> > >
> > > The migration process will entail the following:
> > >
> > > * Marking existing git repo as read-only
> > > * Moving repo to gitbox
> > > * Update website and pom.xml with new SCM URLs
> > > * Update local git clones with the new remote URL(s)
> > >
> > > Note that this vote only applies to the source code. I'm not
> considering
> > > using GitHub Issues instead of Jira, for example. Note also that this
> > vote
> > > does not apply to the use of subversion for publishing the site
> > (svnpubsub)
> > > nor the use of it for publishing releases (only available via svn),
> > though
> > > moving the sites from svnpubsub to gitpubsub (i.e., storing the
> generated
> > > site in a branch called "asf-site", similar to the "gh-pages" branch
> > > feature on GitHub) would be a related topic to cover separately.
> > >
> > > Please vote +1, +0, -0, or -1.
> > >
> > > --
> > > Matt Sicker 
> > >
> >
>

[log4net] dotnet test host process crashes or hangs when run by jenkins docker container

[Dominik Psenner]

Hi,

I am reaching out to you wearing the hat of the apache log4net community.
I'll give you some context first.

We are in the process of automating the builds and tests for our various
targeted frameworks. We still struggle with gettibg the netstandard-1.3
tests to work. Some time ago I already had a conversation with Rob Prouse
about this. I was able to find a good combination of arguments to get the
test results logged into a trx fike that can be consumed by jenkins. The
tests are run on a ubuntu machine that starts up a docker container based
on microsoft/dotnet:1.1-sdk.

What we observe is that the test suite is run and when a test fails, the
tedt process does not terminate and hangs there until jenkins kills the
pipeline after the 4 hour timeout. The last lifesign is this message:

[exec] The active test run was aborted. Reason: Unable to
communicate with test host process.
Sending interrupt signal to process
Cancelling nested steps due to timeout
After 10s process did not stop


Unfortunately we are unable to reproduce the issue when running the test
locally and we have yet found no way to find out what actually goes wrong
or what we could do to avoid the issue. Would you please help us
troubleshoot and find a solution to this situation?

The source can be found here:
https://github.com/apache/logging-log4net/tree/feature/cd-pipeline

The pipeline configuration is in the Jenkinsfile. The test is run via nant.
So the build target can be found at the very end of this file:
https://github.com/apache/logging-log4net/blob/feature/cd-pipeline/tests/nant.build

And last but not least, the full jenkins build console output can be found
here:
https://builds.apache.org/job/logging-log4net/job/feature%252Fcd-pipeline/192/console

Best regards,
Dominik

Re: [log4net] release 2.0.9

[Dominik Psenner]

On 28 Jan 2018 11:43 a.m., "Stefan Bodewig" <bode...@apache.org> wrote:

On 2018-01-21, Dominik Psenner wrote:

> On 21 Jan 2018 11:28 a.m., "Stefan Bodewig" <bode...@apache.org> wrote:

>> Maybe, yes. See the other thread for my investigation so far. The
>> github issue I've linked and the source code for the Unix
>> implementation of FileStream state that FileShare.None is the only
>> thing that works on Unix at all, all other options get translated to
>> "share freely" internally. Unfortunately I haven't seen this
>> documented for .NET Standard in any place so far.

> So we could do FileShare.None when we detect that we run on
> linux. What do you think?

If that works as expected then you'd be unable to "tail" a logfile. This
is most likely not what people want. TBH I don't know whether there is a
way to make locking work "properly" for .NET Core on Linux at all.


I would be surprised if file locking was forgot in the netstandard-1.3 api.
I stumbled upon this https://github.com/dotnet/corefx/issues/5964 but have
no possibility to do cross platform testing in this moment. This is on my
task list now.


For the 2.0.9 release I am inclined to live with the problem and cut the
release the same way 2.0.8 has been created. The situation is not worse
than it has been before and we do have some important fixes in the
develop branch.


There are indeed important things queued that need to get out. So far the
issue is not a blocker but to me it is something that needs to be fixed or
left out from the api. I would like to avoid in the future situations where
the api and documentation indicate a usecase that is broken for good. But
maybe the codebase grew for too long and needs a good bunch of refactor
with all the different targets. #if are no longer an option to me. Should
we duplicate the codebase for the different targets that differ the most?
Has the time come for a log4net.standard and log4net.mono?

Re: [log4net] exclusive lock on .NET Core 1.x and Linux

[Dominik Psenner]

On 28 Jan 2018 11:45 a.m., "Stefan Bodewig" <bode...@apache.org> wrote:

On 2018-01-21, Dominik Psenner wrote:

> Sometimes it is possible to configure the test runner so that it runs in
> process instead of spawning a new process. Would you like to investigate
on
> this?

I don't see any such option. We could re-enable more detailed logging
and try to figure out which of the tests crashes the containers in
Jenkins. So far I have been completely unable to reproduce the Jenkins
issue on Docker containers I've created locally.

Stefan


Same here. I'll escalate and forward a question to nunit-discuss asap.

Re: [log4net] release 2.0.9

[Dominik Psenner]

On 21 Jan 2018 11:28 a.m., "Stefan Bodewig" <bode...@apache.org> wrote:

On 2018-01-20, Dominik Psenner wrote:

> I have looked at the assert that fails. For one there's a comment on it
> saying that "on linux locking seems to not behave as one would expect".
> Second the assert is wrapped in an #if !MONO || MONO_3_5 || MONO_4_0. Note
> that this all comes from my memory and there might be an error here or
> there. It however indicates a long known but badly documented issue
related
> to how log4net behaves on linux.

Maybe, yes. See the other thread for my investigation so far. The github
issue I've linked and the source code for the Unix implementation of
FileStream state that FileShare.None is the only thing that works on
Unix at all, all other options get translated to "share freely"
internally. Unfortunately I haven't seen this documented for .NET
Standard in any place so far.


So we could do FileShare.None when we detect that we run on linux. What do
you think?


> I really have a bad feeling to release something like that now that
> netstandard has become a supported framework and therefore log4net will
> most likely run more on linux machines.

I understand this, but as far as locking of files goes there isn't
anything we can do.

> How about if we configure ci to run our tests for both netstandard and
mono
> on linux and windows?

I'm not sure we've got Windows slaves running either Mono or .NET
Standard (and if so, probably not 1.x). Maybe the Windows slaves can run
Docker themselves, then we might be able to use the "dotnet" Windows
server images available from dockerhub.


We can start small and work us through the ranks one by one.

Re: [log4net] exclusive lock on .NET Core 1.x and Linux

[Dominik Psenner]

Sometimes it is possible to configure the test runner so that it runs in
process instead of spawning a new process. Would you like to investigate on
this? I had contact to Rob Prouse of the nunit developers. It might be a
good idea to crosspost to nunit-discuss.

On 21 Jan 2018 11:21 a.m., "Stefan Bodewig"  wrote:

> On 2018-01-20, Stefan Bodewig wrote:
>
> > I have disabled the test conditionallly on Linux and the Jenkins build
> > now finishes the tests on Linux.
>
> But not reliably, there seems to be another test that crashes the test
> runner from time to time.
>
> https://developercommunity.visualstudio.com/content/
> problem/56318/the-active-test-run-was-aborted-reason-unable-to-c.html
>
> indicates there is no way for us to avoid the crashed test runner or to
> get decent information about which test is responsible for the crash (we
> may be able to see somthing if we increase verbosity again, oh my).
>
> There are reports of this problem being fixed in .NET Core 2.x but that
> won't help us.
>
> Unfortunately it doesn't seem to happen on the local docker image I've
> created for my own tests. This really is frustrating.
>
> Stefan
>

Re: [log4net] release 2.0.9

[Dominik Psenner]

On 20 Jan 2018 9:29 p.m., "Stefan Bodewig" <bode...@apache.org> wrote:

On 2018-01-20, Dominik Psenner wrote:

> On 20 Jan 2018 7:27 p.m., "Stefan Bodewig" <bode...@apache.org> wrote:

>> Building .NET 2.0 (not standard or core, good old .NET framework) was
>> broken.

> I see. I wonder why the build worked on ci.

because there is no build step for compile-net-2.0 :-)

I'll try to add one.

> Btw, have you noticed that the head of develop failed in ci? I'm
> currently on my phone only and therefore cant figure out why.

The build ends with

,
| Could not update commit status, please check if your scan credentials
belong to a member of the organization or a collaborator of the repository
and repo:status scope is selected


I believe this is a warning message of the Jenkins github plugin and it can
be ignored for now. It means that jenkins github plugin was unable to store
the build outcome to the github page. I believe there is already an infra
ticket for this. It would still be good to double check.

|
| ERROR: script returned exit code 1
| Finished: FAILURE
`


That's the generic error message that always shows up when the build fails.


I have no idea what this means.

>> Not sure what "all targetted" frameworks means. The quote above is from
>> running the .NET Standard tests using .NET Core SDK 1.1.7 on Win7. I
>> tested this by changing into the log4net.tests dir and running "dotnet
>> test".

> That's roughly what the runtests-netstandard-1.3 target does, too.

Then maybe my fear that the test pass on Windows but fail on Linux is
warranted. In any case it doesn't necessarily need to stop us from
building the 2.0.9 release as the test used to pass on my Windows bix
and they still do.


I have looked at the assert that fails. For one there's a comment on it
saying that "on linux locking seems to not behave as one would expect".
Second the assert is wrapped in an #if !MONO || MONO_3_5 || MONO_4_0. Note
that this all comes from my memory and there might be an error here or
there. It however indicates a long known but badly documented issue related
to how log4net behaves on linux.

I really have a bad feeling to release something like that now that
netstandard has become a supported framework and therefore log4net will
most likely run more on linux machines.

How about if we configure ci to run our tests for both netstandard and mono
on linux and windows?