Introduce behavior changes in the next release of MP Config

[Emily Jiang]

Just heads up to the following behavior changes in the upcoming MP Config release:

I summarise the behavior change below:

For the following config source:

server.host=localhost
server.port=9080
server.url=http://${server.host}:${server.port}

 

when calling config.getValue(server.url, String.class), it will return

http://localhost:9080

Previously, the value will be http://${server.host}:${server.port}

 

Obviously, this is a behavior change. We plan to come up with a solution to restore to the old behavior. e.g. variable.substitute=true can be specified in the individual config source to disengage the variable substituation.

With this change, even though the previous app will still compile but the return value might be different. If no strong objections, we will want to make this to the next MP Config release.

For more info, please refer to https://github.com/eclipse/microprofile-config/issues/396

If you have comments, please either comment here or directly on the above issue.

Thanks

Emily

[John Clingan]

Is this change part of a Config major version number change?

[Emily Jiang]

Hi John,

It is a behavior change and we are introducing a property to reserve the old behavior. The old app will not break, e.g. not forcing to be recompiled.

We agreed in our last week's Config hangout. We will not bump major version but minor version instead.

Thanks

Emily

[Jeff Mesnil]

We want to avoid having to bump the Config major version change for this feature as it does not break or change the API.

One proposed solution is to mandate in the specification that Config implementations MUST provide a way to disable variable expansions so that there will be no behaviour changes for the users.

So if an user was using Config 1.3, he could upgrade to this Config 1.4 and disable variable expansion so that the application will behave the same.

If we decide that such behaviour change can not be done inside a minor bump, another solution would be to keep the current behaviour the default one (no variable expansion) and says in the spec

that implementation MUST provide a way to enable variable expansion.

Personally, I'd prefer to enable variable expansion by default (as it is such an useful enhancement) and let users disable it if it breaks their existing application.