Aspect Oriented Programming practice questions

Worked examples for Aspect Oriented Programming

1. Question 1

   Inside a Spring-managed bean, public method m1() calls this.m2(), and m2() is matched by an @Around aspect. Does the advice run for that internal call? ```java @Service public class OrderService { public void m1() { this.m2(); // internal self-invocation } public void m2() { // ... matched by an @Around aspect } } ```

   1. A. No — self-invocation goes through 'this', bypassing the proxy, so the advice does not fireCorrect answer

      An internal this.m2() call targets the real object directly and never passes through the proxy that carries the advice, so no advice runs — a classic self-invocation gotcha (Spring Framework 5.3 Reference — Understanding AOP Proxies).

   2. B. Yes — Spring weaves the advice directly into the bean's class, so any call triggers it

      This assumes bytecode weaving into the class itself; proxy-based Spring AOP does not modify the target class, so an internal call finds no advice woven in.

   3. C. Yes, but only because m2() is public

      Method visibility does not change the routing of an internal call: whether m2() is public or not, this.m2() still bypasses the proxy, so the advice does not fire.

   4. D. Only if m2() is declared private

      Private methods are not eligible for proxy-based advice at all, so making m2() private would guarantee the advice never runs rather than enable it.

   Explanation

   Spring AOP applies advice through a proxy that wraps the bean, so only calls that arrive via that proxy are intercepted. When a method calls another method on the same instance through 'this', the call goes straight to the underlying object and never crosses the proxy boundary, so no advice fires for the internal call.

