Skip to content
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

[Feature/extensions] getNamedXContent - Add support for extensions #3379

Closed
Tracked by #3136
saratvemulapalli opened this issue May 18, 2022 · 2 comments
Closed
Tracked by #3136

Comments

@saratvemulapalli
Copy link
Member

saratvemulapalli commented May 18, 2022

Add extension framework support for getNamedXContent extension point.

@saratvemulapalli saratvemulapalli changed the title getNamedXContent - Custom parsers the plugin would use for NamedObjects. [Feature/extensions] getNamedXContent - Custom parsers the plugin would use for NamedObjects. May 18, 2022
@saratvemulapalli saratvemulapalli changed the title [Feature/extensions] getNamedXContent - Custom parsers the plugin would use for NamedObjects. [Feature/extensions] getNamedXContent - Add support for extensions May 18, 2022
@joshpalis
Copy link
Member

Design for default extension point support for getNamedXContent.

Extension Point Purpose :

  • When plugins override getNamedXContent() with their own implementation, they are able to register custom parsers for NamedObjects within the NamedXContentRegistry. XContent Registry entries consist of a category class and object name that is mapped to a reader that provides the ability to deserialize a provided context into the corresponding object.

Previous workflow:

  • Traditionally installed plugins override the getNamedXContentRegistry() extension point and return a collection of XContentRegistry.Entry's
  • During OpenSearch bootstrap within Node.java, XContent Registries from various modules (ie: search, index, network, cluster) and all plugins are consolidated into a central XContentRegistry that is then passed as an argument to multiple services.

Extensibility workflow:

  • Within Node.java, after all installed plugin xcontent registries are collected, extensions orchestrator will send out requests to all extensions that have been previously discovered for any entries they want to register
  • Upon receiving the request, the independent plugins would return a response consisting of all the entries that it wants to register, however, instead of providing the custom parser within the entry, the reader will be replaced with a callback method to send a request from opensearch to the extension for object deserialization
  • The work done to handle object deserialization will be done by the extension in order to maintain the separation of concerns between it and OpenSearch. In the case that the extension goes down, the entries corresponding to the extension must then be deregistered from the XContentRegistry
  • Once all xcontent registries from the extensions have been collected, the registry will then be passed onto various services that are created during bootstrap

@minalsha
Copy link
Contributor

minalsha commented Nov 8, 2022

Closing this issue as it is being tracked in the work being done on opensearch-project/opensearch-sdk-java#208

@minalsha minalsha closed this as completed Nov 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants