Introduce a formal ExtensionPoint class to stream line extensions #12826
Conversation
|
One thought here is to split ExtensionPoint into two different variants, one for a Set and one for a Map. Right now it looks like we have a switch for this, with if/else in the impl. We just have those two types of extension points, either we keep a set of class impls, or we keep a map from name to impl. I think separating them would make the module code a little clearer, and less error prone when adding these (must choose the type of extension when defining, instead of accidentally calling the wrong register method). |
| @@ -116,7 +116,7 @@ protected void configure() { | |||
|
|
|||
| // bind ShardsAllocator | |||
| final String shardsAllocatorType = settings.get(AllocationModule.SHARDS_ALLOCATOR_TYPE_KEY, AllocationModule.BALANCED_ALLOCATOR); | |||
| final Class<? extends ShardsAllocator> shardsAllocator = shardsAllocators.get(shardsAllocatorType); | |||
| final Class<? extends ShardsAllocator> shardsAllocator = shardsAllocators.getExtension(shardsAllocatorType); | |||
There was a problem hiding this comment.
I wonder if we could also factor out the lookup in settings and selection of the class? So we could have a bind method like below, but which takes the binder, Settings and the setting name? In this case, we can just have a lone if to check for the type and log the deprecation message (a little more work here, but a very unusual case)?
|
This looks great in general, I think it will simplify a lot where we have extension points, so we get the same logic/exception checking. I left a few comments/questions. |
| } | ||
|
|
||
|
|
||
| public static class MapExtensionPoint<T> extends ExtensionPoint<T> { |
There was a problem hiding this comment.
Personally I would do these as two separate classes. Then the ctor here can take a map of builtins instead of set of names (which relies on registering those names independently)?
|
LGTM. I left two more questions but those can be follow ups or ignored. |
s1monw
force-pushed
the
add_extension_point
branch
from
80bdfb4
to
f26a4bb
Compare
This commit tries to add some infrastructure to streamline how extension points should be strucutred. It's a simple approache with 4 implementations for `highlighter`, `suggester`, `allocation_decider` and `shards_allocator`. It simplifies adding new extension points and forces to register classes instead of strings.
s1monw
force-pushed
the
add_extension_point
branch
from
f26a4bb
to
74f18d8
Compare
| * all extensions by a single name and ensures that extensions are not registered | ||
| * more than once. | ||
| */ | ||
| public abstract class ExtensionPoint<T> { |
There was a problem hiding this comment.
I like these as they wrap guice ceremony.
This commit tries to add some infrastructure to streamline how extension
points should be strucutred. It's a simple approache with 4 implementations
for
highlighter,suggester,allocation_deciderandshards_allocator.It simplifies adding new extension points and forces to register classes instead
of strings.