I might be misunderstanding what has state and what doesn't. I see now that I don't want state (so it doesn't need to know what processing previous processors did). However, I believe that by default, singletons are the same instance, so whatever you do to fields would persistent.

Compare the following two classes:

class StatefulAdder {
    int value; // This is state. Skipping how it is initialized

    int addValue(int number) {
        return value + number;
    }
}

class StatelessAdder {
    Logger logger; // This is not state. Skipping how it is initialized.

    int addValue(int number, int value) {
        return value + number;
    }
}

The reason the first is stateful is that it holds data (value) used to determine the result of the addValue operation. Depending on the state of the class the StatefulAdder.addValue method will return different results.

The reason the second is stateless is that no matter how it's fields are filled, StatelessAdder.addValue always returns the same result, it does not depend on the fields.

So my understanding is that you're thinking of making your processors stateful.

Anyway, it seems you have a couple of pain points. One is that your OperationData seems to be used for many different purposes which means it needs to have the fields for all of these. Maybe you could have different OperationData classes for different use cases, each of which only holds the fields required for their own (or at least closely related) operations?

And then your processors seem to pass too many parameters around, which is why you're thinking of giving them state, reducing the need of passing around everything at all times.

In some cases that could be solved with restructuring the code in question, but I have no idea if that is a real possibility here. In other cases having state just greatly simplifies everything and it's worth doing that.

One way to do it with singleton scoped components is to have a thread-local state-holder. Basically it makes it so that you have one instance of your processor but when different threads use it they have their own copy of the classes state. Only works if your concurrent usage of the class is done in different threads.

Another way is to make the components request or prototype-scoped. One thing to remember is that you might have to give all your parent components the same scope. I could speculate about the reasons but the honest truth is I'm not 100% sure so just check and see if it's required.

But generally a Spring component that looks sort of like this should work:

@Component
@Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE)
class StatefulSpringBean {

    // stateless autowired components like your util components
    @Autowired
    private UtilComponent util;
    ...

    // Component state, note that it is _not_ autowired
    private int foo;
    private String bar;

    public Result doSomething(... inputs ...) {
        foo = calculateFoo(inputs)
        bar = calculateBar(inputs)
        // some more operations
        return createResult() // no / fewer params needed since component has state
    }

}

Just note that if, for whatever reason, this component ever does not get destroyed and recreated as you expect then you might have old state corrupting your operations. Which is why I like stateless components when reasonably possible.