What is schema-based (XML) AOP configuration in Spring, and what does the <aop:config> element do?

juniorshould knowfreq 35%

answer

aop namespace, <aop:config> outer container
registers auto-proxy creator (BeanPostProcessor)
advice = plain POJO methods, wiring in XML
same AspectJ pointcut language, use and/or/not
proxy-target-class + expose-proxy attributes

basics

~10 s

It configures aspects in XML instead of with @Aspect annotations. The aop:config element (from the aop namespace) holds aspect definitions; Spring reads it and wraps matching beans in proxies that run your advice.

solid answer

~40 s

Schema-based AOP is the XML alternative to @AspectJ annotations. You wrap everything in a top-level aop:config element from the Spring aop namespace. Inside it you declare <aop:aspect ref="someBean">, which points at a plain POJO whose ordinary methods act as advice; you attach them with aop:before, aop:after-returning, aop:around, etc., each naming a method and a pointcut. Declaring aop:config also registers an auto-proxy creator behind the scenes, so any bean matched by a pointcut gets wrapped in a Spring AOP proxy. The advice bean needs no AOP annotations at all — the wiring lives entirely in XML, which suits teams that keep configuration external to code or work with beans they can't annotate.

Schema-based AOP is the XML alternative to @AspectJ annotations. You wrap everything in a top-level <aop:config> element from the Spring aop namespace. Inside it you declare <aop:aspect ref="someBean">, which points at a plain POJO whose ordinary methods act as advice; you attach them with <aop:before>, <aop:after-returning>, <aop:around>, etc., each naming a method and a pointcut. Declaring <aop:config> also registers an auto-proxy creator behind the scenes, so any bean matched by a pointcut gets wrapped in a Spring AOP proxy. The advice bean needs no AOP annotations at all — the wiring lives entirely in XML, which suits teams that keep configuration external to code or work with beans they can't annotate.

code

java · 26 lines

java

// The backing bean — a plain POJO, NO AOP annotations anywhere.
package com.app;

public class AuditAspect {
    public void logEntry() {
        System.out.println("Entering a service method");
    }
}

/*  spring-context.xml:
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="...beans.xsd ...spring-aop.xsd">

    <bean id="auditAspect" class="com.app.AuditAspect"/>

    <aop:config>
        <aop:aspect ref="auditAspect">
            <aop:before
                pointcut="execution(* com.app.service..*(..))"
                method="logEntry"/>
        </aop:aspect>
    </aop:config>
</beans>
*/

go deeper

for a junior

Know that aop:config is the XML container and the advice bean is a plain POJO with methods named in XML.

for a middle

Explain that aop:config registers an auto-proxy creator and that pointcut syntax is the same AspectJ language with and/or/not keyword operators.

for a senior

Discuss proxy-target-class/expose-proxy, coexistence with @AspectJ, and the singleton-only instantiation limitation.

for a principal

Frame the trade-off: XML for externalized/third-party wiring and tx advisors vs annotations for cohesion and advanced models; both are proxy-based Spring AOP with identical join-point limits.

What it is. Spring AOP lets you insert cross-cutting behavior (logging, timing, security, transactions) around bean method calls without editing those methods. There are two ways to declare that behavior: the @AspectJ annotation style (@Aspect, @Before, @Around on Java classes) and the schema-based / XML style using the aop XML namespace. This leaf is about the second.

The namespace. Your Spring XML must declare the aop schema:

xml

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           https://www.springframework.org/schema/beans/spring-beans.xsd
           http://www.springframework.org/schema/aop
           https://www.springframework.org/schema/aop/spring-aop.xsd">

<aop:config>. This is the mandatory outer container for all schema-based aspect and advisor declarations. Simply having it in your context triggers Spring to register an auto-proxy creator (an AspectJAwareAdvisorAutoProxyCreator) as an infrastructure bean. That auto-proxy creator is a BeanPostProcessor that, at bean-creation time, checks every bean against the declared pointcuts and — if any advice applies — replaces the bean reference with a proxy (JDK dynamic proxy if the bean implements interfaces, CGLIB subclass otherwise). Callers get the proxy; the proxy runs your advice around the real method.

What lives inside <aop:config>:

<aop:pointcut> — a named, reusable pointcut expression.
<aop:aspect> — groups advice around a backing POJO bean.
<aop:advisor> — wires a standalone advice/Advisor bean to a pointcut (no aspect POJO needed).

Key trait. The backing bean of an <aop:aspect> is a plain Spring bean — its advice methods are ordinary methods with no annotations. All the AOP metadata (which method is before advice, what it matches) lives in XML. This is the defining contrast with @AspectJ.

Pointcut expression language. Both styles use the same AspectJ pointcut expression language (execution(...), within(...), args(...), @annotation(...), etc.). XML doesn't change what you can match, only where the declaration lives. One syntactic gotcha: &&, ||, ! contain XML-special characters, so in XML you use the word forms and, or, not (e.g. execution(* com.app..*(..)) and args(id)).

Attributes on <aop:config>:

