Proposal: Using references to log messages in logging hooks
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- perl
- Domain
- backend, observability
Research direction
Start by reading Dancer2::Core::Role::Logger, especially the around 'log' hook, and compare it with Dancer2::Core::Role::Template. Review how execute_hook receives @args and how logging adapters consume them. The issue does not define a settled behavior, so done would require agreement on whether hooks may modify log messages and a resulting implementation or documented decision.
Written by the indexing model from the issue text.
Description
I was making some minor corrections in the logging docs when I happened upon hooks in our logging engine (what a nice surprise!). I noticed they were not documented, and as I tried to use them to make some examples, I got a bit frustrated by them. I'd like to discuss a possible change.
In Dancer2::Core::Role::Logger, we have:
around 'log' => sub {
my ($orig, $self, @args) = @_;
$self->execute_hook( 'engine.logger.before', $self, @args );
$self->$orig( @args );
$self->execute_hook( 'engine.logger.after', $self, @args );
};
In other places (such as Dancer2::Core::Role::Template), we pass around a reference so we can manipulate content in the hooks before continuing execution. This isn't possible in the logger hook, at least not trivially (unless I am missing something - which is completely likely!). So you'd have to push that functionality down into the logging adapter/logger engine, or create another wrapper method for log().
What are your thoughts about making @args a reference instead? This would allow developers to add additional information to log messages (such as a request ID or other metadata) without repeating code.
On the other hand, you can make a solid argument for not wanting to alter log messages. And maybe that was the original intent. I wasn't here for that. If that is the case, I can close this and you all can disregard.
Dancers, what are your thoughts here? Am I simply missing the point of what you're supposed to do with this hook?
- Dominant language
- Perl
- Stars
- 604
- Forks
- 287
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 6
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from PerlDancer/Dancer2
-
Add .gitattributes so share/skel keeps LF on a Windows git checkoutPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 1/5 Under an hour Newbie friendliness 85/100
PerlDancer/Dancer2#1854 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
PerlDancer/Dancer2#1851 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
PerlDancer/Dancer2#1850 ·
-
Bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
PerlDancer/Dancer2#1820 ·
-
Enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
PerlDancer/Dancer2#1819 ·
All issues in PerlDancer/Dancer2
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
major/MySQLTuner-perl#1007 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 69/100
bioconda/bioconda-recipes#70187 ·
Maintainers usually reply within 2 days
-
documentation Needs Triage
Difficulty 1/5 Under an hour Newbie friendliness 93/100
Maintainers usually reply within 1 day