Problem
Currently, adding a new filter requires changes in multiple places:
Adding a new field to AppConfig
Updating defaults() and withDefaultsApplied()
Modifying ConnectionHandler.buildFilters() to instantiate the filter
As more filters are introduced, AppConfig and the filter wiring logic grow linearly. This increases the risk of merge conflicts and makes it easy to miss required changes when introducing new filters.
Proposed Improvement
Introduce a more flexible filter configuration and registration mechanism, for example:
A generic filters: section in the configuration file (list-based)
A centralized FilterPipelineFactory responsible for building the filter chain
Optionally, a simple filter registry/factory pattern to map configuration entries to filter implementations
This would allow:
Adding new filters without modifying AppConfig
Avoiding repeated changes in ConnectionHandler
Making filter ordering and enabling/disabling more configuration-driven
Problem
Currently, adding a new filter requires changes in multiple places:
Adding a new field to AppConfig
Updating defaults() and withDefaultsApplied()
Modifying ConnectionHandler.buildFilters() to instantiate the filter
As more filters are introduced, AppConfig and the filter wiring logic grow linearly. This increases the risk of merge conflicts and makes it easy to miss required changes when introducing new filters.
Proposed Improvement
Introduce a more flexible filter configuration and registration mechanism, for example:
A generic filters: section in the configuration file (list-based)
A centralized FilterPipelineFactory responsible for building the filter chain
Optionally, a simple filter registry/factory pattern to map configuration entries to filter implementations
This would allow:
Adding new filters without modifying AppConfig
Avoiding repeated changes in ConnectionHandler
Making filter ordering and enabling/disabling more configuration-driven