proxy-target-class="true" — force CGLIB class-based proxies even for interface-implementing beans.
expose-proxy="true" — make the current proxy available via AopContext.currentProxy() so self-invocations can be re-routed through the proxy.

When to use it. Choose XML when you can't or don't want to annotate the advice class (e.g., third-party classes), when you keep configuration outside code by policy, or for framework wiring like <tx:advice> + <aop:advisor> for declarative transactions. Choose @AspectJ when you want the aspect self-contained and refactor-friendly, or need advanced instantiation models (perthis, pertarget) — schema-based aspects support only the singleton instantiation model.

Limitations vs @AspectJ. Schema style cannot express perthis/pertarget/percflow aspect instantiation, and combining multiple pieces of advice from different aspects that share state is more awkward. Otherwise the two are functionally equivalent — both are Spring AOP (proxy-based, method-execution join points only, no field or constructor interception).

**What it is.** Spring AOP lets you insert cross-cutting behavior (logging, timing, security, transactions) around bean method calls without editing those methods. There are two ways to declare that behavior: the `@AspectJ` annotation style (`@Aspect`, `@Before`, `@Around` on Java classes) and the **schema-based / XML style** using the `aop` XML namespace. This leaf is about the second. **The namespace.** Your Spring XML must declare the aop schema: ```xml <beans xmlns="http://www.springframework.org/schema/beans" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/aop https://www.springframework.org/schema/aop/spring-aop.xsd"> ``` **`<aop:config>`.** This is the mandatory outer container for all schema-based aspect and advisor declarations. Simply having it in your context triggers Spring to register an auto-proxy creator (an `AspectJAwareAdvisorAutoProxyCreator`) as an infrastructure bean. That auto-proxy creator is a `BeanPostProcessor` that, at bean-creation time, checks every bean against the declared pointcuts and — if any advice applies — replaces the bean reference with a **proxy** (JDK dynamic proxy if the bean implements interfaces, CGLIB subclass otherwise). Callers get the proxy; the proxy runs your advice around the real method. **What lives inside `<aop:config>`:** - `<aop:pointcut>` — a named, reusable pointcut expression. - `<aop:aspect>` — groups advice around a backing POJO bean. - `<aop:advisor>` — wires a standalone advice/Advisor bean to a pointcut (no aspect POJO needed). **Key trait.** The backing bean of an `<aop:aspect>` is a **plain Spring bean** — its advice methods are ordinary methods with no annotations. All the AOP metadata (which method is `before` advice, what it matches) lives in XML. This is the defining contrast with `@AspectJ`. **Pointcut expression language.** Both styles use the **same AspectJ pointcut expression language** (`execution(...)`, `within(...)`, `args(...)`, `@annotation(...)`, etc.). XML doesn't change what you can match, only where the declaration lives. One syntactic gotcha: `&&`, `||`, `!` contain XML-special characters, so in XML you use the word forms `and`, `or`, `not` (e.g. `execution(* com.app..*(..)) and args(id)`). **Attributes on `<aop:config>`:** - `proxy-target-class="true"` — force CGLIB class-based proxies even for interface-implementing beans. - `expose-proxy="true"` — make the current proxy available via `AopContext.currentProxy()` so self-invocations can be re-routed through the proxy. **When to use it.** Choose XML when you can't or don't want to annotate the advice class (e.g., third-party classes), when you keep configuration outside code by policy, or for framework wiring like `<tx:advice>` + `<aop:advisor>` for declarative transactions. Choose `@AspectJ` when you want the aspect self-contained and refactor-friendly, or need advanced instantiation models (`perthis`, `pertarget`) — schema-based aspects support **only the singleton** instantiation model. **Limitations vs @AspectJ.** Schema style cannot express `perthis`/`pertarget`/`percflow` aspect instantiation, and combining multiple pieces of advice from *different* aspects that share state is more awkward. Otherwise the two are functionally equivalent — both are Spring AOP (proxy-based, method-execution join points only, no field or constructor interception).

Does using <aop:config> require your advice class to implement any interface or extend any Spring class?
No. The backing bean is an ordinary POJO. All AOP metadata lives in XML, so the advice class has zero Spring/AOP dependencies. (The exception is <aop:advisor>, which wires a bean that already implements a Spring/AOP Advice interface.)
Can schema-based and @AspectJ aspects coexist in the same context?
Yes. You can have <aop:config> aspects and <aop:aspectj-autoproxy/> annotated aspects in the same application; Spring merges all matching advisors and applies them through a single proxy per bean.

saying these in an interview costs you the question

Thinking the XML advice class must be annotated with @Aspect (it must NOT — that's the whole point).
Believing XML AOP uses a different pointcut language than @AspectJ (same AspectJ expression language).
Saying <aop:config> weaves at compile time or does bytecode weaving (it's runtime proxy-based Spring AOP).

What is schema-based (XML) AOP configuration in Spring, and what does the <aop:config> element do?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~2 min

▾common follow-ups2 questions

▾red flags3 flags

§ context

▾related questions5 questions

▾related topics3 topics

answer

go deeper

context