Re: Log4Net Web site

Ralph, I've pushed to that PR with updated release notes based on what I could grok from prior commits, basically: - update to support netstandard2.0 & project restructuring - address LOG4NET-559 (adds null checks to prevent some reported issues with custom appenders) - address LOG4NET-563, whic

Re: Log4Net Web site

Thanks Ralph I've figured out part of the problem: I updated the .gitignore as part of the build / maintenance update & the default gitignore rule for vs projects excludes folders called 'release', which left out release docs from the site. I've copied in from the develop branch and updated the

Re: Log4Net Web site

If you have moved them back I can take a look this evening when I have some time. Ralph > On Aug 26, 2020, at 10:22 AM, Davyd McColl wrote: > > I've raised a PR in the interim: all I've done is move the site assets back > where they belong (I inadvertently moved them out when refactoring for

Re: Log4Net Web site

Normally, src/changes/changes.xml should have the list of changes for each release. The Maven site plugin runs the changes plugin - https://maven.apache.org/plugins/maven-changes-plugin/ - would normally process that. But it appears Log4net isn’t using that as it doesn’t contain any useful info

Re: Log4Net Web site

I've raised a PR in the interim: all I've done is move the site assets back where they belong (I inadvertently moved them out when refactoring for build!). I have a lot to learn to understand what maven is doing, so right now, I'm not very clued up as to why a lot of links in the generated outpu

Re: Log4Net Web site

update: I have the site building with maven, but a _lot_ of the links are broken (target html file is missing), so I'm going to have to hunt those down. I'm also not sure how a changelog ends up in the site, since the changes folder doesn't seem to e referenced (that I could find via a quick tex

Re: Log4Net Web site

Thanks Ralph, will give that all a go tonight! -d On August 26, 2020 17:24:40 Ralph Goers wrote: Building the site should just require running mvn site in the home directory of the log4net project. To get it somewhere you can view you can then do mvn site:stage -DstagingDirectory=$HOME/

Re: Log4Net Web site

Building the site should just require running mvn site in the home directory of the log4net project. To get it somewhere you can view you can then do mvn site:stage -DstagingDirectory=$HOME/log4net Once you have a site you are happy with the instructions on the link Matt gave you will tell yo

Re: Log4Net Web site

Actually, I can handle the main web site. I just need the Log4Net site updated. From what I can tell it uses the Maven site plugin. That requires files in the src/site and src/changes directory that were present in the 2.0.8 release but seem to have been moved to src/Log4Net/site where they will

Re: log4net.dll - does 2.0.9 fix CVE-2018-1285

Oh right, I think I mixed that up with something else. That CVE only affects downstream users who accept arbitrary user input for their log4net config file (which seems like a security nightmare no matter what). On Wed, 26 Aug 2020 at 10:12, Davyd McColl wrote: > > Hi > > Matt, I don't think that

Re: Log4Net Web site

Thanks Matt, I'll give that a go tonight (: -d On 2020/08/26 17:07:00, Matt Sicker wrote: I think these instructions are still up to date: https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site On Wed, 26 Aug 2020 at 10:02, Davyd McColl wrote: > > Ralph, I'm

Re: log4net.dll - does 2.0.9 fix CVE-2018-1285

Hi Matt, I don't think that CVE is fixed in 2.0.9. I originally tracked down a commit in the develop branch which had the change in it, and I'm quite sure that commit was never brought into the 2.0.9 release. The changes I made on that branch were all around build, simply to try to get the proj

Re: Log4Net Web site

I think these instructions are still up to date: https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Site On Wed, 26 Aug 2020 at 10:02, Davyd McColl wrote: > > Ralph, I'm happy to -- but I have no idea how to. Even a pointer at a > document I can read on how wo

Re: log4net.dll - does 2.0.9 fix CVE-2018-1285

Yes, that release fixes the CVE. I still need to submit an update to Mitre about that. On Wed, 26 Aug 2020 at 09:52, #CircusLogic wrote: > > Team - > > The latest that I read about log4net.dll is that it is dormant as of 2017 and > the latest version was 2.0.8. > > But then I read that there is

Re: Log4Net Web site

Ralph, I'm happy to -- but I have no idea how to. Even a pointer at a document I can read on how would be greatly appreciated (ie how to get content to the website) -d On 2020/08/26 16:54:46, Ralph Goers wrote: Davyd, Can you update the web site? It still says Log4Net is dormant and does not

Re: Time-sensitive tests

You probably need to look at the logic of the tests. Some of these expect a certain number of files or records in each file and that may not always be the case in the first or last interval. Ralph > On Aug 26, 2020, at 12:47 AM, Volkan Yazıcı wrote: > > I have been trying to fix certain (rand

Re: Log4Net Web site

Davyd, Can you update the web site? It still says Log4Net is dormant and does not include any info about 2.0.0. The PMC is continuing to get queries since there is no public info about the release. Ralph > On Aug 24, 2020, at 3:31 PM, Ralph Goers wrote: > > All the NuGet emails are forwarde

log4net.dll - does 2.0.9 fix CVE-2018-1285

Team - The latest that I read about log4net.dll is that it is dormant as of 2017 and the latest version was 2.0.8. But then I read that there is now a version 2.0.9. What is in 2.0.9? Is a fix for CVE-2018-1285 included? Thanks, CL

Re: [apache/logging-log4j2] Bump jetty-util from 8.2.0.v20160908 to 9.4.31.v20200723 (#393)

Done. On Wed, Aug 26, 2020 at 3:42 PM Gary Gregory wrote: > Hi Volkan, > > May you please document this version change in changes.xml? > > Gary > > On Wed, Aug 26, 2020 at 4:59 AM Volkan Yazıcı > wrote: > > > Merged #393 into > > master. > > >

Re: [apache/logging-log4j2] Bump jetty-util from 8.2.0.v20160908 to 9.4.31.v20200723 (#393)

I like to keep changes.xml in sync with the code/POM otherwise it's an extra step/hassle to review git history before you cut a RC assuming you even remember to do it ;-) but that's just me and I usually don't cut RCs for Log4j. Gary On Wed, Aug 26, 2020, 10:06 Volkan Yazıcı wrote: > Hey Gary,

Re: [apache/logging-log4j2] Bump jetty-util from 8.2.0.v20160908 to 9.4.31.v20200723 (#393)

I've asked this before, and Gary had mentioned that he liked showing that we had tested Log4j with each of those dependency updates. That way, users aren't forced to upgrade all their dependencies when unnecessary. On Wed, 26 Aug 2020 at 09:06, Volkan Yazıcı wrote: > > Hey Gary, > > Thanks for sp

Re: [apache/logging-log4j2] Bump jetty-util from 8.2.0.v20160908 to 9.4.31.v20200723 (#393)

Hey Gary, Thanks for sparing time to check the changes. I was sort of sitting on the fence for what to do about them. I have also merged a couple of other dependabot PRs. Jackson, Apache Felix, JCTools, etc. libraries are upgraded as well. Though looking at changes.xml, for instance, I see two "Up

Re: Maven verify success vs test report failures

Personally, I’d love if we can simplify our build like that. I’m not sure if I have the expertise around it though. On Wed, Aug 26, 2020 at 08:47 Volkan Yazıcı wrote: > IMHO, we should stop adding any new features until we get "verify" working. > > It is really confusing to commit any change in

Re: Maven verify success vs test report failures

IMHO, we should stop adding any new features until we get "verify" working. It is really confusing to commit any change in the presence of test failures. Thinking it the other way around, if we are okay with making releases given these failed tests, let's delete those tests. For the records, packa

Re: [apache/logging-log4j2] Bump jetty-util from 8.2.0.v20160908 to 9.4.31.v20200723 (#393)

Hi Volkan, May you please document this version change in changes.xml? Gary On Wed, Aug 26, 2020 at 4:59 AM Volkan Yazıcı wrote: > Merged #393 into > master. > > — > You are receiving this because you are subscribed to this thread. > Reply to

Re: [CI][UNSTABLE] Logging/log4j/master#141 has test failures

I wonder what causes these OSGi failures when there’s some other failed test earlier in the build. I thought I fixed this by disabling test failures as an exit error. On Wed, Aug 26, 2020 at 08:31 Mr. Jenkins wrote: > *BUILD UNSTABLE* > > > Build URL > > https://ci-builds.apache.org/job/Logging/

Re: Time-sensitive tests

I always prefer to refactor sleep calls to use count down latches or other concurrency mechanisms due to timing variability like this. Do note that the Clock instance is configurable, so perhaps a test version can be used for that test to artificially advance time step by step? On Wed, Aug 26, 202

Re: Maven verify success vs test report failures

I’ve never been able to get the verify task to work properly. I always need to use install instead. Some modules referring to other modules seems to be confusing Maven. On Wed, Aug 26, 2020 at 07:16 Volkan Yazıcı wrote: > Nevermind, fooled by the -Dmaven.test.failure.ignore=true in the Maven > >

Re: Maven verify success vs test report failures

Nevermind, fooled by the -Dmaven.test.failure.ignore=true in the Maven options. Nevertheless, now we have plenty of tests that are failing. On Wed, Aug 26, 2020 at 1:19 PM Volkan Yazıcı wrote: > Hello, > > How one shall interpret "./mvnw verify" success where there are failures > in the test (su

Maven verify success vs test report failures

Hello, How one shall interpret "./mvnw verify" success where there are failures in the test (surefire/failsafe) reports? Should this be marked as a successful build or not? If not, why did "verify" succeed? Kind regards.

Time-sensitive tests

I have been trying to fix certain (randomly?) failing tests on both master and release-2.x; RollingDirectSizeTimeNewDirectoryTest, RollingDirectTimeNewDirectoryTest, etc. to name a few. I suspect the hardwiring to the system clock causes this strange behaviour. Consider the following RollingDirect