-
Notifications
You must be signed in to change notification settings - Fork 137
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
Remove WebApplicationType from application API #269
Comments
This was referenced May 14, 2020
sdeleuze
added a commit
to sdeleuze/spring-native
that referenced
this issue
May 15, 2020
This commit introduces various optimizations that allow to significantly reduce Spring Boot applications footprint when compiled as native images. The first one is the capability to remove XML parsers (see related oracle/graal#2327 GraalVM issue) including those configured habitually by Spring. XML Parsers from Logback, Tomcat, Spring Boot, Spring Framework Core/WebMvc/WebFlux can be disabled via -Dspring.graal.remove-xml-support=true and is implemented via various substitutions. Notice for now FormHttpMessageConverter is used instead of AllEncompassingFormHttpMessageConverter due to oracle/graal#2458. It is now also possible to remove SpEL via -Dspring.graal.remove-spel-support=true and JMX via -Dspring.graal.remove-jmx-support=true. BackgroundPreinitializer are now disabled since they do not make sense with GraalVM native. spring-graal-feature is now added as a regular Maven dependency in order to make the new org.springframework.boot.NativePropertiesListener taken in account when the agent is used. Key samples and petclinic ones have been updated to take advantage of those optimizations. Spring Fu samples now also takes advantages of spring-projects-experimental/spring-fu#269 and those capabilities. In the long run, these "not so easy to maintain substitutions" could maybe be replaced by a new GraalVM capability that would monitor used classes by the JVM via an agent and pass this list to native-image compiler to remove those unused classes from the native image in order to load classes lazily like the JVM does. It would also have the advantage to not require an explicit option to enable those optimizations. Closes spring-atticgh-109
dsyer
pushed a commit
to scratches/spring-graalvm-native
that referenced
this issue
Sep 23, 2020
This commit introduces various optimizations that allow to significantly reduce Spring Boot applications footprint when compiled as native images. The first one is the capability to remove XML parsers (see related oracle/graal#2327 GraalVM issue) including those configured habitually by Spring. XML Parsers from Logback, Tomcat, Spring Boot, Spring Framework Core/WebMvc/WebFlux can be disabled via -Dspring.graal.remove-xml-support=true and is implemented via various substitutions. Notice for now FormHttpMessageConverter is used instead of AllEncompassingFormHttpMessageConverter due to oracle/graal#2458. It is now also possible to remove SpEL via -Dspring.graal.remove-spel-support=true and JMX via -Dspring.graal.remove-jmx-support=true. BackgroundPreinitializer are now disabled since they do not make sense with GraalVM native. spring-graal-feature is now added as a regular Maven dependency in order to make the new org.springframework.boot.NativePropertiesListener taken in account when the agent is used. Key samples and petclinic ones have been updated to take advantage of those optimizations. Spring Fu samples now also takes advantages of spring-projects-experimental/spring-fu#269 and those capabilities. In the long run, these "not so easy to maintain substitutions" could maybe be replaced by a new GraalVM capability that would monitor used classes by the JVM via an agent and pass this list to native-image compiler to remove those unused classes from the native image in order to load classes lazily like the JVM does. It would also have the advantage to not require an explicit option to enable those optimizations. Closes spring-atticgh-109
dsyer
pushed a commit
to scratches/spring-graalvm-native
that referenced
this issue
Sep 23, 2020
This commit introduces various optimizations that allow to significantly reduce Spring Boot applications footprint when compiled as native images. The first one is the capability to remove XML parsers (see related oracle/graal#2327 GraalVM issue) including those configured habitually by Spring. XML Parsers from Logback, Tomcat, Spring Boot, Spring Framework Core/WebMvc/WebFlux can be disabled via -Dspring.graal.remove-xml-support=true and is implemented via various substitutions. Notice for now FormHttpMessageConverter is used instead of AllEncompassingFormHttpMessageConverter due to oracle/graal#2458. It is now also possible to remove SpEL via -Dspring.graal.remove-spel-support=true and JMX via -Dspring.graal.remove-jmx-support=true. BackgroundPreinitializer are now disabled since they do not make sense with GraalVM native. spring-graal-feature is now added as a regular Maven dependency in order to make the new org.springframework.boot.NativePropertiesListener taken in account when the agent is used. Key samples and petclinic ones have been updated to take advantage of those optimizations. Spring Fu samples now also takes advantages of spring-projects-experimental/spring-fu#269 and those capabilities. In the long run, these "not so easy to maintain substitutions" could maybe be replaced by a new GraalVM capability that would monitor used classes by the JVM via an agent and pass this list to native-image compiler to remove those unused classes from the native image in order to load classes lazily like the JVM does. It would also have the advantage to not require an explicit option to enable those optimizations. Closes spring-atticgh-109
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue is about changing:
application(WebApplicationType.NONE, ...)
toapplication(...)
application(WebApplicationType.SERVLET, ...)
towebApplication(...)
application(WebApplicationType.REACTIVE, ...)
toreactiveWebApplication(...)
This change was proposed by @poutsma since
WebApplicationType
usage is probably not optimal for such commonly used API, especially theWebApplicationType.NONE
variant.Another reason for such change is to improve GraalVM native support since that allows to use
new FooApplicationContext()
instead of using reflection, which leads to smaller native images and less reflection configuration.The text was updated successfully, but these errors were encountered: