Spring XML and AOP hidden logic

Spring 2.x applications configured in XML often use AOP for more than logging. An around advice applied by a pointcut such as execution(* com.acme.billing..*Service.calculate*(..)) can apply a regulatory cap, check an entitlement, or swap a return value, and nothing in the target class mentions it. Transaction advice in <tx:advice> sets propagation and rollback rules per method name pattern, and those rules decide which failures undo which writes. Spring's proxy-based AOP also has a well-known gap: a call from one method to another method on the same object does not pass through the proxy, so the advice does not run. Rewrites that port the Java classes and replace XML with annotations by hand drop advice, change which methods it matches, or newly apply it to self-invocations where it never ran before.

PYD ENTERPRISES parses Spring XML contexts, including imports and ${...} property substitution, into a bean graph with concrete classes, constructor and property injection, and scopes. AspectJ pointcut expressions in <aop:config> and @Aspect classes are parsed and matched against every method of every bean, using the same matching semantics as Spring's proxy-based AOP. For each join point the engine records which advice applies, in which order, and with which transaction attributes. Intra-class calls are detected so that advice is shown as not applying on those paths. Around advice bodies are then analysed like any other code, and their decisions are extracted as rules attached to the advised methods.

Business advice becomes an explicit step in the service, called by name, with a test of its own. Genuine cross-cutting concerns such as transactions, metrics and tracing remain declarative, as Spring Boot annotations or configuration whose scope the generated report lists method by method. The goal is that a reader of the new service sees every rule that applies to it.