Your thoughts on 2 use cases on MP Config

[Emily Jiang]

Recently, on MP config hangout, we cannot reach conclusion on a couple of use cases. I would like to bring them up here to get a wider conversation purely from a user perspective.

1. As an end user, do you need to set an empty value as a config value and wish to get the empty value from your application? If yes, please provide your detailed use case.

2. As an end user, do you need to way to erase a property, though it was specified in a config source? If yes, please provide your detailed use case again.

When you reply, please use a detailed example.

Thanks in advance!

Emily

[Emily Jiang]

I also posted this question to our ConfigJSR mailing list. Below is the response I got from Phillip .

Dear Emily,

here are my 50 Cents on this:

Concerning question 1: yes, I like empty values

For me it makes a difference if a property is present but empty, or if it is null.

There are plenty of use cases for empty properties (like custom prefixes or suffixes).

If a property is null in contrary, I would like to be able to provide a default value myself, which I wouldn't do, if it is empty.

Concerning question 2: no idea

It depends on the definition of "configuration". If "configuration" is always deemed to be "read only", than the erasing of a property simply makes no sense.

I "configuration" to the contrary is something that is "mutable", than erasing must be possible. Nevertheless it gets tricky here, if a configuration item is defined on several sources and some sources are "ready only" (as e.g. environment variables) whereas other are "modifiable" by the application (as e.g. system properties or files). It must than be ensured, that if a simple "= null" (aka removal) of a single property does not lead to a consecutive search on the next invocation, meaning that an explicit "remove" list must be maintained, which increases programmatic complexity.

I would go for a "read only" API but offer a simple "clone-like" mechanism into a similar data structure that is mutable and which may also be able to handle deletes. But for the 95% of cases the overhead makes imho no sense.

hth, Philip

Thanks

Emily

[Rhuan Henrique]

Hi,

About question 1 and 2:

I think these behaviors depend of ConfigSource implemented and we should keep it open for the implementation decide. Looking in my example here(https://rhuanrocha.net/2018/12/21/microprofile-config-creating-a-custom-configsource/) the config values are immutable (are read from source only once), but I can create a ConfigSource that refresh these values when called. I'm talking about value inside ConfigSource, but if you are talking about the config value inside a class attribute, I think it don't need to way to erase a property.

Regards,

Rhuan Rocha

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/0dc89d7e-4614-4a2e-9a9c-7343ca106254%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Emily Jiang]

Thank you Rhuan for your comments! Unfortunately we need to spec this so that implementations are in sync and microservices are portable.

More comments from Config JSR mailinglist and twitter responses:

From Sebastian

Hi Emily,

For 1. yes I absolutely see that necessity in projects. E. g. configuring something where empty value represents the default, or "do nothing" behavior (business-logic wise). I can't think of a better example r/n, but e.g. having a String concatenation or replacement in the logic where an empty value (legally) does nothing.

For 2. I'm sure there's also a use case, but I wouldn't judge it too important, based on my experience. With my committer hat on, I wouldn't include it in a standard (yet).

Cheers,
Sebastian

Christina

IMO empty string would be more correct in your example (specifying user.name=).

Empty String => Property exists and is blank

Null => Property is not set

From twitter:

Marcus 

I can't think of any reason why I would want to set an empty config value specifically.

• Derek

Better question is: Why not? Solving a problem domain isn't about knowing each individual use-case, it is about accommodating every possible unimagined use-case. Libraries solve problem domains, not solution domains.

• 
  

• Mark Struberg‏

In @DeltaSpikeTeam weused an empty value to ‚erase‘ a lower ordinal config. This has the effect to make the code fall back tomthe programmatic default behaviour. In other words „“==null

• Pascal

Depending on the environment, we may have to use a proxy for some http calls. As the config keys list is consistent across environments, we may have to set the proxy config value to "" in some config files, and handle the http client accordingly in our application.

We will discuss this further in tomorrow's MP Config hangout. Please join in if you are interested in the discussion.

Thanks

Emily

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[Emily Jiang]

Anyone who is interested in this discussion, please vote on your availability here

If you cannot join the call, please have a look at the comment https://github.com/eclipse/microprofile-config/pull/407#issuecomment-491859890 and provide your feedback.

https://doodle.com/poll/aikzk6ntipbv7ppn

Thanks

Emily