2. Question 2

   A Spring application defines a class annotated with `@Aspect` that contains a correctly written `@Before` advice method, but the advice never runs. The class is in a package covered by component scanning. What is the MOST likely cause, and how is it corrected?

   1. A. `@Aspect` alone does not make the class a Spring bean, and auto-proxying is not enabled by default; the class must be declared as a bean (for example with `@Component`) and auto-proxy creation must be switched on with `@EnableAspectJAutoProxy` (or Spring Boot's AOP auto-configuration).Correct answer

      Correct. `@Aspect` is an AspectJ annotation that only marks a class as an aspect; Spring must still manage it as a bean and an auto-proxy creator must be registered — `@EnableAspectJAutoProxy` on a `@Configuration` class (or `spring-boot-starter-aop` auto-configuration) does that.

   2. B. The aspect class must be compiled with the AspectJ compiler (ajc) or woven by the AspectJ load-time weaver; Spring cannot apply `@Before` advice without AspectJ weaving.

      Confuses Spring AOP with full AspectJ weaving. Spring AOP reuses AspectJ's annotations and pointcut expression language but implements advice with runtime proxies — no ajc compilation or load-time weaving is required.

   3. C. The advice method must be declared `public` and return `void`, and the aspect class must implement `org.aopalliance.intercept.MethodInterceptor` for Spring to recognise it.

      Invents a required interface. Annotation-style aspects are plain classes; implementing `MethodInterceptor` is the low-level alternative API, not a prerequisite for `@Aspect`.

   4. D. The aspect must be registered in a separate configuration file listing it under an `aop:aspect` element, because annotation-declared aspects are only discovered when XML schema-based AOP config is also present.

      Assumes the annotation style depends on the XML schema style. `<aop:aspectj-autoproxy/>` and `@EnableAspectJAutoProxy` are equivalent alternatives; neither requires re-declaring the aspect in XML.

   Explanation

   Enabling `@AspectJ` support is a two-part requirement: the aspect must be a Spring-managed bean, and the container must register an auto-proxy creator that recognises `@Aspect`-annotated beans. `@EnableAspectJAutoProxy` on a `@Configuration` class (the Java-config equivalent of `<aop:aspectj-autoproxy/>`) supplies the second part, and Spring Boot's AOP starter does it automatically. Spring AOP borrows AspectJ's annotation and pointcut syntax but weaves via runtime proxies, so no AspectJ compiler or load-time weaver is involved; likewise, no framework interface must be implemented and no XML aspect declaration is needed when the annotation style is used.

3. Question 3

   A bean with no interfaces is proxied by CGLIB. One method matched by the pointcut is declared final, and advice fires on the bean's other methods but never on that one. What explains it?

   1. A. A CGLIB proxy subclasses the target, so it cannot override a final method and therefore cannot intercept it.Correct answer

      CGLIB applies advice by subclassing the target and overriding its methods; a final method cannot be overridden, so the proxy cannot intercept it while the non-final methods are still advised.

   2. B. final methods are treated as private, and private methods are never eligible for advice.

      final and private are different modifiers; a final method can still be public and callable, and it is the inability to override it, not a change to its visibility, that prevents interception.

   3. C. CGLIB refuses to build the proxy when any method is final, so none of the bean's methods are advised.

      The proxy is still created and the other methods are advised; only the final method is left un-overridden, so this contradicts the stated behaviour.

   4. D. The JIT compiler inlines final methods at runtime, erasing the join point.

      JIT inlining is a runtime optimisation invisible to the proxying model; the join point is missed at proxy-creation time because the method cannot be overridden, not because of inlining.

   Explanation

   CGLIB proxies work by generating a subclass of the target and overriding its methods to insert advice. A final method cannot be overridden, so the generated subclass cannot intercept it, which is why advice fires on the bean's other (non-final) methods but not on that one. This is also why CGLIB-proxied classes and their advised methods must not be final. Visibility rules, a refusal to build the proxy, and JIT inlining are not the cause.

4. Question 4

   You want to advise every method-execution join point occurring in any type located in com.xyz.service OR any of its sub-packages, without constraining the return type, method name, or arguments. Which pointcut expression is correct and idiomatic?

   1. A. execution(* com.xyz.service.*.*(..))

      The single '.*' in the type position matches only types sitting directly in com.xyz.service; it does not descend into sub-packages, so it misses part of the required scope.

   2. B. within(com.xyz.service..*)Correct answer

      within(...) scopes matching to types, and the '..' wildcard means com.xyz.service and every sub-package, so this matches all method executions in that whole subtree without constraining signatures.

   3. C. within(com.xyz.service.*)

      A single '*' after the package matches only types directly in com.xyz.service; descending into sub-packages requires the '..' wildcard instead.

   4. D. bean(com.xyz.service..*)

      bean(...) matches on Spring bean names, not on package paths, so a dotted package expression is not what it interprets and it would not select by location.

   Explanation

   within(com.xyz.service..*) uses the '..' wildcard, which denotes the named package and all of its sub-packages, and because within scopes by declaring type it needs no return-type, method-name, or argument pattern. A single '*' in the type position (whether in execution or within) stops at the immediate package and never descends, and the bean designator matches bean names rather than package locations.

5. Question 5

   How does Spring AOP perform weaving?

   1. A. It does not weave; it copies source code

      Spring AOP does not copy source code; weaving is the act of applying advice, and this description does not correspond to any real weaving mechanism.

   2. B. At runtime, by creating proxies around beansCorrect answer

      Spring AOP is proxy-based and weaves at runtime, wrapping beans in proxies that intercept method calls to apply advice.

   3. C. At compile time, modifying the .class files

      Compile-time weaving that modifies .class files is an AspectJ capability, not how plain Spring AOP works.

   4. D. At class-load time via a load-time weaver only

      Load-time weaving is an AspectJ capability; plain Spring AOP does not rely on a load-time weaver to apply advice.

   Explanation

   Spring AOP is proxy-based: it weaves at runtime by wrapping each advised bean in a proxy that intercepts method invocations. Compile-time and load-time weaving that alter bytecode are capabilities of full AspectJ rather than of plain Spring AOP.

6. Question 6

   In a non-Boot Java-config application, what enables @Aspect-style annotation AOP?

   1. A. @EnableAspectJAutoProxy on a @Configuration class (with AspectJ on the classpath)Correct answer

      This turns on the auto-proxy creator that applies @Aspect advice; Spring Boot enables the same thing automatically when AOP is on the classpath.

   2. B. Nothing — @Aspect beans are always active

      Aspects are not auto-active: without the auto-proxy creator being enabled, an @Aspect bean is just a registered bean and no advice is applied.

   3. C. @EnableAOP on the application class

      There is no @EnableAOP annotation in Spring; the real enabler is @EnableAspectJAutoProxy.

   4. D. @ComponentScan by itself

      Component scanning only discovers and registers the aspect as a bean; it does not activate the proxying that actually applies the advice.

   Explanation

   Annotation-driven @Aspect advice in a plain Java-config application requires explicitly switching on the auto-proxy creator, which is what @EnableAspectJAutoProxy (with AspectJ on the classpath) does; Spring Boot performs this automatically. Simply declaring or component-scanning aspect beans registers them but does not weave their advice, and there is no separate @EnableAOP annotation.

7. Question 7

   Which advice type runs only when the target method exits by throwing an exception?

   1. A. @Before

      Incorrect: @Before runs before the method executes, regardless of how it exits.

   2. B. @After

      Incorrect: @After runs in all cases, finally-style, not only on an exception.

   3. C. @AfterReturning

      Incorrect: @AfterReturning runs only when the method returns normally, not when it throws.

   4. D. @AfterThrowingCorrect answer

      Correct: @AfterThrowing fires only on the exception path, when the target method exits by throwing.

   Explanation

   Only after-throwing advice is bound to the exception exit path, running when the target method completes by throwing. The other advice kinds run before invocation, only on normal return, or unconditionally like a finally block.

8. Question 8

   An advised method exits by throwing an exception. Setting aside around advice, which TWO of the following advice types can still execute their body after that exception is thrown? Select TWO.

   1. A. @After (finally) advice.Correct answer

      @After behaves like a finally block: it runs after the join point regardless of whether it returned normally or threw, so it fires on the exceptional exit.

   2. B. @AfterThrowing advice.Correct answer

      @AfterThrowing is defined to run precisely when the advised method exits by throwing, so it executes after the exception is raised.

   3. C. @AfterReturning advice.

      @AfterReturning runs only when the method completes normally; an exceptional exit skips it entirely.

   4. D. @Before advice.

      @Before runs ahead of the join point, so it executes before the target runs at all, not after the exception is thrown.

   5. E. A method annotated only with @Pointcut.

      A @Pointcut method just names a matching expression; it is not advice and never runs as a callback at a join point.

   Explanation

   After a method throws, the callbacks that still fire are @After, which runs on every exit path like a finally block, and @AfterThrowing, which is triggered specifically by the exceptional exit. After-returning advice is skipped because the method did not return normally, before advice has already run ahead of the call, and a @Pointcut method is a selector rather than advice.