Spring AOP

AOP (Aspect-Oriented Programming) is a way to modularize cross-cutting concerns like logging, security, and transactions.

Spring AOP is Spring’s proxy-based AOP framework for method-level interception on Spring-managed beans.

To keep cross-cutting logic separate from business code and reduce duplication.

A concern affecting multiple modules, e.g., logging, metrics, auth checks.

A class that groups advice and pointcut definitions.

Action executed at a matched join point (before/after/around/etc.).

A method execution point on a proxied bean.

A predicate/expression selecting which join points should run advice.

Applying aspects to target objects (in Spring AOP, via runtime proxies).

No, it is primarily runtime proxy-based weaving.

• Before
• After
• AfterReturning
• AfterThrowing
• Around

Runs advice before target method execution.

Runs advice after method finishes (success or exception).

Runs only when method returns successfully.

Runs only when method throws an exception.

Wraps method execution and controls whether/when target executes.

Object passed to around advice enabling proceed() invocation.

Target method is skipped.

Annotation marking a class as an aspect.

Enables proxy-based AOP processing in Spring configuration.

AspectJ expression syntax is used, but full AspectJ weaving is not required for basic Spring AOP.

The original bean instance being proxied/intercepted.

A wrapper object that intercepts method calls and applies advice.

JDK proxies interfaces; CGLIB subclasses concrete classes.

When target implements at least one interface (default strategy).

When proxying class-based targets (or when forced).

Final classes cannot be subclassed, so class-based proxying is limited.

Generally no, because subclass proxies cannot override final methods.

No, proxy interception targets externally invoked methods.

A method within a bean calling another method in same bean bypasses proxy.

Internal call uses this directly, not proxy reference.

Move advised method to another bean and call through container-managed proxy.

AspectJ pointcut expression syntax for matching methods/types.

execution(...) is most common.

execution(* com.example.service.*.*(..))

Any method name with any argument list.

Matches current package and subpackages.

Matches methods annotated with a specific annotation.

Matches join points within certain types/packages.

Matches based on proxy type.

Matches based on target object type.

Matches runtime argument types.

Spring-specific designator matching bean names.

Prevents accidental interception and performance/noise issues.

Determines execution precedence when multiple aspects match same join point.

Use @Order or Ordered interface.

Input validation, correlation ID setup, audit pre-log.

Result transformation metadata logging, success metrics.

Error logging, exception metrics, alert enrichment.

Timing, retries, transaction wrappers, conditional execution.

Yes, but also easiest to misuse.

Around advice can supply different args when calling proceed(args).

Around advice can wrap/replace return value.

No, keep aspects focused on cross-cutting concerns.

Observability concerns (logging, metrics, tracing).

Integration tests with Spring context and assertions on side effects.

Not with Spring proxy AOP unless object is managed/proxied by container.

Allows obtaining current proxy in special cases (use sparingly).

Yes for proxy model; field/constructor join points require AspectJ weaving.

Use narrow pointcuts, simple advice, and avoid hidden business behavior.

According to precedence/order; around advice nests others.

Outer aspect proceeds to next interceptor until target executes.

Caller sees success path, which may break semantics/monitoring.

Usually yes; multiple/no proceed calls require deliberate design.

Method annotated with @Pointcut reused across advice methods.

Improves readability and consistency across aspects.

Yes, using boolean operators (&&, ||, !).

Service package AND public methods AND annotated with @Timed.

Reading method signature, args, target class from JoinPoint.

From joinPoint.getSignature().getName().

joinPoint.getArgs().

joinPoint.getTarget().getClass() (or signature metadata).

Signature subtype exposing method-specific metadata.

Custom annotations like @Auditable, @Timed, @Retryable.

More explicit intent and lower accidental match risk.

Adding interfaces/behavior to proxied objects (limited in Spring vs full AspectJ).

Limited compared to full AspectJ weaving.

Forces class-based (CGLIB) proxies.

Can proxy classes without interfaces but has subclassing constraints.

Exposes current proxy via AopContext for advanced scenarios.

Creates coupling and hides design issues (often self-invocation smell).

@Transactional is implemented via AOP proxies/interceptors.

Proxy cannot intercept private method calls.

Internal method call bypasses transactional proxy.

Annotations like @PreAuthorize are applied via interceptors/proxies.

@Cacheable and related annotations rely on proxy interception.

Different interceptor order changes behavior and side effects.

Combination of advice + pointcut packaged for application.

Exposes proxy configuration details for advanced inspection.

Programmatic API to create AOP proxies manually.

Common advisor implementation combining pointcut and advice.

Static matched by signature; dynamic may evaluate runtime arguments.

Higher runtime overhead and complexity.

Match based on call stack/control flow (AspectJ concept, limited/expensive patterns).

