Proxy w Spring AOP — na czym polega problem self-invocation?

Głębiej

Spring AOP jest zwykle **oparte o proxy**:

• JDK dynamic proxy, gdy proxujesz interfejs.
• CGLIB, gdy proxujesz klasę (podklasa).

Proxy przechwytuje wywołania **idące przez proxy**. Gdy kod w beanie wywołuje metodę na `this`, nie wychodzi poza obiekt docelowy, więc proxy nie ma szans tego przechwycić.

Przykład (problem)

@Service
class BillingService {
  @Transactional
  public void pay() { /* ... */ }

  public void run() {
    this.pay(); // omija proxy -> brak transakcji
  }
}

Rozwiązania

• Wyciągnij metodę/aspekt do innego beana i wołaj ten bean.
• Wstrzyknij proxowany interfejs i wołaj przez niego (uważaj na projekt).
• AspectJ weaving tylko jeśli naprawdę potrzebujesz self-invocation.

Typowe pułapki

• `@Transactional` na metodach private i oczekiwanie działania.
• Wołanie „pomocniczych” metod z aspektami w tej samej klasie.
• Testy, które tworzą klasy przez `new` (bez proxy), a potem oczekują zachowania AOP.