-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Description
In the go-based buildpack The config/*.yml configuration files and the configuration overlay mechanism are now removed.
Functionalities for configuring with JBP_CONFIG_<FRAMEWORK> are available in the respective frameworks where parsing and handling of custom config properties is applied.
Some of the go-based frameworks though seem to lack possibility to adjust some of their corresponding configurations through JBP_CONFIG mechanism, for example:
-
google stack profiler framework - application_name and application_version properties which were set with priority from configuration as can be seen here are only obtained from
VCAP_APLICATIONin the go-based framework and custom config is not taken into concern. -
java_memory_assistant framework - Some of the agent section properties that are with empty default values in the original config seem to be disregarded from possibly setting custom config values with
JBP_CONFIG_JAVA_MEMORY_ASSISTANTin the go-based framework. For example if an app is staged with the following:JBP_CONFIG_JAVA_MEMORY_ASSISTANT: '{ enabled: true, agent: { thresholds: { heap: 1000 } } }'the threshold value won't be reflected in agent config. On this place and this place some values and custom values are not taken into concern. Also nojava-memory-assistantcannot be downloaded at all with the go-based buildpack because corresponding info missing inmanifest.yml. -
jrebel agent framework - setting
enabledthoughJBP_CONFIGlike in the current implementation seems not an option in the go-based framework.JBP_CONFIG_JREBEL_AGENT: '{ enabled: false }'won't disable jrebel. Enablement is based solely on havingrebel-remote.xml. -
new relic agent framework - The extensions config section seems to be disregarded in the go-based framework.
-
sealights agent framework - These config properties seem to not be available for custom configuration through
JBP_CONFIGin the go-based framework. -
skywalking agent framework - The default_application_name property which was taken in concern here seems not a subject of custom config in the go-based version.