The spring-starter-logging is included everywhere transitively
now so logback is the default. The actuator sample explicitly
excludes the logging starter so it can have profiles for
different loggers (just as a demo).
[Fixes#53278727]
Extract command line property parsing logic from the
ConfigFileApplicationContextInitializer and instead perform it as part
of the SpringApplication initialization. This allows SpringApplications
that do not use the ConfigFileApplicationContextInitializer to still
expose command line arguments as property sources.
SpringApplicationInitializers may now implement EnvironmentAware if
they need access to the environment during early initialization.
This commit also removes the custom command line parsing logic that
was temporarily added to work around SPR-10579 which has since been
fixed upstream.
* Move Spring.main into SpringApplication.main
* User can bind command line or application.properties into
SpringApplication
* User can provide sources dynamically with --spring.main.sources
(a CSV list of class names, package names or XML resource locations)
* One side effect was to make DocumentMatchers stateless
[#52830829]
Add LoggingSystem class that can be used to configure various logging
systems in a consistent way. Mostly the code is migrated from the
LoggingApplicationContextInitializer.
Add SpringApplicationInitializer that can be used to initialize a
SpringApplication before it runs. An ApplicationContextInitializer
can optionally implement this interface.
If JPA is used and the context is a webapp we add the OEMIV interceptor.
It can be switched off by the user declaring a bean of type OEMSIVI or
the corresponding Filter, or by setting spring.jpa.open_in_view=false.
[Fixes#52939983]
If you add a pom-type dependency with scope=import to the dependency
management section, it pulls in the dependencyManagement section from
the other side. So we can have all the depndency versions fixed in one
place (the root parent).
[#53185049] [bs-225] Rework starter parent pom