AOP Aspect Order Mistakes? Stop Misusing @Order – A Rule That Cuts Interview Errors to Zero

Incident that triggered the analysis

Late at night a colleague discovered that online payment callbacks were chaotic: the payment was marked successful in logs but the transaction was rolled back, almost breaking financial reconciliation. The root cause was two aspects fighting each other because the aspect priority was set incorrectly.

Core priority rule (90% of people get it wrong)

The priority rule is simple: the smaller the numeric value, the higher the priority . This contradicts the common misconception that @Order(1) runs before @Order(2). The rule applies to annotation‑based @Order, the Ordered interface, and XML order="..." configuration.

@Aspect
@Order(1) // higher priority, runs first
public class SecurityAspect { /* permission check */ }

@Aspect
@Order(2) // lower priority, runs later
public class LoggingAspect { /* log recording */ }

Typical pitfalls

If no explicit order is set, aspect execution order becomes random , which once caused a security‑critical e‑commerce project to miss risk checks and lose 200,000 coupons.

Mixing XML and annotation configuration can lead to confusion because the same numeric rule applies, but the container loading order decides the final sequence.

Inherited aspects that do not override getOrder() inherit the parent’s lower priority, leading to missing audit logs in a financial project.

Why the order gets scrambled – three common scenarios

Aspect “cut‑in” : If a transaction aspect ( @Order(2)) runs before a logging aspect ( @Order(1)), the log may still show “success” after a rollback, creating a data illusion.

XML‑annotation mix : When one aspect is defined in XML with order="1" and another with @Order(2), the actual execution order depends on the container’s loading sequence.

Inheritance trap : A subclass aspect that does not override getOrder() inherits the parent’s order, potentially lowering its priority unintentionally.

Four‑step debugging method

Print the aspect tree : Add JVM parameters

-Dspring.show.weaving=true -Dspring.aop.proxy-target-class=true

to display the execution chain, e.g.

[SecurityAspect@Order(1)] → [TxAspect@Order(2)] → [LogAspect@Order(3)]

.

Unit‑test verification : Use AopTestUtils.getAdvisors(myService) and assert the order of advisors, e.g. assertThat(advisors.get(0).getOrder()).isEqualTo(1).

AOP debugging toolkit : Integrate Spring AOP Dashboard to monitor aspect execution in real time.

Production‑level check : Employ Arthas with watch *Aspect * to trace parameters, targets and return values.

Final analogy and template

Think of aspects as a traffic‑light system: high‑priority aspects ( @Order(1)) are like ambulances that must go first, medium priority ( @Order(2)) are buses, and low priority ( @Order(3)) are private cars. A ready‑to‑use template follows this order:

// 1. Critical aspect – transaction/lock
@Aspect
@Order(Ordered.HIGHEST_PRECEDENCE) // value = 0
public class CriticalAspect {}

// 2. Business aspect – validation/conversion
@Aspect
@Order(Ordered.HIGHEST_PRECEDENCE + 1) // value = 1
public class BizAspect {}

// 3. Auxiliary aspect – logging/monitoring
@Aspect
@Order(Ordered.LOWEST_PRECEDENCE) // value = Integer.MAX_VALUE
public class LogAspect {}

Conclusion

Applying the rule reduced aspect‑related bugs from an average of 15 per month to zero in a logistics order‑system project. The essence of aspect ordering is a responsibility‑chain design—just like cooking steps, each aspect must run in the correct sequence, otherwise the result turns into a mess.