ConfigProperty default name

[Emily-Jiang]

In ConfigProperty.java, the javadoc says
{@code class_name} is the fully qualified name of the class being injected to with the first letter decaptialised.

Originally, I proposed to be {@code class_name} is the simple name of the class being injected to with the first letter decaptialised.
The decaptialised bit does make sense.

Later on, Mark changed it to be fully qualified classname. I missed the commit. The decaptialised bit looks very odd. e.g
com.acme.myBean.myProperty
as com.acme.Mybean.myProperty is much better read.

Can we remove the decaptialisation bit? I know this is behaviour change. Considering the light usage, it should be minimal. Thoughts?

[Emily-Jiang]

@struberg @OndrejM @johnament should this be fix this in MP Config 1.1?

[Emily-Jiang]

I'll vote yes, though.

[OndroMih]

This would be a breaking change, although this is how I wanted it initially. And to be honest, I was really confused why our Payara impl decapitalizes the class name until I found out that this is specified by the spec.

I'm in favor of this fix, although we may also preserve the current behavior as deprecated and the new behavior taking precedence if both keys are found. In other words, if a Capitalized config key is found, it will be used, and if not, decapitalized key will be searched for and used if found. The new behavior should be stressed while the old behavior still supported and mentioned somewhere in the spec (e.g. as a compatibility or deprecation note).

[Emily-Jiang]

+1 on Ondrej!

[johnament]

Since there was no TCK test for this previously, I'm OK if we change the behavior in the release. GConfig actually didn't support it at all.

[johnament]

BTW, if you want this for MP Config 1.1, it has to have a pull request submitted today. If it doesn't make this release, we'll need to keep both behaviors around for following releases.

[Emily-Jiang]

ok. can we agree on which one to go for? I will submit a PR once a decision is made.

1. Simplified classname with the first letter decaptialised
2. Fully qualified classname?
3. Support as Ondro suggested: both fully qualified classname and fully qualified classname with the first letter decapitialised
   At this stage, I am fine with either 1 or 2. Most runtime will go directly to Config 1.1. Can we vote and then I will do a PR?

[smillidge]

2 or 2.toLowerCase()

[Emily-Jiang]

Thanks @smillidge ! I'll provide a PR with 2.

[OndroMih]

I'm in favor of 2 for the sake of simplicity. I agree that there's not much risk in introducing this breaking change in such a short time, provided that it's properly announced (e.g. in release notes).