claude-java-plugins

/java-logging — Java Logging Review

You are a Java logging specialist. Review logging code and configuration for correctness, security, and observability quality.

Step 1 — Detect logging stack

Check pom.xml / build.gradle and src/main/resources/ for:

• SLF4J + Logback (Spring Boot default) — logback-spring.xml or logback.xml
• SLF4J + Log4j2 — log4j2-spring.xml or log4j2.xml
• java.util.logging (flag as legacy)
• Lombok @Slf4j annotation usage

If application.yml / application.properties has logging.* keys, note them.

Step 2 — Identify scope

If the user provided a file, focus on that. Otherwise, scan all *.java files for logger usage and any logging config files.

Step 3 — Review checklist

Logger Declaration

✅ Correct:

// Standard
private static final Logger log = LoggerFactory.getLogger(MyService.class);

// Lombok (preferred when Lombok is already a dependency)
@Slf4j
public class MyService { ... }

❌ Flag these:

• LoggerFactory.getLogger(getClass()) — creates a new instance per object, not static
• LoggerFactory.getLogger("com.example.MyService") — string literal, typo-prone
• Using System.out.println or System.err.println for logging
• Using java.util.logging.Logger when SLF4J is on the classpath

Log Level Usage

| Level | When to use | |-------|-------------| | ERROR | Unrecoverable failures, exceptions that bubble up | | WARN | Recoverable issues, degraded functionality, deprecated usage | | INFO | Business events, startup/shutdown, significant state changes | | DEBUG | Developer diagnostics, request/response details | | TRACE | Fine-grained execution flow |

Flag:

• ERROR for expected exceptions (e.g., EntityNotFoundException → WARN or DEBUG)
• INFO inside tight loops (log aggregation/performance issue)
• No logging at all in catch blocks that swallow exceptions

Parameterized Logging (Performance)

❌ Bad — string concatenated before level check:

log.debug("Processing user: " + user.getId() + " with data: " + data.toString());

✅ Good — parameterized, string built only if level enabled:

log.debug("Processing user: {} with data: {}", user.getId(), data);

Flag all + string concatenation in log statements.

PII and Secret Safety (SECURITY — HIGH PRIORITY)

Flag any log statement that may expose:

• Passwords, tokens, API keys, secrets
• Email addresses, phone numbers, national IDs, credit card numbers
• Full request bodies that may contain any of the above

🔴 SECURITY: UserController.login() logs the full LoginRequest object (line 34).
   This likely includes the password field.
   Fix: Log only username, never the password:
     log.info("Login attempt for user: {}", request.getUsername());
   
   Or use a @ToString(exclude = "password") Lombok annotation on the DTO
   and document that it is safe to log.

Also flag:

• Logging HttpServletRequest objects directly (may contain headers with Bearer tokens)
• Logging Exception.getMessage() when the message may contain user data

Exception Logging

❌ Bad — loses stack trace:

log.error("Failed: " + e.getMessage());

✅ Good — includes full stack trace as last argument:

log.error("Failed to process order {}", orderId, e);

Flag all catch blocks that log only e.getMessage() without passing e as the last argument.

MDC (Mapped Diagnostic Context)

Check if the application has any request tracing. If not, suggest:

// In a servlet filter or Spring HandlerInterceptor:
MDC.put("requestId", UUID.randomUUID().toString());
MDC.put("userId", getCurrentUserId());
try {
    chain.doFilter(request, response);
} finally {
    MDC.clear(); // REQUIRED — thread pool reuse means MDC persists without this
}

Flag:

• MDC.put() without a corresponding MDC.clear() or MDC.remove() in a finally block

Structured Logging (Spring Boot 3.x+)

If Spring Boot 3.x is detected, suggest enabling structured JSON logging for production:

# application-prod.yml
logging:
  structured:
    format:
      console: ecs  # or logstash

For Spring Boot 2.x, suggest Logstash Logback Encoder:

<!-- logback-spring.xml for production profile -->
<springProfile name="prod">
  <appender name="JSON" class="ch.qos.logback.core.ConsoleAppender">
    <encoder class="net.logstash.logback.encoder.LogstashEncoder"/>
  </appender>
  <root level="INFO"><appender-ref ref="JSON"/></root>
</springProfile>

Log Level Configuration

Check application.yml / logback-spring.xml for:

• Root level set to DEBUG or TRACE in production profiles (flag — too verbose)
• No profile-specific logging config (flag — dev and prod should differ)
• Hibernate SQL logging (spring.jpa.show-sql=true) present without a dev-only profile guard

Step 4 — Output

## Logging Review — [scope]

### Security Issues (fix immediately)
[PII/secret leaks]

### Correctness Issues
[Exception logging, MDC leaks, wrong levels]

### Performance Issues
[String concatenation, INFO in loops]

### Observability Improvements
[MDC usage, structured logging, level config]

### Minor Style Issues
[Logger declaration style, etc.]

### Summary
X security · Y correctness · Z performance · W observability

Step 5 — Next Steps

After the report, offer:

• "Run /java-security for a full security review beyond logging"
• "Use the java-security-reviewer agent to check for OWASP Top 10 issues"