There might be a bug in the mp config implementation of Payara. When an even low ordinal config source has a profiled value, it seems not be overrideable from a higher ordinal source. Thanks to Johannes for pointing me to this
He was trying to override the DATAVERSE_SOLR_HOST by env var and couldn't do it. Needs to be _CT_DATAVERSE_SOLR_HOST (so with the profile name we have in the container)
Sounds like a bug to me because spec says:
Conforming implementations are required to search for a configuration source with the highest ordinal (priority) that provides either the property name or the "profile-specific" property name. If the configuration source provides the "profile-specific" name, the value of the "profile-specific" property will be returned. If it doesn’t contain the "profile-specific" name, the value of the plain property will be returned.
Maybe it's just me being German, but to me this sound like it should work like "if you have a value from a higher ordinal source, that one wins"
Looking at the spec discussion in https://github.com/eclipse/microprofile-config/issues/418#issuecomment-618678228, it seems my interpretation is what was intended.
Sounds like I need to ring someone at Payara about this.
Here are the problematic lines: https://github.com/payara/Payara/blob/0704b24df099e928276d34e115b8ab4ae492a60a/nucleus/payara-modules/nucleus-microprofile/config-service/src/main/java/fish/payara/nucleus/microprofile/config/spi/ConfigExpressionResolver.java#L91-L118
the same issue occurs for FQDN and SITEURL
I think you're reading the spec right.
Philip Durbin said:
I think you're reading the spec right.
I believe the current behaviour is correct. Consider this example: Given a property with one profile-specific definition via Environment variables (default ordinal=300) and one default definition via System properties (default ordinal=400). (Higher ordinal wins.) With an activated profile, the profile version from the Environment should be returned, right? This is only possible if the profile specific definition have precedence over the the ordinals. Otherwise, the activation of a profile may have no effect as default properties are available with higher ordinal ranking. This follows the intuition that a profile override default definitions.
I still believe that the implementation in Payara is probably violating spec. https://forum.payara.fish/t/microprofile-config-not-using-value-from-higher-ordinal-source-with-profile/618
But I might be wrong or not have read the code correctly
Do note though that SmallRye Config does implement this differently
It seems odd to me that two apparently compliant implementations would behave differently.
Should we create an issue for this in the Dataverse repo?
BTW - up until now _no_ response in the forum. Wondering how much does it cost to have an Enterprise license to call support
Good question.
Thinking about reaching out to Emily Jiang
Or maybe knock in MPC project. Open an issue, ask about how that part of the spec was meant to be read.
https://github.com/eclipse/microprofile-config/issues/781
Nice writeup.
Looks like Payara is not spec compliant... https://github.com/eclipse/microprofile-config/pull/782 Sorry @Johannes D!
Uh oh, the code formatter check got ya. :big_smile:
Nice, https://github.com/eclipse/microprofile-config/pull/782 was merged? What's next?
Probably we should open an issue at Payara's. Now that we are about to be on P6 with DV6, we would actually be able to use a fixed future version.
Payara 6.2023.12 claims to be MPC 3.1 compliant. Maybe we should give this another try... MPC 3.1 contains my spec fix, so we could run the TCK again and see if it works now...
Sounds like a good reason to upgrade.
This is kind of related to creating versioned base images... we could let the images defer from main if needed. It seems to be a container experience issue for now, although people might want to use profiled settings in other scenarios, too
Related to #containers > change version scheme base image? Yes.
It looks like I cannot reproduce this anymore... We probably need to check this manually. Bummer that the TCK doesn't fail anymore like described in https://notes.desy.de/iDjhL8UESlO-_RGNKLDRZQ#
I'm having trouble setting SITEURL too: #containers > setting siteUrl in containers
I created an issue: In containers, can't set DATAVERSE_SITEURL using documented methods #10285
It looks like they did fix the failing TCK compliance hrhr https://github.com/payara/Payara/commit/5bf6a6f391893ebbb83fb01b520238b0f83d61fb
It's been included since 6.2023.11 - the first release with MP 6.1 support. That's the release with the updated MPC spec and TCK. It has not been mentioned in the release notes... And it was only tracked internally as JIRA ticket "FISH-7689"
Great!
I just created https://github.com/IQSS/dataverse/pull/10495 and I can verify that this is no longer a problem!!!
With 6.2024.4 and my fix to avoid an NPE released I declare this resolved. It's now a matter of making the upgrade to 6.2024.4, see #containers > Payara 6.2024.4
Oliver Bertuch has marked this topic as resolved.
Last updated: Oct 30 2025 at 05:14 UTC