Support Ordered interface for @ControllerAdvice beans

[dicksonleong]

Affects: 5.1.8

---

The ControllerAdvice doc states that:

All such beans are sorted via AnnotationAwareOrderComparator, i.e. based on @Order and Ordered, and applied in that order at runtime.

But when I try to order using the Ordered interface, it is not working, although the @Order annotation is working.

Example below:

@ControllerAdvice
//@Order(1)
class TestAdviceFirst : Ordered {
    override fun getOrder(): Int {
        return 1
    }
    @ExceptionHandler
    @ResponseBody
    fun handleException(e: Exception): String {
        return "Handling exception in TestAdviceFirst"
    }
}

@ControllerAdvice
//@Order(2)
class TestAdvice : Ordered {
    override fun getOrder(): Int {
        return 2
    }
    @ExceptionHandler
    @ResponseBody
    fun handleException(e: Exception): String {
        return "Handling exception in TestAdvice"
    }
}

@RestController
class TestController {
    @GetMapping("/exception")
    fun exception(e: Exception) {
        throw Exception()
    }
}

When @Order is commented out, I get the response "Handling exception in TestAdvice". However when I uncomment @Order, then I get the correct order response: "Handling exception in TestAdviceFirst"

There is also a StackOverflow question but it is unanswered: https://stackoverflow.com/questions/51896436/ordered-interface-is-not-taken-into-account-for-controlleradvice-components

[sbrannen]

After thorough investigation, I have determined that the Ordered interface was never supported for @ControllerAdvice beans.

In conjunction with gh-19993, the Javadoc was incorrectly updated to state that both @Order and Ordered are supported for @ControllerAdvice beans.

I will therefore update the Javadoc to correct that: only @Order is supported for ordering @ControllerAdvice beans.

I will also likely delete or deprecate the unused code paths in ControllerAdviceBean that honor Ordered since that is essentially dead code.

[dicksonleong]

Is it possible to add support to order @ControllerAdvice beans with Ordered interface? Or is there any technical reason this is not supported?

My use case is that I need to order my @ControllerAdvice beans in a configurable manner, so I can't use @Order since it needs the order to be hardcoded.

[sbrannen]

My use case is that I need to order my @ControllerAdvice beans in a configurable manner, so I can't use @Order since it needs the order to be hardcoded.

I understand your desire to be able to do that.

Is it possible to add support to order @ControllerAdvice beans with Ordered interface?

It is technically possible, and I have some ideas regarding how to achieve that, but I am missing a key piece of the puzzle (see below).

Or is there any technical reason this is not supported?

It appears to me that there is in fact a technical reason why it is not currently supported. Namely, each @ControllerAdvice bean is lazily retrieved from the ApplicationContext which means that the ordering cannot be based on Ordered, since the entire set of actual bean instances is not available when the ControllerAdviceBean wrappers are sorted.

The missing piece of the puzzle for me is why that is the case. Specifically, I am not sure why Spring doesn't retrieve all such beans from the ApplicationContext simultaneously -- for example, prior to processing the first request.

I'll discuss the background on this behavior with @rstoyanchev, and we will decide how to proceed.

[sbrannen]

Related Issues and Commits

• Introduction of Ordered support for ControllerAdviceBean created from a bean instance instead of a bean name.
• Documentation changes stating that Ordered is supported for @ControllerAdvice beans; committed in fce8ed6.

[dicksonleong]

Thanks for the explanation! Seems like the original idea is not to initialize the @ControllerAdvice bean when creating and sorting the ControllerAdviceBeans, a wild guess on the reason would be to avoid initialize those beans too early and causing issue when resolving bean dependency?

[sbrannen]

Thanks for the explanation!

You're welcome.

Seems like the original idea is not to initialize the @ControllerAdvice bean when creating and sorting the ControllerAdviceBeans

Yes, that's correct.

a wild guess on the reason would be to avoid initialize those beans too early and causing issue when resolving bean dependency?

Yes, it appears that the intention was to follow the pattern used for looking up handler mappings for controllers which may potentially be defined as prototype beans. However, for a @ControllerAdvice bean we do not think users would define them as prototype beans. Even if a @ControllerAdvice is defined as a prototype bean, it is unlikely that the value returned from getOrder() would change per instantiated prototype. So we think it is safe to change the algorithm in order to support Ordered for @ControllerAdvice beans.

I have updated the title of this issue accordingly.