Supporting v2 handlers and removing removed. #321
Conversation
|
Thanks @gmponos - added that message. What do you think? any experience with multiple version testing? Is that covered by the definitions within travis? |
|
Hello @inverse
To be honest no. I don't have that much.
Thank you for taking into account my feedback.. I truly wanted also the your opinion (and from the maintainers.. ) if it makes sense to have a deprecation on the configuration level.. It might be overhead since a deprecation will be triggered when the handlers will be initialized: https://github.com/Seldaek/monolog/blob/1.x/src/Monolog/Handler/HipChatHandler.php#L100 I think that symfony configuration has a special option that you can set a config option as deprecated.. not sure if raises also a deprecation notice and if it would make sense to have it here as well.. Last sorry if I caused any trouble... |
|
@gmponos Ahh you're right - it probably makes sense to allow the package not the bundle to flag such deprecation. As for the Symfony one - looks like that's more for configuration keys which in this case is a string type which I don't think makes sense. See: https://symfony.com/blog/new-in-symfony-3-4-deprecate-configuration-options |
|
@lyrixx any input on this direction? |
|
Thank you. |
This PR was merged into the 3.x-dev branch. Discussion ---------- Remove invalid handlers This PR removes the invalid handlers added in #321: Adding an handler is not only about adding the mapping `shortName` <=> `class`: The constructor's arguments have to be defined in the `buildHandler` function. Otherwise, we get the following exception: ``` InvalidArgumentException: Invalid handler type "logmatic" given for handler "logmatic" /data/oss/monolog-bundle/DependencyInjection/MonologExtension.php:911 ``` This PR adds support for handler "noop". Re-adding supports for the other (more complex) handlers could be done in dedicated PR. Commits ------- 44799b3 Remove invalid handlers
This would allow the wiring up of v2 handlers and preventing wiring of removed on V2 API.
Wanted to get feedback if this approach is suitable before I continue with adding tests to cover the validation aspect.
If you like the approach this is taking do you have any guidelines around testing against multiple versions of monolog? e.g. something like this https://github.com/g1a/composer-test-scenarios
Release notes: https://github.com/Seldaek/monolog/releases/tag/2.0.0