[lahma]

LogExceptionHandler, the log action of the exception-handler advice, hasn't logged anything since logging moved to Microsoft.Extensions.Logging in 3.0.3 (fda46d9). PR #346 named this as a follow-up.

The bug. The handler wrapped its expression as #log.<Level>(<expression>[, #e]) and evaluated it with #log bound to an ILogger. ILogger has no Information/Fatal/… instance methods, only LogXxx extension methods. So every evaluation threw, the catch reduced it to a warning, and the handler returned "logged" without writing anything.

The fix.

• ActionExpressionText is the message expression. HandleException evaluates it against the call context (#method, #args, #target, #e). It then calls ILogger.Log(LogLevel, LogMessageOnly ? null : #e, "{Message}", message), so the template stays constant.
• LogName, LogLevel (default Trace) and LogMessageOnly keep their meaning.
• If the expression fails, the handler logs a warning, as before. A legacy #log.Fatal(...) expression gets a specific warning that says how to rewrite it.
• If the logging provider itself fails, the handler logs a separate warning, and the exception the advised method threw still propagates.
• The log entry in the call context is now assigned, not added. Before, a second log handler on the same call threw ArgumentException and replaced the user's exception.
• The set-once guard on ActionExpressionText is removed. It had frozen the first statement's expression, level and LogMessageOnly on a shared keyed handler.

BreakingChanges item 10.

• The getter now returns the expression as set, not the #log.<Level>(...) wrapper.
• A handler configured as #log.Fatal('msg', #e) doesn't log. That form worked on 3.0.2 and earlier only by accident of nesting, and nothing has logged since 3.0.3. Migrate to ActionExpressionText="'msg'" with LogLevel="Critical".
• We decided against a compatibility shim. It would bring back a Common.Logging-shaped #log, which we'd have to maintain.

Tests.

• New LogExceptionHandlerTests, with 17 cases. They use a recording logger factory to check level, category, message text and whether the exception is attached. They also cover:
  • legacy level names through LogLevelConverter;
  • property order;
  • the failure warnings;
  • a null message;
  • a throwing provider;
  • end-to-end runs through ExceptionHandlerAdvice with the DSL, the constraint DSL, keyed handlers and handler lists.
• ExceptionHandlerAspectIntegrationTests actually test something now. Before, they matched a substring anywhere in the log, so the failure warning satisfied them, and some asserted nothing if no exception was thrown. Six of them fail against the old source. ExecuteSpelAction never ran its action, because the type name in its expression couldn't be resolved; it now uses T(type, assembly) and asserts the action ran.
• Spring.Aop.Tests on net10.0: 505 passed, 6 skipped. On net472: 523 passed, 6 skipped. The skips were already there.
• The new tests and the six integration tests fail on the unfixed source.
• spring-reviewer accepted the change with follow-ups, and those follow-ups are in this PR.

Known, not changed here. ExceptionHandlerAdvice reuses one keyed handler instance (log, translate, wrap) for every statement that names it, and each statement overwrites its expressions. This was already the case before this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LGkLQuAuUjvRjrU1AcTsmk