Profile-specific property sources were being added last,
*after* the global values, which means they did not
override in the way that users would expect.
Fixed by storing the global property sources in an
intermediate list and applying them after the profile
specific ones.
...for compatibility with Spring JDBC. Users can still
optionally specify spring.database.schema, but the default
location is schema-${spring.database.platform}.sql, schema.sql,
data.sql.
[Fixes#58332710]
Builder for SpringApplication and ApplicationContext instances with
convenient fluent API and context hierarchy support. Simple example
of a context hierarchy:
new SpringApplicationBuilder(ParentConfig.class)
.child(ChildConfig.class).run(args);
Another common use case is setting default arguments, e.g.
active Spring profiles, to set up the environment for an application:
new SpringApplicationBuilder(Application.class).profiles("server")
.defaultArgs("--transport=local").run(args);
If your needs are simpler, consider using the static convenience
methods in SpringApplication instead.
[#49703716] [bs-116] Parent context for some beans maybe?
- If RabbitTemplate is on the classpath, turn on autodetection.
- Create a RabbitTemplate, a Rabbit ConnectionFactory, and a RabbitAdmin is spring.rabbitmq.dynamic:true
- Enable some **spring.rabbitmq** properties like host, port, username, password, and dynamic
- Add tests to verify functionality
- Add Groovy CLI functionality. Base it on @EnableRabbitMessaging. Add spring-amqp to the path.
- Create rabbit.groovy test to prove it all works.
- Make Queue and TopicExchange top-level Spring beans in rabbit.groovy test script
* application.properties support for spring.jms and spring.activemq
* more tests to verify ActiveMQConnectionFactory pooling
* Groovy support and simple sample with activemq
* Groovy detection mechanism is @EnableJmsMessaging annotation
Update SpringBootServletInitializer with separate getConfigClass() and
getAdditionalConfigClasses() methods. This change makes it easier to
use the SpringBootServletInitializer with the common use case of a
single config class.
Update DataSource conditional to ensure that the driver class
can actually be loaded by the DataSource. This fixes an issue when
deploying a classic WAR where `org.apache.tomcat.jdbc.pool.DataSource`
is found the parent classloader but the database driver cannot be loaded
because is included as a local `/lib` dependency.
Adapted to changes in the API in Spring Data Commons which requires to pass in the current Environment into the AnnotationRepositoryConfigurationSource.
The `Tomcat.start()` has to happen to initialize the `ServletContext`
but we can immediately stop the connector and then restart it when
the context is finished refreshing. Seems to make curl fail quickly
if an app is slow to start.