Provide property to indicate the index page for static resources

[brunolmfg]

Description

Providing a configuration property to indicate the index page for static resources will allow use a different filename. This is only possible with undertow extension using the welcome-file-list entry on web.xml. The vertx-http extension could provide an option like this:

quarkus.http.index-page=/default.html

Implementation ideas

The static resources are provided by VertX Web using StaticHandler that only accept one filename definition. So the new config property will define the indexPage attribute of the created StaticHandler for the static resources in src/main/resources/META-INF/resources.

Will need to change the StaticResourcesProcessor and StaticResourcesRecorder to consider the indexPage property at HttpBuildTimeConfig.

[geoand]

@brunolmfg would you be willing to contribute this feature?

[brunolmfg]

@brunolmfg would you be willing to contribute this feature?

@geoand I've took a look and some considerations came out. Maybe it's better to create a static-resources configuration group exposing other properties of StaticHandler. Bellow the proposed properties to be exposed and its default values defined in StaticHandler.

quarkus.http.static-resources.index-page=index.html
quarkus.http.static-resources.max-age=24H
quarkus.http.static-resources.max-cache-size=10000
quarkus.http.static-resources.cache-entry-timeout=30S
quarkus.http.static-resources.include-hidden=false

The property quarkus.http.static-resources.index-page require to be a build time configuration because StaticResourcesProcessor registers the paths containing an index page. An alternative would be moving the verification to StaticResourcesRecorder.

I've also observed that an internal StaticResourcesBuildItem is used in StaticResourcesProcessor but a cloned new class was created in #23280 as a SPI, deprecating the former since 2.8.0.CR1. Would be ok remove it?

[geoand]

Maybe it's better to create a static-resources configuration group exposing other properties of StaticHandler

Sounds reasonable.

Would be ok remove it?

I would need to look at the code, but off the tope of my head, I think it makes sense to remove it