search

pact-foundation / pact-net

.NET version of Pact. Enables consumer driven contract testing, providing a mock service and DSL for the consumer project, and interaction playback and verification for the service provider project.
https://pact.io
MIT License
847 stars 232 forks source link

Can PactConfig.LoggerName be made public? #48

Closed davidmcgregor closed 9 years ago

davidmcgregor commented 9 years ago

When using MockProviderNancyBootstrapper it needs the PactConfig.LoggerName to be set and it can't be set when creating PactConfig in an external assembly because it's currently set to be internal.

neilcampbell commented 9 years ago

Thanks @davidmcgregor, nice find! I will get that one sorted.

neilcampbell commented 9 years ago

The LoggerName on PactConfig is intentionally internal. Is the log file name something you guys actually want to control or is it ok to keep it internal and just set a sensible default. Something like "logs"?

davidmcgregor commented 9 years ago

I'm okay with a sensible default - I can't think of any reason at the moment why we'd want to change it. Thanks!

neilcampbell commented 9 years ago

Actually I looked a little deeper and no logs will be generated when you use the MockProviderNancyBootstrapper directly.

neilcampbell commented 9 years ago

Fixed in 2ca38aa75d1f4a3fb503dd74e0170e8a3ffd975c and released in 1.0.9. Can I please get you to do an update and check that you no longer see the issue?

davidmcgregor commented 9 years ago

That's done the trick. It's all fixed up now. Thanks!

davidmcgregor commented 9 years ago

One more issue now - when running in parallel I'm getting errors of logs being used by other processes:

Result Message: System.IO.IOException : The process cannot access the file '...\logs\api.2_verifier.log' because it is being used by another process.

Result StackTrace:
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share) at System.IO.Abstractions.FileWrapper.Open(String path, FileMode mode, FileAccess access, FileShare share) at PactNet.Infrastructure.Logging.LocalRollingLogFileMessageHandler..ctor(IFileSystem fileSystem, String logFilePath) in c:\projects\pact-net\PactNet\Infrastructure\Logging\LocalRollingLogFileMessageHandler.cs:line 20 at PactNet.Infrastructure.Logging.LocalLogProvider.AddLogger(String logDir, String loggerNameSeed, String logFileNameTemplate) in c:\projects\pact-net\PactNet\Infrastructure\Logging\LocalLogProvider.cs:line 24 at PactNet.PactVerifier.Verify(String description, String providerState) in c:\projects\pact-net\PactNet\PactVerifier.cs:line 223

neilcampbell commented 9 years ago

This looks like a different issue to the one originally raised.

It looks like you are using the Verify("description", "provider state") method, which was added to help filter scenarios whilst debugging failures and not as a way to isolate individual interaction verifications (for running in parallel). As such provider verifications should never run in parallel.

The reason I mention this is that if you use the filtering method during provider verification, you may miss new interactions that a consumer has added, which would be very bad.

davidmcgregor commented 9 years ago

Understood! Thanks for looking into it,