Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Injection of zip-compressor for fileTarget #1423

Merged
merged 13 commits into from May 11, 2016

Conversation

AndreGleichner
Copy link
Contributor

See also Issue #1420.
I need to get archive files zipped on .Net4.0 and thus have added a IFileCompressor interface to LogManager, so that NLog users may call NLog.LogManager.SetFileCompressor() to inject there own preferred file compressor like DotNetZip.

@304NotModified
Copy link
Member

Sounds good! Will check this in depth this week

@304NotModified
Copy link
Member

Please add the file headers to the new files so appveyor won't complain

/// <summary>
/// Uses .Net4.5 ZipArchive
/// </summary>
public class DefaultFileCompressor : IFileCompressor
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • good approach
  • I think is better to only include this class in .Net 45. The bool return is then not needed.
  • Please use the <see tag for ZipArchive
  • change it to internal? (easier to maintain)

@304NotModified
Copy link
Member

reviewed already :)

It's in a good direction, and the following changes makes in perfect IMO:

  • The IFileCompressor is always used (all platforms)
  • The Compressor property is of the FileTarget (see code notes) (instead of LogManager)
  • The Compressor property is null for non-.Net45 platforms.
  • Some small changes, see code notes.

@304NotModified 304NotModified changed the title Allow zip file archives for platforms other than .Net4.5 Injection of zip-compressor for fileTarget May 2, 2016
///
/// </summary>
/// <returns></returns>
public static IFileCompressor GetFileCompressor()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to property instead of 2 methods

…ressor to ZipArchiveFileCompressor to better fit in FileTarget which now has a static property DefaultCompressor as well as instance property Compressor. ZipArchiveFileCompressor now only is included by the netfx45 project.
@AndreGleichner
Copy link
Contributor Author

Great to see you already had a chance to check my proposed code. Initially my intention was that IFileCompressor could be used FileTarget independently. After moving all stuff to FileTarget according to your comments, it now seems to be a pretty straightforward to use interface. To be honest i til now only hacked this stuff together w/o any actual test and now have my doubts that i actually can set that FileTarget.DefaultCompressor static property early enough, before NLog actually creates the FileTarget instances. So i guess DefaultCompressor setter would need looping over all FileTarget instances.

@304NotModified
Copy link
Member

have my doubts that i actually can set that FileTarget.DefaultCompressor static property early enough, before NLog actually creates the FileTarget instances.

It's only important to set it before writing any logevent?

@AndreGleichner
Copy link
Contributor Author

Ok, i guess i just have to set DefaultCompressor before doing any actual logging...i'm a bit unsure how the NLog bootstrap is done.
Could you point me to the right direction of how to fix that AppVeyor thing?

@304NotModified
Copy link
Member

304NotModified commented May 2, 2016

Could you point me to the right direction of how to fix that AppVeyor thing?

Sure, see line 164, 171 etc: https://ci.appveyor.com/project/nlog/nlog/build/4.0.2397. Let me know if it's unclear (and ignore the typo ;))

…ng ZipArchiveFileCompressor.cs in all project, thus again added NET4_5 checks.
/// Per instance file compressor to be used to compress log files during archiving.
/// Defaults to <see cref="DefaultCompressor"/>.
/// </summary>
public IFileCompressor Compressor { get; set; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

proposal: rename to FileCompressor

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would have been my personal preference, but you proposed "Compressor" as the property name above ;)

@304NotModified
Copy link
Member

\0/ it builds.

Some last things about naming and I was a bit confused with two properties, see notes.

@AndreGleichner
Copy link
Contributor Author

I'll remove the per FileTarget Instance Compressor property. Just leaving the static property which I'll rename to FileCompressor. And I'll rename IFileCompressor.Compress() to IFileCompressor.CompressFile().

… the static property which was renamed to FileCompressor. Renamed IFileCompressor.Compress() to IFileCompressor.CompressFile().
@304NotModified
Copy link
Member

Cool! Think we needs some unit tests and then we are ready to go

@AndreGleichner
Copy link
Contributor Author

I'll see if I can invent some unit tests soon.
It just came to my mind to also support non-zip archive formats like 7z...how about extending IFileCompressor by an ArchiveExtension readonly property to return e.g. ".zip", ".7z", etc?
There're just a few places where zip is hardcoded.

@304NotModified
Copy link
Member

Good idea about supporting .7z etc. But I think already fits in the current interface? AFAIK the .zip is only used as fallback, so a user could inject how FileCompressor and configure something like "archive.7z"

@AndreGleichner
Copy link
Contributor Author

Right, in FileTarget its just a fallback. Its actually just the unit tests hardcoding .zip or .txt as archive extension. But that can stay as is...so you're right no need to have such ArchiveExtension property.

@PeterHric
Copy link

PeterHric commented May 9, 2016

Hi all,
I appreciate this effort. I'd ike to ask if and where is the new .dll available with this patch.
If there was a simple example how to inject FileCompressor and what Interface it must comply to, that would be even fantastisk !
Thank you again for support...

@304NotModified
Copy link
Member

We needs some unit tests, and then it's ready for merge. After merge I expect the release within a few days.

I you could help us with unit tests, then I can merge (and release) it earlier.

@PeterHric
Copy link

