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

Use FileSystemStaticHandler for all webjars #23030

Merged
merged 1 commit into from
Jan 24, 2022

Conversation

Postremus
Copy link
Member

The changes in this PR prevent copying all static resources needed for webjars (smallrye-health, swaggerui, graphql), and serves them directly from the jar instead.

I also replaced the extension specific handlers (e.g. SwaggerUiNotFoundHandler, SwaggerUiStaticHandler) with general purpose implementation (WebJarNotFoundHandler, WebJarStaticHandler) in vertx-http.

Same idea as in #22525.

This saves about 30ms of dev mode startup time.
Relates to #21552

@quarkus-bot
Copy link

quarkus-bot bot commented Jan 19, 2022

This workflow status is outdated as a new workflow run has been triggered.

Failing Jobs - Building ae78856

Status Name Step Failures Logs Raw logs
JVM Tests - JDK 11 Build Failures Logs Raw logs
✔️ JVM Tests - JDK 17

Full information is available in the Build summary check run.

Failures

⚙️ JVM Tests - JDK 11 #

- Failing: extensions/smallrye-reactive-messaging-kafka/deployment 
! Skipped: integration-tests/kafka-oauth-keycloak integration-tests/kafka-sasl-elytron integration-tests/kubernetes/quarkus-standard-way-kafka and 2 more

📦 extensions/smallrye-reactive-messaging-kafka/deployment

io.quarkus.smallrye.reactivemessaging.kafka.deployment.testing.KafkaDevServicesContinuousTestingTestCase.testContinuousTestingScenario1 - More details - Source on GitHub

java.lang.RuntimeException: 
java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
	[error]: Build step io.quarkus.kafka.client.deployment.DevServicesKafkaProcessor#startKafkaDevService threw an exception: java.lang.RuntimeException: org.testcontainers.containers.ContainerLaunchException: Container startup failed

Copy link
Member

@gsmet gsmet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me and a nice cleanup.

I just added a small open question.

@@ -136,6 +136,7 @@ public void getSwaggerUiFinalDestination(
byte[] indexHtmlContent = generateIndexHtml(openApiPath, swaggerUiPath, swaggerUiConfig, indexRootPathBuildItem);
webJarBuildProducer.produce(
WebJarBuildItem.builder().artifactKey(SWAGGER_UI_WEBJAR_ARTIFACT_KEY) //
.onlyCopyNonArtifactFiles(true)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this change? Shouldn't it be the default if we generalize it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, it's an open question, you're the one with the most knowledge of this stuff so I'm curious to hear your opinion.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting onlyCopyNonArtifactFiles to default as true, could break quarkiverse members that have already updated to the new webjar infrastructure with 2.7.0.CR1.

I (personally) don't believe a .Final should intentionally break extensions.
WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, if making it the default makes sense, I prefer we do it now rather than after because it will be far more of a pain to change it later.

Now, I don't know if it makes sense to make it the default - I will let you decide what makes more sense on this - but, if it does, let's do it now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, defaulting to true makes sense, and is easy enough to change if one needs to.
Done.

@Postremus
Copy link
Member Author

I fixed the vert.x 4.2.4 deprecations in WebJarStaticHandler, and disallowed rootfilesystemaccess.
This handler only needs to serve from META-INF anyway.

/cc @cescoffier

@quarkus-bot
Copy link

quarkus-bot bot commented Jan 23, 2022

Failing Jobs - Building 4bbaa52

Status Name Step Failures Logs Raw logs
Gradle Tests - JDK 11 Windows Build Failures Logs Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ Gradle Tests - JDK 11 Windows #

- Failing: integration-tests/gradle 

📦 integration-tests/gradle

io.quarkus.gradle.devmode.CustomQuarkusDevModeConfigurationTest.main line 13 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference, java.util.concurrent.atomic.AtomicReferencejava.lang.String, java.lang.Stringboolean was not fulfilled within 1 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:164)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

@Postremus
Copy link
Member Author

Test failures in CustomQuarkusDevModeConfigurationTest do not look related

@gsmet
Copy link
Member

gsmet commented Jan 24, 2022

I'm testing this locally and will merge if things are OK.

@gsmet gsmet merged commit d464b14 into quarkusio:main Jan 24, 2022
@quarkus-bot quarkus-bot bot added this to the 2.8 - main milestone Jan 24, 2022
@gsmet
Copy link
Member

gsmet commented Jan 24, 2022

Thanks @Postremus , very nice work!

@gsmet gsmet modified the milestones: 2.8 - main, 2.7.0.Final Jan 24, 2022
@Postremus Postremus deleted the webjar-serve-as-jar branch January 24, 2022 18:34
return new SmallRyeGraphQLStaticHandler(graphqlUiFinalDestination, graphqlUiPath);
WebJarStaticHandler handler = new WebJarStaticHandler(graphqlUiFinalDestination, graphqlUiPath,
webRootConfigurations);
shutdownContext.addShutdownTask(new ShutdownContext.CloseRunnable(handler));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mkouba @cescoffier I was going back to this patch and was wondering why we needed to do that? Shouldn't the handler be closed by Vert.x itself?

Copy link
Member Author

@Postremus Postremus Jan 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/quarkusio/quarkus/blob/main/extensions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/runtime/devmode/FileSystemStaticHandler.java#L166

This is the handler in question which should be closed.
At first, I also hopped that a instance of Closeable is automaticly closed.
I set a breakpoint in the close method. Never got invoked though.

This is why I decided to add the shutdownhandlers.

Is there any better / automatic way with Vert.x?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah OK, I missed you specifically implemented Closeable. Maybe @mkouba will have some ideas about how we could improve it and close Closeable handlers automatically.
If not, that's not a biggy.

I was going through this patch again to move Quarkus GitHub App to this new pattern.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants