There's a bit of a problem here. A builder as it is presented here, is a stateful construct, meaning, you use a builder to build a "configured" instance of a processor. But the passed in registry should not be stateful... effectively, the builders in the passed in registry should act as "factories".

either separate the two notions (builder & factory) or have the registry hold "prototype" builders and then change the void fromMap(Map) to Processor build(Map). Personally I like the separation of the constructs - builds clear API with clear roles and responsibility for each class. But core moved more towards the "prototype" direction, so perhaps a prototype here will be more aligned with core.

If we move to prototypes than that means that we a processor can only built with a map of maps. I though that also the idea was to have a real builder that has setters for its properties. So maybe we should then take the builder & factory direction?

well.. as I said, IMO the separation is cleaner. But if you keep the prototype way, you'll eventually need to keep the current build() method and introduce a new Processor build(Map) method next to it... it's a bit messy tbh... the same applies to the Pipeline.Builder.

Another option is leave things as they are (so leave the current void fromMap(Map) method) and then introduce a factory to a builder... however you look at it, we need a factory somewhere... a construct that is registered by "type" that can create the appropriate builder/processor for that type... something along the lines of:

Processor.Builder builder = registry.get("type").create();

Another option is to mandate all builders to have an empty ctor and use reflection to create those. So instead of injecting a set of builders, you'd work with a set of builder classes and then the code will just create new instances using reflection on default ctor.

@uboness makes sense, I added the factory for the processor builders, so the registry passed to the processor builder doesn't hold state any more.