The 25 drills you missed on the #21 page — and the six facts behind most of them

Two questions settle every AOP mechanics question

Then, for proxies only, which kind? Picture what each one has to be in Java:

// JDK proxy: a new class that IMPLEMENTS your interfaces
class $Proxy12 implements Payer { ... }               // needs an interface

// CGLIB proxy: a new class that EXTENDS your class
class Billing$$EnhancerBySpringCGLIB$$1a2b extends Billing { ... } // can't if Billing is final
                                                      // can't override final methods

The JDK proxy needs an interface. CGLIB is blocked by final. Only two limits hit both: self-invocation, and private methods (neither kind of proxy can override them). So a public final class Billing with no interface can't be proxied either way, and startup fails. It isn't silently skipped, because there's no proxy to skip the advice on.

Treat it as a flowchart, not a list of facts

@Autowired takes part with one attribute, required. Narrowing by name is the job of @Qualifier("x") (or step 4). There's no name, value or qualifier attribute on @Autowired.

Cycles: ask "does an instance exist yet?"

Boot 2.6 turned the setter case off by default: spring.main.allow-circular-references=false. @Lazy on one of the constructor parameters breaks any cycle, because Spring injects a lazy proxy instead of the real bean.

Look at the method signatures and the answer follows

interface BeanFactoryPostProcessor {
    void postProcessBeanFactory(ConfigurableListableBeanFactory f); // gets the PLANS
}
interface BeanPostProcessor {
    Object postProcessBeforeInitialization(Object bean, String name); // gets a REAL OBJECT
    Object postProcessAfterInitialization(Object bean, String name);  // and can return a replacement
}

• A BPP takes Object bean, so the bean already exists. "Before instantiation" can't be BPP. It runs after the constructor and DI, either side of the init callbacks.
• postProcessAfterInitialization returns an object, and that object is what the container stores. That's how AOP swaps your bean for a proxy: the auto-proxy creator is a BPP, and it returns the proxy from its after-init hook.
• A BFPP takes the factory, which only holds bean definitions (the plans). It runs before any normal bean is created, so it can change scope, property values or ${…} placeholders.

Recognising them by name: Spring's names say what they are. …Configurer classes that edit definitions (PropertySourcesPlaceholderConfigurer, PropertyOverrideConfigurer) are BFPPs. Classes named …BeanPostProcessor (AutowiredAnnotationBeanPostProcessor, CommonAnnotationBeanPostProcessor) are BPPs, which is how they can set fields and call @PostConstruct on real objects.

You got the web version right both times, and the non-web version wrong both times

On #14 you gave a non-web app JNDI and the servlet parameters. These two misses suggest that hasn't changed, probably on JNDI. This is an inference: the copy doesn't show what you clicked. Use the application server as the test:

StandardEnvironment (non-web) adds the first two. StandardServletEnvironment (web) adds the other three on top. Profiles are available in both, because they're part of the Environment interface itself.

Seven facts, each with the wrong answer it's easily confused with

@ModelAttribute is the easiest one to doubt. On a parameter it builds an object from form or query fields, as in save(@ModelAttribute Order order). That's binding.