OK great, How do I help you ? :)

@304NotModified
Copy link
Member

  1. checkout this PR locally
  2. create a new branch locally from 1.
  3. add unit tests
  4. Create PR to "AndreGleichner:master"

@AndreGleichner
Copy link
Contributor Author

I'd do such UnitTests...just a bit bussy...my main problem just doing a simple UnitTest, ist that I wasn't easily able figuring out whether xUnit is running tests in parallel. If it would I can't just set FileTarget.FileCompressor to another IFileCompressor implementation based on e.g. DotNetZip, because that may crash the other tests also doing file with zip archiving.
That was one of the reasons why my original approach had a per instance compressor property.

@304NotModified
Copy link
Member

my main problem just doing a simple UnitTest, ist that I wasn't easily able figuring out whether xUnit is running tests in parallel.

I can answer that :) We are not running tests in parallel, so you can set the static and revert with a finally block. We prefer stable tests above test run time, so we will never turn on parallel testing (and we disable it in xUnit2)

I'd do such UnitTests...just a bit bussy

Thanks!

@304NotModified 304NotModified added this to the 4.3.4 milestone May 10, 2016
@codecov-io
Copy link

Current coverage is 75.41%

Merging #1423 into master will decrease coverage by -4.40%

  1. 2 files in src/NLog/Config were modified. more
    • Misses +5
    • Partials +31
    • Hits -36
  2. 2 files in src/NLog were modified. more
    • Misses +12
    • Partials +45
    • Hits -57
  3. 5 files (not in diff) in ...Log/Targets/Wrappers were modified. more
    • Misses +2
    • Partials +8
    • Hits -10
  4. 20 files (not in diff) in src/NLog/Targets were modified. more
    • Misses +43
    • Partials +81
    • Hits -124
  5. 4 files (not in diff) in ...g/LogReceiverService were modified. more
    • Misses +4
    • Partials +5
    • Hits -9
  6. 5 files (not in diff) in src/NLog/Layouts were modified. more
    • Misses +6
    • Partials +13
    • Hits -19
  7. 8 files (not in diff) in ...utRenderers/Wrappers were modified. more
    • Misses +1
    • Partials +11
    • Hits -12
  8. 26 files (not in diff) in ...NLog/LayoutRenderers were modified. more
    • Misses +50
    • Partials +45
    • Hits -95
  9. 5 files (not in diff) in ...ernal/NetworkSenders were modified. more
    • Misses +6
    • Partials +16
    • Hits -22
  10. 5 files (not in diff) in ...ternal/FileAppenders were modified. more
    • Misses +9
    • Partials +19
    • Hits -28
@@             master      #1423   diff @@
==========================================
  Files           267        269     +2   
  Lines         15990      16066    +76   
  Methods           0          0          
  Messages          0          0          
  Branches       1724       1738    +14   
==========================================
- Hits          12762      12116   -646   
- Misses         3228       3528   +300   
- Partials          0        422   +422   

Sunburst

Powered by Codecov. Last updated by e052b10...a7178a6

@304NotModified
Copy link
Member

304NotModified commented May 10, 2016

Codecov is lost again...

@304NotModified
Copy link
Member

@AndreGleichner is dotnetzip a good library? Then maybe we can release it as separate package. We can then remove it from here and replace it with a mock.

@AndreGleichner
Copy link
Contributor Author

IMO DotNetZip is one of the best pure managed zip libs. The only comparable lib is SharpZipLib. But the latter is GPL thus at work we've used DotNetZip since couple years w/o issues and its licence fits our needs.
Concerning codecov...I'll try to figure out how to increase it....

@AndreGleichner
Copy link
Contributor Author

DotNetZip is only refed by the unit tests...didn't know adding new dependencies there could harm.
To perfom the actual unit test of changed code, it would be enough to inject the ZipArchiveFileCompressor as custom FileCompressor, the mechanics would be the same as with using a real custom implementation.

@304NotModified
Copy link
Member

The external lib is no problem in the unit tests :)

But I think it's nice to release the implementation as separate package and then we have twice the same code and tests ;)

Codecov is buggy. The -4% is wrong. More unit tests are nice, but right now it's unclear to me what isn't covered.

@AndreGleichner
Copy link
Contributor Author

Anything else i could do to get this pr merged?

@304NotModified
Copy link
Member

Forced a rebuild. I added an unstable test a few days ago. Not sure what's wrong.

@304NotModified 304NotModified merged commit 4605707 into NLog:master May 11, 2016
@304NotModified
Copy link
Member

merged :)

@AndreGleichner
Copy link
Contributor Author

Yeah :)

@304NotModified
Copy link
Member

304NotModified commented May 11, 2016

@AndreGleichner

PS what is the difference between DotNetZip and DotNetZip.Reduced?

@AndreGleichner
Copy link
Contributor Author

Reduced just means it is w/o self extracting archive support.
Am 11.05.2016 7:46 nachm. schrieb "Julian Verdurmen" <
notifications@github.com>:

@AndreGleichner https://github.com/AndreGleichner

PS hat the difference between DotNetZip and DotNetZip.Reduced


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1423 (comment)

@304NotModified
Copy link
Member

This has been released with NLog 4.3.4 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants