Overview

Our current support for @Order/Ordered uses an absolute number with a default value of "lowest precedence" (i.e. Integer.MAX_VALUE). We also have PriorityOrdered to override such ordering in certain scenarios.

One problem with the current default value is that it is not natural for customizers where you'd want the "default" ones to be at a given order with the ability of custom instance to run before, or after. Such a default must provide a value as there is no way to run "after" with the current default value. A natural value for that is zero with negative values being processed before and positive values being processed after.

A better way to express ordering is to express it relative to another concept. You may need to run/customize/execute before or after another "instance". In Spring Boot, we've essentially implemented that with @AutoConfigureBefore and @AutoConfigureAfter to order auto-configurations.

This issue is to discuss if there is an appetite to provide such constructs in the core framework, with an SPI that would let us order things (potentially being honored in ObjectProvider#orderedStream().

Related Issues

• 34670

Comment From: andersonkyle

This would be particularly nice for servlet filter registration.

Comment From: mjustin

As a user, I can confirm this would be useful. The current approach I have to follow is open the bean, see if there's an order defined, and then order relative to that (hoping that it's not at the max/min in a way that would prevent going before/after it). When there isn't an order defined, I need to pull open @Order.value() to see what the default is (LOWEST_PRECEDENCE) and make sure I order relative to that.

Then I write something like the following, where the reasoning is in the comments, rather than being declarative in the code itself:

@Order(Ordered.LOWEST_PRECEDENCE - 1) // Higher precedence than SomeOtherThing

Comment From: rstoyanchev

Team Decision: this is worth doing to provide sufficient control over ordering. There are some design decisions to be thought through such as relative vs explicit ordering, how to refer to others for relative ordering, etc.

Comment From: spencergibb

We do this in spring cloud gateway with constants, so this would be useful

Comment From: sbrannen

This is also related to:

• 34670

Comment From: YongGoose

Hello @sbrannen @snicoll

I've been following this issue with interest and have put some thought into a potential design that I'd like to share. I'm also very keen to contribute an implementation for this; I'm confident I have the skills and motivation to see it through 🚀

My proposal is to introduce new annotations @OrderBefore and @OrderAfter. (The annotation names may be changed later if more suitable names are found. Therefore, I would appreciate it if you could focus on their roles)

Quick Example

// 1. The component that runs first
@Component
public class DatabaseInitializer {  }

// 3. The component that runs last
@Component
public class BusinessLogic { }

// 2. The component that needs to be inserted in the middle
@Component
@OrderAfter(DatabaseInitializer.class)
@OrderBefore(BusinessLogic.class)
public class MonitoringActivator { }

With these definitions, Spring could build a dependency graph based on the ordering relationships among all the components.

A topological sort could then be performed on this graph to determine the final execution order.

graph TD
    DatabaseInitializer -- then --> MonitoringActivator
    MonitoringActivator -- then --> BusinessLogic

A key advantage of this graph-based approach is its inherent ability to detect cycles. If a developer accidentally creates an impossible ordering (e.g., ComponentA is before ComponentB, and ComponentB is before ComponentA), the circular reference can be detected during context startup, causing it to fail fast—the same logic used for circular dependency detection in DI.

WDYT?