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
Allow the Launcher to detect ans run exploded (unpacked) jar/war files.
This change is primarily driven by the fact that Cloud Foundry will
unpack uploaded files.
Issue: #53066255
Dave Syer
Phillip Webb
Dave Syer
Scott Frederick