-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
Allow qualified exports to extended modules #95243
Conversation
In elastic#94884 the ability to add qualified exports and opens from jars upstream of server was added. Some Elasticsearch components need to qualify their exports to another component. This commit tweaks the loading of the exports services so that each loaded module has the chance to also load an exports service. It also does so for exporting of the license package for serverless.
Pinging @elastic/es-core-infra (Team:Core/Infra) |
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.
I think I understand the change here (LGTM), but probably not enough so to approve the PR.
Thanks again for fixing this ! I tested locally and and works great.
@@ -213,5 +213,6 @@ | |||
exports org.elasticsearch.xpack.core.watcher.watch; | |||
exports org.elasticsearch.xpack.core.watcher; | |||
|
|||
opens org.elasticsearch.license.internal; // spi | |||
// opens org.elasticsearch.license.internal to org.elasticsearch.server; // spi |
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.
nit: delete the commented out opens
@elasticsearchmachine run elasticsearch-ci/part-2 |
I think this PR is fine as is, but there is an alternative... In 94884, it was necessary for the libs to provide some way of modifying their exports/opens available - this was done explicitly through a service. Since the libs module is loaded in the boot layer (along with the jdk modules, server, etc), it is not possible for server to modify it's module exports directly - there is no access to a module layer controller for the boot layer. For qualified exports/opens between ES plugin modules, then we could use the module layer controller to reify the qualified exports automagically, without the need for each plugin module to implement the exports service. We can do this since it is our server that creates the module layers for the plugin modules (where as for libs, it is the JDK that creates the boot layer). |
Thanks Chris! I applied your idea in 8b44d57, let me know what you think. |
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.
I think that this looks good. And is a great improvement as qualified exports/opens between ES modules not in the boot layer will just work automatically. 👍
In #94884 the ability to add qualified exports and opens from jars upstream of server was added. Some Elasticsearch components need to qualify their exports to another component. This commit tweaks the exports handling in PluginsService to also handle plugins with exports/opens.