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

Provide a flag to disable XML support #25151

Closed
sdeleuze opened this issue May 28, 2020 · 3 comments
Closed

Provide a flag to disable XML support #25151

sdeleuze opened this issue May 28, 2020 · 3 comments
Assignees
Labels
type: enhancement A general enhancement
Milestone

Comments

@sdeleuze
Copy link
Contributor

sdeleuze commented May 28, 2020

Unlike other converters/codecs which can be enabled selectively based on classpath detection, XML ones are enabled by default in Spring MVC and WebFlux, but are also reachable in other places like properties loading facilities.

In order to improve effiency on both JVM and GraalVM native images for users not using XML (more common these days since JSON and Yaml are widely used), this issue plan to introduce a spring.xml.ignore flag in order to disable XML support in a way that allows GraalVM native images to remove that code at build time.

Usage of XML support with the flag enabled should trigger a proper exception with a message explaining how to re-enable it.

For the record this allows to reduce native image size by 8.4M, RSS memory consumption by 4.2M and build time by 7s with Java 8.

The work done on spring-graalvm-native substitutions has allows to identify a first set of classes where XML support should be removed:

  • org.springframework.util.DefaultPropertiesPersister
  • org.springframework.core.io.support.PropertiesLoaderUtils
  • org.springframework.web.servlet.function.support.RouterFunctionMapping
  • org.springframework.web.client.RestTemplate
  • org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver
  • org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport
  • org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter
  • org.springframework.http.converter.support.AllEncompassingFormHttpMessageConverter
  • org.springframework.http.codec.support.BaseDefaultCodecs

There are potential other places where we should seek where those XML related classes (used by GraalVM native to trigger XML support):

  • javax.xml.bind.Binder
  • javax.xml.datatype.DatatypeFactory
  • javax.xml.parsers.DocumentBuilderFactory
  • javax.xml.parsers.SAXParserFactory
  • javax.xml.stream.FactoryFinder
  • javax.xml.transform.FactoryFinder
  • org.w3c.dom.bootstrap.DOMImplementationRegistryClasses

Such flag could also be used on Spring Boot side:

  • In org.springframework.boot.BeanDefinitionLoader to remove usage of XmlBeanDefinitionReader
  • In org.springframework.boot.logging.logback.LogbackLoggingSystem to remove XML support from Logback configuration.
@sdeleuze sdeleuze added the type: enhancement A general enhancement label May 28, 2020
@sdeleuze sdeleuze added this to the 5.3 M1 milestone May 28, 2020
@sdeleuze sdeleuze self-assigned this May 28, 2020
kenny5he pushed a commit to kenny5he/spring-framework that referenced this issue Jun 21, 2020
This commit introduces a spring.xml.ignore system property
which when set to true avoid initializing XML infrastructure.

A typical use case is optimizing GraalVM native image footprint
for applications not using XML. In order to be effective, those
classes should be initialized at build time:

- org.springframework.util.DefaultPropertiesPersister
- org.springframework.core.io.support.PropertiesLoaderUtils
- org.springframework.web.servlet.function.support.RouterFunctionMapping
- org.springframework.web.client.RestTemplate
- org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver
- org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport
- org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter
- org.springframework.http.converter.support.AllEncompassingFormHttpMessageConverter
- org.springframework.http.codec.support.BaseDefaultCodecs
- org.springframework.beans.PropertyEditorRegistrySupport

Closes spring-projectsgh-25151
wilkinsona pushed a commit to spring-projects/spring-boot that referenced this issue Jun 25, 2020
This commit allows to set the XmlBeanDefinitionReader field from
BeanDefinitionLoader to null in a way that allows the GraalVM native
compiler to remove it from the native image when the spring.xml.ignore
flag introduced by spring-projects/spring-framework#25151
is set to true.

The purpose of this change is to allow smaller footprint on native
images without requiring to use GraalVM native substitutions
which are unmaintainable by nature and also to increase the consistency
between JVM and native images.

In order to effective, this optimization requires BeanDefinitionLoader
class to be initialized at build time.

See gh-22093
@mnhock
Copy link
Contributor

mnhock commented Nov 19, 2020

Through this change we get an NPE in our JUnit 5 Test using the RestTemplate, because there are no properties loaded and no spring application properties should be loaded as well.

The problem is this change:

private static final boolean shouldIgnoreXml = SpringProperties.getFlag("spring.xml.ignore");

Exception:

java.lang.ExceptionInInitializerError
        at com.xxx.xxx.RestConfigurationTest.testCompilerRestTemplate(RestConfigurationTest.java:14)
Caused by: java.lang.NullPointerException: Cannot invoke "java.util.Properties.getProperty(String)" because "org.springframework.core.SpringProperties.localProperties" is null

@sbrannen
Copy link
Member

@mnhock, since this issue was closed several months ago, can you please open a new issue describing the regression you are experiencing? Also, can you please provide a sample application that reproduces the problem?

Thanks in advance

@mnhock
Copy link
Contributor

mnhock commented Nov 19, 2020

Hello @sbrannen!

Here you can found the issue #26120

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants