- OAuth 2.0 Resource Server JWT :: Spring Security
- Common Application Properties :: Spring Boot
- OAuth2ResourceServerJwtConfiguration
- Note. It does not use org.springframework.security.oauth2.jwt.JwtAudienceValidator class
If we accept the classic equation knowledge = power, then by substitution, knowledge transfer becomes power transfer.
In disciplines like physics, engineering, and especially politics, transferring power is rarely simple —
it often involves resistance, inefficiency, and loss.
| @Configuration | |
| public class KafkaConfig { | |
| @Bean | |
| public NewTopic fooTopic(@Value("${app.topics.fooTopic}") String topic) { | |
| return TopicBuilder.name(topic) | |
| .partitions(8) | |
| .build(); | |
| } | |
| import com.fasterxml.jackson.annotation.JsonProperty; | |
| import com.fasterxml.jackson.annotation.JsonTypeInfo; | |
| import org.javers.core.ChangesByCommit; | |
| import org.javers.core.diff.Change; | |
| import org.javers.core.json.BasicStringTypeAdapter; | |
| import org.javers.core.json.typeadapter.util.UtilTypeCoreAdapters; | |
| import org.springframework.boot.autoconfigure.jackson.Jackson2ObjectMapperBuilderCustomizer; | |
| import org.springframework.context.annotation.Bean; | |
| import org.springframework.context.annotation.Configuration; | |
| import org.springframework.http.converter.json.Jackson2ObjectMapperBuilder; |
| import org.springframework.boot.task.ThreadPoolTaskExecutorBuilder; | |
| import org.springframework.context.annotation.Bean; | |
| import org.springframework.context.annotation.Configuration; | |
| import org.springframework.core.task.AsyncTaskExecutor; | |
| import org.springframework.security.task.DelegatingSecurityContextAsyncTaskExecutor; | |
| @Configuration | |
| public class AsyncTaskExecutorConfiguration { | |
| /** |
| import com.droidablebee.avro.BlueEvent; | |
| import com.droidablebee.avro.GreenEvent; | |
| import org.apache.avro.specific.SpecificRecord; | |
| import org.apache.kafka.clients.consumer.ConsumerRecord; | |
| import org.slf4j.Logger; | |
| import org.slf4j.LoggerFactory; | |
| import org.springframework.kafka.annotation.KafkaListener; | |
| import org.springframework.messaging.MessageHeaders; | |
| import org.springframework.stereotype.Service; |
Ran into an issue with flyway script executing an alter table statement while Postgres auto-vacuum for the same table was in progress.
As tables grow, Postgres runs the auto-vacuum for tables periodically. The flyway script was stuck waiting for the table lock to be released.
To avoid this issue, one can disable the auto-vacuum before the flyway migration and re-enable it after migration is finished using beforeMigrate.sql and afterMigrate.sql.
Occasionally it can be helpful to parameterize a migration depending on an environment. Flyway supports the concept of placeholders to help with that.
Flyway provides default placeholders, whose values are automatically populated:
${flyway:defaultSchema}= The default schema for Flyway${flyway:user}= The user Flyway will use to connect to the database${flyway:database}= The name of the database from the connection url${flyway:timestamp}= The time that Flyway parsed the script, formatted as 'yyyy-MM-dd HH:mm:ss'
For some reason, DataSourceHealthIndicator does not support custom query configuration via a property.
DataSourceHealthContributorAutoConfiguration
uses poolMetadata.getValidationQuery() to pass the validation query to DataSourceHealthIndicator.
Using spring.datasource.hikari.connection-test-query will customize the Hikari datasource test query and db health check will also it. However, it will also affect the performance of the Hikari connection pool which is not ideal.
Another way of configuring a custom query for DataSourceHealthIndicator is to create this as a @Bean manually and pass a custom query to its constructor. Using the same @Bean name dbHealthIndicator disables the [autoconfiguration of the default DataSourceHealthIndicator](https://github.com/spr
-
disable
auto scalingand set number ofreplicasmanually -
view events in GCP to get a better idea of why application is getting killed and restarted

-
note how long it takes for app to start successfully in your current environment
- adjust number of tries for
livenessandreadinessprobes to accommodate slower start ups - enable debug logging by org.springframework.boot.availability.ApplicationAvailabilityBean
- adjust number of tries for
-
use GCP metrics to monitor application CPU and RAM usage