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.

Sign up for GitHub

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

Jump to bottom

Qute - improve content type detection #11050

Merged
merged 1 commit into from
Jul 30, 2020
Merged

Qute - improve content type detection #11050

merged 1 commit into from
Jul 30, 2020

Conversation

mkouba
Copy link
Contributor

@mkouba mkouba commented Jul 29, 2020

@mkouba
Qute - improve content type detection
8dabad1 
- add config property for additional mappings
- resolves quarkusio#10991
@mkouba mkouba added this to the 1.7.0 - master milestone Jul 29, 2020
@mkouba mkouba requested a review from gastaldi July 29, 2020 06:31
@mkouba
Copy link
Contributor Author

mkouba commented Jul 29, 2020

@gastaldi you would add quarkus.qute.content-types.graphql=application/graphql to get rid of the warning, plus you should also specify quarkus.qute.suffixes=qute.html,qute.txt,html,txt,graphql to get full support ;-)

@gsmet
Copy link
Member

gsmet commented Jul 29, 2020

Looks like a nice addition for 1.7. @gastaldi I let you review it?

gastaldi
gastaldi approved these changes Jul 29, 2020
View reviewed changes
Copy link
Contributor

@gastaldi gastaldi left a comment

Choose a reason for hiding this comment

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

Excellent! Added one minor optional comment

extensions/qute/runtime/src/main/java/io/quarkus/qute/runtime/ContentTypes.java
if (suffix.equalsIgnoreCase("json")) {
return Variant.APPLICATION_JSON;
}
String contentType = URLConnection.getFileNameMap().getContentTypeFor(fileName);
Copy link
Contributor

Choose a reason for hiding this comment

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

We could use Files.probeContentType too (or instead?) to take advantage of libraries that register their own java.nio.file.spi.FileTypeDetector through the ServiceLoader mechanism

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was thinking about Files.probeContentType() too but given the fact that the result may differ, based on the OS or presence of other libraries, I decided to choose the simple and straightforward solution for now. Also it seems that the default FileTypeDetector impl is makes use of URLConnection.getFileNameMap() anyway...

@gsmet
Copy link
Member

gsmet commented Jul 30, 2020

Merging this one. We can still improve on @gastaldi 's suggestion later.

@gsmet gsmet merged commit 479957d into quarkusio:master Jul 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@gastaldi gastaldi gastaldi approved these changes

Assignees
No one assigned
Labels
area/qute The template engine area/resteasy-classic
Projects
None yet
Milestone
1.7.0.CR1
Development

Successfully merging this pull request may close these issues.

Qute: Unknown media type for suffix: .graphql
3 participants
@mkouba @gsmet @gastaldi