Spring Boot application is not a reading application.properties during docker run. This issue/error only happens when the actuator dependency is present.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

I have a sample Spring Cloud Stream project which internally uses spring-kafka. I have checked this with the Spring Cloud Stream and they have recommended checking this with the Spring Boot team.

Here is the sample project created for the same: https://github.com/msshitole/reactive-avro-processor

P.S: The same application runs fine with the docker if we take out or delete the spring-boot-starter-actuator dependency. Could you please the issue and do the needful. Thanks in adavance.

Comment From: wilkinsona

Thanks for the sample, unfortunately it doesn't appear to reproduce the problem. For example, I can see that server.port from application.properties is being used as Tomcat listens on port 9083:

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.2.6.RELEASE)

2020-05-13 19:39:07.012  INFO 72127 --- [           main] c.e.r.ReactiveAvroProcessorApplication   : Starting ReactiveAvroProcessorApplication on Andys-MacBook-Pro.local with PID 72127 (/Users/awilkinson/dev/temp/reactive-avro-processor/target/classes started by awilkinson in /Users/awilkinson/dev/temp/reactive-avro-processor)
2020-05-13 19:39:07.016  INFO 72127 --- [           main] c.e.r.ReactiveAvroProcessorApplication   : No active profile set, falling back to default profiles: default
2020-05-13 19:39:07.556  INFO 72127 --- [           main] faultConfiguringBeanFactoryPostProcessor : No bean named 'errorChannel' has been explicitly defined. Therefore, a default PublishSubscribeChannel will be created.
2020-05-13 19:39:07.561  INFO 72127 --- [           main] faultConfiguringBeanFactoryPostProcessor : No bean named 'taskScheduler' has been explicitly defined. Therefore, a default ThreadPoolTaskScheduler will be created.
2020-05-13 19:39:07.563  INFO 72127 --- [           main] faultConfiguringBeanFactoryPostProcessor : No bean named 'integrationHeaderChannelRegistry' has been explicitly defined. Therefore, a default DefaultHeaderChannelRegistry will be created.
2020-05-13 19:39:07.590  INFO 72127 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'org.springframework.integration.config.IntegrationManagementConfiguration' of type [org.springframework.integration.config.IntegrationManagementConfiguration] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
2020-05-13 19:39:07.598  INFO 72127 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'integrationChannelResolver' of type [org.springframework.integration.support.channel.BeanFactoryChannelResolver] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
2020-05-13 19:39:07.599  INFO 72127 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'integrationDisposableAutoCreatedBeans' of type [org.springframework.integration.config.annotation.Disposables] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
2020-05-13 19:39:07.787  INFO 72127 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 9083 (http)

Comment From: msshitole

@wilkinsona Thanks for your reply. My bad, it's working in docker but failing with the above mentioned issue when we are deploying to Kubernetes via SCDF. (Spring Cloud dataflow).

I am checking this in detail, I will update this issue with more details later today. Thanks again.

Comment From: msshitole

Unfortunately, I am unable to simulate this issue locally or only in the docker. The above issue is occurring when I am deploying this application via the Spring data flow.

I have reported this issue to the Spring Cloud Stream team as well. They will also look into this. Here is the link from the Gitter/spring-cloud-stream chat. https://gitter.im/spring-cloud/spring-cloud-stream?at=5ebd68e920d9bf305765376b

Now there are multiple possibilities with respect to the root cause analysis. - this might be the bug from Spring Cloud Stream Hoxton.SR2/SR3/SR4. The same configuration and application work fine without error with Hoxton.SR1 - This error is not happening with SCS's source microservice. It only comes with the Processor and Sink Microservices. - This error only comes when spring-boot-starter-actuator dependency is present. Hence might be some relation with Spring boot or Actuator project. - This might be the issue from Spring Cloud dataflow

Thank you again for the feedback and much-needed support!

Comment From: wilkinsona

Thanks for the update. Given that we don't have a way to reproduce the problem and it only occurs with Spring Cloud Dataflow and with particular versions of Spring Cloud Stream, I think it's best if those teams investigate in the first instance. To avoid duplication of effort, I'm going to close this issue. We can re-open it if it turns out that there's a problem in Boot itself. In the meantime, you may like to deploy your application with trace level logging enabled for org.springframework.boot.context.config. That will show you the files that have been found by ConfigFileApplicationListener and turned into property sources in the environment.

Comment From: msshitole

@wilkinsona Yes, that's a good idea. Thanks for the clue, I will check the deployment again with the given config. Many thanks!

Comment From: Arjunv56

@msshitole What is the reason for this issue? I tried the gitter link you have shared, but no discussions are available before Apr 2021.