-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generalized factory registration #1127
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice.
*/ | ||
static RegisterNamedHttpFilterConfigFactory<BufferFilterConfig> register_; | ||
static Registry::RegisterFactory<BufferFilterConfig, NamedHttpFilterConfigFactory> register_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having just worked on this code, IIRC it's now possible to remove "server/config/network/http_connection_manager.h" from includes and bazel deps. Similarly for network filters IIRC you only need registry.h and filter_config.h and can remove configuration_impl.h/bazel dep. (I actually thought about doing something like this but got lazy, so this is awesome, thanks).
If we agree that we don't want to deprecate the previous Named* factory registration mechanism because of its recent introduction, how should I update the envoy-filter-example repo to allow the CI to pass (I think that's the only failure left)? Should I just make a PR for the other repo, get it committed, and then increment the hash to match in this PR? |
@mrice32 you can look at what I did last time.
It's annoying but doesn't happen very often. |
Automatic merge from submit-queue. [DO NOT MERGE] Auto PR to update dependencies of proxy This PR will be merged automatically once checks are successful. ```release-note none ```
Description: The high-level representation of filter statuses with attached HTTP entities to be forwarded can't be directly represented across the bridge layer and must be mapped. Uniquely, resume iteration statuses may contain pending entities that have not yet been forwarded. This quick fix checks bounds explicitly for these cases in Objective-C. Risk Level: Low Signed-off-by: Mike Schore <[email protected]> Signed-off-by: JP Simard <[email protected]>
Description: The high-level representation of filter statuses with attached HTTP entities to be forwarded can't be directly represented across the bridge layer and must be mapped. Uniquely, resume iteration statuses may contain pending entities that have not yet been forwarded. This quick fix checks bounds explicitly for these cases in Objective-C. Risk Level: Low Signed-off-by: Mike Schore <[email protected]> Signed-off-by: JP Simard <[email protected]>
This generalized registration interface should reduce the burden of introducing new types of implementations that are statically registered and looked up at runtime by name (currently what is used for filters and tracers) and simplify the interface. As mentioned in a previous modification to the filter registration mechanism, it may be possible to get this new interface introduced with no deprecation because the Named* filter factories and the tracer factory that this touches were introduced in this release cycle. #967