-
Notifications
You must be signed in to change notification settings - Fork 332
Quarkus-based Polaris service runtime #469
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
Conversation
f714c40 to
dcf8ccd
Compare
2f18194 to
adfbbc2
Compare
4ac2974 to
5cc6fec
Compare
fe8b9dc to
9fd4ce3
Compare
a4e8638 to
ea66fd4
Compare
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.
Noted! Change LGTM!
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: Do you think it should be @QuarkusIntegrationTest in the spirit of backbox tests?
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.
Yes, but later: we don't have an intTest configuration in polaris yet :-)
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.
Just add this to your build.gradle.kts (after #714)
testing {
suites {
val intTest by registering(JvmTestSuite::class)
}
}
tasks.named("check") { dependsOn(testing.suites.named("intTest")) }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, let's do it in a follow-up PR after the renamings etc.
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.
no rush :)
When editing `.gitignore`, IntelliJ warns about a couple directories being ignored but not excluded from being indexed and searched. This change ignores the mentioned directories, except the one for DW, which is going away with apache#469.
Having documentation about the configuration that is both "up-to-date" and "in-sync with the source code" with the actual code is good practice. The functionality added in this change allows generating markdown docs from smallrye-config based configuration types, starting at and grouped by types that are annotated with `@ConfigMapping`. The javadoc of the config interfaces and properties is emitted as markdown. On top there is functionality to generate reference docs for "static" types (currently unused in Polaris). The code is nearly a 1:1 port of the same functionality in Nessie. This change will become useful with/after apache#469. Gradle projects added in this change are: * `polaris-config-doc-annotations` adds an annotation used when generating docs to influence the generation of the configuration reference docs. * `polaris-config-doc-generator` is the reference doc generator implementation, as a "standalone" tool that uses javadoc _infrastructure_. See `ReferenceConfigDocsGenerator` why it needs to be a separate tool than "just" a doclet (class loader isolation issues). * `polaris-site-reference-docs` actually generates the markdown files from referenced Gradle projects. Currently there are no projects referenced, so generation yields nothing. The generated docs are not yet integrated into the website, which will happen in a follow-up PR.
Having documentation about the configuration that is both "up-to-date" and "in-sync with the source code" with the actual code is good practice. The functionality added in this change allows generating markdown docs from smallrye-config based configuration types, starting at and grouped by types that are annotated with `@ConfigMapping`. The javadoc of the config interfaces and properties is emitted as markdown. On top there is functionality to generate reference docs for "static" types (currently unused in Polaris). The code is nearly a 1:1 port of the same functionality in Nessie. This change will become useful with/after #469. Gradle projects added in this change are: * `polaris-config-doc-annotations` adds an annotation used when generating docs to influence the generation of the configuration reference docs. * `polaris-config-doc-generator` is the reference doc generator implementation, as a "standalone" tool that uses javadoc _infrastructure_. See `ReferenceConfigDocsGenerator` why it needs to be a separate tool than "just" a doclet (class loader isolation issues). * `polaris-site-reference-docs` actually generates the markdown files from referenced Gradle projects. Currently there are no projects referenced, so generation yields nothing. The generated docs are not yet integrated into the website, which will happen in a follow-up PR.
ea66fd4 to
c4e6ff0
Compare
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: there are new comments in the caller, could we also add comments here to explain why we need cloned objects realmContext and polarisCallContext.
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.
@flyrain this will soon disappear with #589 so I don't think there is need to explain.
But just for posterity, the reason is realted to TaskExecutor: these beans are request-scoped, and they would become unusable when the original request that created them completes, but the task hasn't finished executing yet.
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.
Question: are we going to use DI for the class PolarisAdminService later as well?
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.
Probably. There is a huge overlap between PolarisServiceImpl (which is a request-scoped CDI bean) and PolarisAdminService, which is just a regular Pojo.
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 suggest postponing this change until we've fixed line 101.
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.
Let's keep this PR as it is - there is already #463 to get rid of the problematic TLs
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 suggest postponing this change until we've fixed the line 101.
service/common/build.gradle.kts
Outdated
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.
Considering this is a service-common module, do we need these libs in runtime classpaths?
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 will take a note to check if these would work with compileOnly.
dropwizard/service/README-quarkus.md
Outdated
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.
Can we improve the documentation to provide clearer and more detailed descriptions like the following:
Quarkus aggregates configuration properties from multiple sources, applying them in a specific order of precedence. When a property is defined in multiple sources, the value from the source with the higher priority overrides those from lower-priority sources. This behavior replaces the old configuration file format, such as polaris-server.yml.
The sources are listed below, from highest to lowest priority:
- System properties: Properties set via the Java command line using
-Dproperty.name=value. - Environment variables in
.envfile of the current working directory. - Settings in
$PWD/config/application.propertiesfile - The application configuration file packaged as part of the lib
polaris-quarkus-service. - Default values: Hardcoded defaults within the application.
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.
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.
Incorporated the above changes in #700. FYI.
dropwizard/service/README-quarkus.md
Outdated
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 believe this potentially breaks existing deployment as the endpoint url has changed, like this example shows:
"http://localhost:8182/healthcheck" --> "http://localhost:8182/q/health"
I'd recommend to keep the existing health check in this PR. Deprecated it later if needed. cc @dennishuo @collado-mike @eric-maynard
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.
@flyrain if you really have an existing deployment and need the old endpoint, then you can add it to your build (as a system integrator you likely have your own build).
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 don't think this is a reasonable response to proposed breaking changes. This is a bit like saying "if you have your own fork, you can patch it". It is a reasonable use case that someone would check out the Polaris repo, package it up in a Docker build and deploy it to their K8s application and use the provided health checker endpoint to monitor it. We wouldn't remove one of the management APIs out from under users and tell them to just fix it in their own build. I don't think the health checker or the metrics APIs ought to be treated any differently
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.
We did not remove the health check endpoint nor the metrics endpoint.
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.
@collado-mike : Does #782 help?
When editing `.gitignore`, IntelliJ warns about a couple directories being ignored but not excluded from being indexed and searched. This change ignores the mentioned directories, except the one for DW, which is going away with #469.
c4e6ff0 to
e15f55a
Compare
| swagger = "1.6.14" | ||
|
|
||
| [bundles] | ||
| junit-testing = ["assertj-core", "mockito-core", "mockito-junit-jupiter", "junit-jupiter-api", "junit-jupiter-params", "junit-platform-reporting"] |
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'll do a follow-up to adopt it to what #714 introduced
Fixes #392.
Read the
README_quarkus.mdfile for more details on what changes, how, and what remains to be done.