Upgrading from 1.4.9 to more recent versions throws NoSuchElementException

[chris-ryan-square]

I've tried upgrading from 1.4.9 to 1.4.10 and above, but I get the following stacktrace:

java.util.NoSuchElementException: List is empty.
        at kotlin.collections.CollectionsKt___CollectionsKt.first(_Collections.kt:212)
        at com.sksamuel.hoplite.decoder.DataClassDecoder.safeDecode(DataClassDecoder.kt:116)
        at com.sksamuel.hoplite.decoder.NullHandlingDecoder$DefaultImpls.decode(Decoder.kt:85)
        at com.sksamuel.hoplite.decoder.DataClassDecoder.decode(DataClassDecoder.kt:28)
        at com.sksamuel.hoplite.ConfigLoader.decode(ConfigLoader.kt:400)
        at com.sksamuel.hoplite.ConfigLoader.loadConfig(ConfigLoader.kt:386)
...

I haven't narrowed what in our config is causing this as yet, but if I do, I'll update the issue with the details.

[sksamuel]

Is that the only thing you changed ?
Also, did you try 1.4.14 ?

[sksamuel]

The class in question, does it have multiple constructors ?

[chris-ryan-square]

I tried 1.4.10, 1.4.13 and 1.4.14.

I haven't worked out which particular part of the config it's breaking on. The main config class is a data class that includes a number of other data classes (which in turn do the same).

I have no extra explicit constructors, although some fields do have default values (does that make another constructor?). If it matters, some of these default values are null.

And my config is loaded combining 2 yaml files.

[sksamuel]

Can you supply the yaml files and the data classes ? Replace any real data with xxxxxx and rename the fields to a b c d e.

…

On Sun, 14 Nov 2021 at 21:07, Chris Ryan ***@***.***> wrote: I tried 1.4.10, 1.4.13 and 1.4.14. I haven't worked out which particular part of the config it's breaking on. The main config class is a data class that includes a number of other data classes (which in turn do the same). I have no extra explicit constructors, although some fields do have default values (does that make another constructor?). If it matters, some of these default values are null. And my config is loaded combining 2 yaml files. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#236 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVSGU7TTYGBAUZA6G52QLUMB2OFANCNFSM5IANMR4A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[chris-ryan-square]

I started on extracting it out to a test case for you, but somehow in the process of doing the sanitisation it's now working fine. So, I have to go back to the start of the sanitisation process and work through to find the real issue.

[sksamuel]

Ok cool.

…

On Mon, 15 Nov 2021 at 16:23, Chris Ryan ***@***.***> wrote: I started on extracting it out to a test case for you, but somehow in the process of doing the sanitisation it's now working fine. So, I have to go back to the start of the sanitisation process and work through to find the real issue. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#236 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVSGUACPTSZ6F7YATJJYLUMGB7FANCNFSM5IANMR4A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[chris-ryan-square]

Another update. I've got a separate project where I'm trying to reproduce the error. I went back to using copies of various files to run the test - passes fine.

My various data classes are across a number of modules/projects, so the only thing I can think of right now is something weird with the classpath. Shall investigate more. Very bizarre.

[sksamuel]

Just looked over the classloader stuff and it hasn't changed in a while. Does the issue go away if you just move back to 1.4.9 ?

…

On Mon, 15 Nov 2021 at 16:40, Chris Ryan ***@***.***> wrote: Another update. I've got a separate project where I'm trying to reproduce the error. I went back to using copies of various files to run the test - passes fine. My various data classes are across a number of modules/projects, so the only thing I can think of right now is something weird with the classpath. Shall investigate more. Very bizarre. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#236 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVSGX7KKRN5HFJPSNR2T3UMGD5XANCNFSM5IANMR4A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[sksamuel]

If so (that 1.4.9 works again) then my guess is this commit: 4e9f584

Which is why I was asking about multiple constructors.

[chris-ryan-square]

Yes, it works fine with 1.4.9.

I wrote another test in our actual code and the 1.4.14 works fine as well with the real classes and config.

I don't know why yet, but the error happens when the code is running the application - which happens to be bundled in a shadow jar.

[chris-ryan-square]

I'll be closing this issue as the fault is 100% in my camp. It was a gradle build file misconfiguration that was including libraries it should not have been in the final shadow jar. The changes in 1.4.10 were enough to trigger a time-bomb that was waiting to go off.

[chris-ryan-square]

Spoke too soon. My changes + last lot of tests were with the 1.4.9 version. Still got the issue. More investigations.

[mneundorfer]

I can confirm this issue

For me the problem disappears after getting rid of @ConfigAlias in my configuration class. Not sure about the underlying issue though...

edit: I could track down the cause to the value defined in ConfigAlias containing a dot ., such as app.host. It seems that using appHost instead solves the problem.

[sksamuel]

Once we have a duplicating case I will fix ASAP.

…

On Tue, 16 Nov 2021 at 05:50, mneundorfer ***@***.***> wrote: I can confirm this issue For me the problem goes away after getting rid of @ConfigAlias in my configuration class. Not sure about the underlying issue though... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#236 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVSGUGU7R3TT7BGX4O4DLUMJAR7ANCNFSM5IANMR4A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[chris-ryan-square]

@mneundorfer if you've got an example that shows the issue that you can share, please do.

[chris-ryan-square]

Got a simple replication for you:

import com.sksamuel.hoplite.ConfigLoader
import com.sksamuel.hoplite.yaml.YamlPropertySource
import io.kotest.core.spec.style.FreeSpec

data class A(
  val foo: Foo = Foo()
)

data class Foo(
  val x: String = "x"
)

class StartHereConfigTest : FreeSpec({

  val config = "{" +
      "}"

  "Bug Reproduce" {
    val a = ConfigLoader.Builder()
      .addSource(YamlPropertySource(config))
      .build()
      .loadConfigOrThrow<A>()
  }

})

[chris-ryan-square]

Essentially, buried in our config we've got an "optional" config data class that has defaults in it (other data classes - not sure if that's important or not). Those fields have default values. And our config has no entries for these defaults, so I assume they get an "empty" block to parse?

[sksamuel]

So the config data class is itself not nullable, but each of the parameters of that class are optional as they provide defaults, and with the empty block, the whole thing falls over ?

If so, I understand the issue, and will work on a fix.

@chris-ryan-square

[chris-ryan-square]

Yes, it took a while to track down as I was thinking about null values. Anyway, the test above should help.

[sksamuel]

Ok publishing 1.4.15 now with fix.

[chris-ryan-square]

Retested with 1.4.15 - all good now, thanks.