Make "default-env.json" optional for Java CAP services

[dirk_richtsteiger]

Hi,

currently, we have to maintain an application configuration of our Spring Boot CAP services in multiple places:

• Spring Boot's "application.yaml" file
• several "default-env.json" files (for different non-CF test spaces like Spring Integration Tests or local tests)

Spring Boot supports the definition of different profiles at the application configuration and it has a built-in VCAPS parser that makes it possible to access VCAPS settings at the "application.yaml".

In principle something like the following example would be possible to be maintained at "application.yaml":

cds:
  xsuaa:
    url: ${vcap.services.xsuaa.credentials.uri}
---

spring.config.activate.on-profile: spring-integration-test
cds:
  xsuaa:
    url: https://localhost:${DYNAMIC_XSUUA_PORT}
---
spring.config.activate.on-profile: local-test
cds:
  xsuaa:
    url: https://localhost:9000

To make this happen, CAP should define Spring configuration properties for the ones currently fetched from VCAPS directly and during bootstrapping check, if the necessary properties are provided by the "application.yaml".

This would make "default-env.json" superfluous for CAP Spring Boot services and our live a bit easier.

Maybe you could consider this idea in your further roadmap planning?

All the best,

Dirk

[marcbecker]

Yes these are all valid and good thoughts!

Currently CAP Java follows a slightly different concept where Service Bindings are less "optional". CAP Java directly reacts to Service Bindings to auto-configure various aspects (DataSources, MessagingServices, Multitenancy, etc.). In addition CAP often allows to provide configuration to configure these auto-configured things, usually by connecting the configuration to the service binding from which the thing was autoconfigured (for example: here, here, here or here).

What you are rather suggesting is to allow the configuration of such things completely in properties. Auto-configuration based on Service Bindings would then act as a prefilling of these configuration sections. CAP Node.js follows this pattern, but we deviated from that a little bit in CAP Java.

To sum it up: Currently configuration in CAP Java refers to Service Bindings, while you suggest Service Bindings should fill configuration.

This usually leads to the fact that you need to provide Service Bindings (which can be provided in default-env.json, VCAP_SERVICES, K8s secrets, and also potentially other places -> the place where a Service Binding comes from is already abstracted in CAP Java*) in case you also want auto-configuration of various things in your application.

We will keep these thoughts in mind, in case we get the chance to redesign this a little bit.

I guess you already know that you can configure at least a Spring profile-dependent default-env.json, through this property, right?

* In theory you could already today implement code in an extension that retrieves Service Bindings from configuration. However then you would unnecessarily separate the Service Binding from the "thing it auto-configures" in their configuration structure.