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

Add PSR-3 logging #74

Open
schlessera opened this issue Feb 19, 2021 · 1 comment
Open

Add PSR-3 logging #74

schlessera opened this issue Feb 19, 2021 · 1 comment
Labels
Infrastructure Changes impacting testing infrastructure or build tooling

Comments

@schlessera
Copy link
Collaborator

The TransformationEngine should accept a PSR-3 logger implementation and route it through to the transformers. This is a standardized way of letting the consumer of the library decide how and when to accept logging information and is mandatory in larger projects to maintain control over the different parts of the system.

The library should also include a logger implementation that can be used (or will be used by default, TBD) that logs errors into HTML comments, as a sort of last resort to communicating error conditions in an HTTP stack that doesn't come with its own PSR-3 routing.

In the future, the validator and the sanitizer engines should accept such a PSR-3 logger as well.

@schlessera schlessera added the Infrastructure Changes impacting testing infrastructure or build tooling label Feb 19, 2021
@schlessera
Copy link
Collaborator Author

We already have the ErrorCollection object which is mandatory and collects actual errors within the Optimizer.

The logger would be optional and maybe complementary to that and collect purely informational and/or debugging information. It could also forward the errors added to the ErrorCollection as well, so that log files contain the complete picture of what the system is going through.

The way a PSR-3 logger is usually handled is that, at the very least, you pass a NullLogger around (see NullObject design pattern) and all the places where logging makes sense just blindly log into whatever logging instance they received.

Then, the outside/consuming code can decide what logging functionality is needed and pass the corresponding implementation into the system via dependency injection.

This is different than the ErrorCollection object that we currently have for errors, because that one:

  • is required and clearly communicated as being the "return value" mechanism of the optimizer;
  • deals only with errors and mustn't be abused for informational/debugging messages;
  • is a simple bag that collects these errors to make them easy to pass around;
  • cannot take care of routing/dispatching/orchestrating/etc... which might be needed for higher throughput messaging.

Food for thought:
Is the ErrorCollection object really needed, or would it be preferable to have a PSR-3 logger only which covers the entire spectrum of feedback (debug, info, warnings & errors in several severities)?
Is it preferable to use both for semantically separating the two concepts of "providing generic output" & "gathering a list of encountered errors"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Infrastructure Changes impacting testing infrastructure or build tooling
Projects
None yet
Development

No branches or pull requests

1 participant