@ControllerAdvice(basePackageClasses) do the prefix search by package name. [SPR-12509]

[spring-projects-issues]

Kazuki Shimizu opened SPR-12509 and commented

When use the @ControllerAdvice(basePackageClasses), it has been applied to the other base package's Controller.

e.g)

package io.github.kazuki43zoo.app;

import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ModelAttribute;


@ControllerAdvice(basePackageClasses = io.github.kazuki43zoo.app.AppControllerAdvice.class)
public class AppControllerAdvice {

    @ModelAttribute("appCommonMessage")
    public String commonMessage() {
        System.out.println("AppControllerAdvice#appCommonMessage() called.");
        return "Hello in AppControllerAdvice.";
    }

}

Above @ModelAttribute method has been applied to the Controller under io.github.kazuki43zoo.app and io.github.kazuki43zoo.app1 package.

I think that should not be applied to the Controller under io.github.kazuki43zoo.app1 package.

p.s)
basePackages and value attribute is similar behavior.

---

Affects: 4.1.2

Reference URL: https://github.com/kazuki43zoo/spring-controller-advice

Issue Links:

• Base packages referenced from @ControllerAdvice must contain at least one Controller [SPR-12506] #17111 Base packages referenced from @ControllerAdvice must contain at least one Controller
• When specified the Non-existent package using @ControllerAdvice(basePackages), has been applied to all controllers. [SPR-12510] #17115 When specified the Non-existent package using @ControllerAdvice(basePackages), has been applied to all controllers.

Referenced from: commits d1f8968

[spring-projects-issues]

Juergen Hoeller commented

Brought in line with regular component scanning behavior through a base package comparison including a package separator, strictly checking specified base package and sub-packages thereof (as originally intended).

Some applications may accidentally rely on matches with other packages which start with the same prefix. For this reason, we're only fixing this in 4.1.3 and not in 4.0.9. Anyone affected in 4.1.3 should simply specify the other packages explicitly and not rely on unintended prefix matches; for 4.0.9, we'd like to not disrupt at all and therefore avoid this minor hassle.

Juergen

[spring-projects-issues]

Kazuki Shimizu commented

Hi Juergen !

Thank you for resolve !!
It worked using the 4.1.3.BUILD-SNAPSHOT in my application :)