Logging sensitive data or flooding logs in high-traffic methods.

Redact fields and define explicit allowlist for logged values.

Around advice measuring duration and recording metrics.

Supports filtering by operation/class/outcome in dashboards.

Retrying non-idempotent operations can duplicate side effects.

Restrict to transient exceptions and idempotent operations.

Maps low-level exceptions to domain-specific exceptions.

No, preserve cause chain.

Captures who/what/when for critical actions.

Prefer reliable async/event pipeline or dedicated audit store pattern.

Pointcut unintentionally starts/stops matching after refactoring.

Use annotation markers and tests verifying interception coverage.

Test asserting aspect behavior on representative target methods.

Check class name/proxy utilities/logging of advisor application.

Proxy type compatibility must satisfy injection/casting expectations.

Proxy class may differ from target; equality assumptions can break.

Some proxies/handlers are not serialization-friendly by default.

Aspect beans are usually singletons; state must be immutable/thread-safe.

No, use method-local variables or request context holders.

Aspect sets request/trace context for logs and clears it reliably.

Context leakage across reused threads.

Advice should avoid duplicate side effects if call chain retries/reenters.

Adds proxy/interceptor frames, sometimes obscuring direct call flow.

Document scope, pointcuts, order, and expected side effects.

Need field/constructor join points or non-Spring object weaving.

Keep aspects explicit, test-covered, and limited to true cross-cutting needs.

Aspect instantiation models beyond singleton; mostly full AspectJ territory.

Yes, unless scope changed.

Troubleshooting unexpected behavior due to interceptor order.

Interception overhead without meaningful value.

Broad pointcuts + hidden side effects + poor tests.

Each interceptor adds call overhead; excessive chains increase latency.

Applying heavy advice to ultra-frequent methods can hurt throughput.

Measure with/without aspects, inspect p95/p99 latency and CPU allocation.

Broader join point model and potentially lower proxy indirection in some cases.

Weaving aspects during class loading via agents/instrumentation.

Agent setup, classloader interactions, and deployment constraints.

Most enterprise method interception needs with simpler ops model.

Enforce rules (e.g., no repository access from controllers) via checks/instrumentation.

Prefer compile/test-time checks when possible; runtime checks for critical safeguards.

Assuming advice runs everywhere despite self-invocation or non-proxied objects.

Combine method security with explicit boundary design and tests.

Unexpected propagation/ordering can alter commit/rollback behavior.

Integration tests covering propagation, exceptions, and rollback semantics.

Aspect creates spans/tags around service methods with error status recording.

Duplicate spans/metrics if both auto-instrumentation and custom aspects run.

Define clear ownership and disable overlapping instrumentation points.

Controls volume during high traffic/incidents while preserving diagnostic value.

Advice failures should not cascade and break core business flow (unless required).

Generally no; fail open carefully and log internal failures.

Fail-closed denies on uncertainty; fail-open allows continuation—choose by risk model.

Explicitly define precedence among tracing, security, transactions, caching, retries.

Security/auth first, then idempotency/validation, then tx, then business, then logging/metrics (context-dependent).

Incorrect nesting may retry inside same failed transaction context.

Custom rollback/compensation must align with transaction boundaries.

Feature flags, canary rollout, and backward-compatible defaults.

Number of methods/services affected by one pointcut change.

Narrow pointcuts, annotation markers, incremental rollout.

Review process for new aspects, pointcut patterns, and operational impact.

Invocation count, added latency, error rate, dropped/skipped behavior counts.

Advice triggers code paths that re-trigger same advice unintentionally.

Guard flags/context markers and carefully scoped pointcuts.

Many generated proxies can increase metaspace/memory pressure.

Proxy only necessary beans and avoid dynamic per-tenant/per-request proxy generation.

Proxy/reflection configuration may need explicit AOT hints.

Encourage build-time analysis and explicit proxy registrations.

Translate external exceptions/protocol concerns at boundary services.

Aspects should support domain logic, not replace explicit domain workflows.

Singleton scope + concurrency safety + easier reasoning.

Consistent logs/metrics/traces across services speed root-cause analysis.

Using broad around advice as hidden control flow engine.

When it encodes business decisions better expressed in explicit services.

Small set of well-documented, high-value aspects with strict tests and observability.

Dedicated interception contract tests plus end-to-end behavior verification.

Canary + shadow traffic + fast rollback for pointcut/order changes.

Verify pointcut scope, ordering, side effects, and failure behavior.

Centralize common pointcuts and deprecate risky patterns gradually.

Advice behavior should be predictable and unsurprising to developers.

Never put expensive I/O inside ubiquitous advice on hot paths.

Prefer explicitness: annotate intent, constrain scope, measure impact.

Use AOP as a precision tool for cross-cutting concerns, not as hidden business orchestration.