ConfigurationProperties - ParameterResolutionExcep...

# spring

[EricJTurley]

ConfigurationProperties - ParameterResolutionException
I have:

@ConfigurationProperties("chat-replay")
@ConstructorBinding
data class ChatReplayProperties(
    val chatLogPrintInterval: Long,
    val poll: Poll,
    val generation: Generation,
    val query: Query,
    val external: External,
) {

But:
• All the chat-replay.generation.* properties are in a application-genchatlogs.properties file, so...
• When run with no active Spring Profiles, the Generation object is null
And application startup fails with ParameterResolutionException of course.

What's a good pattern for this?

[EricJTurley]

Because, the "Generation" properties are ONLY ever accessed by other Spring components that are also only available if that profile is active.
So, it's safe.
But if I mark the ChatReplayProperties.Generation as nullable, I have to keep treating all accesses of the property specially.

[Saharath Kleips]

Maybe lateinit? But it feels like there might be something better…

[hho]

Or just put the properties in the main `application.properties`… 🤷‍♂️

[hho]

If Generation isn't too complex, you could also put a default with dummy values

[thanksforallthefish]

@ConfigurationProperties("chat-replay")
@ConstructorBinding
data class ChatReplayProperties(
    val chatLogPrintInterval: Long,
    val poll: Poll,
    val generation: Generation?,
    val query: Query,
    val external: External,
) {
  val publicGeneration: Generation
     get() = checkNotNull(generation)
}

I don’t remember right now if you could have val generation: Generation? private and still have it injected by spring

[EricJTurley]

@Saharath Kleips I COULD use lateinit - but then I don't get constructor injection.

[EricJTurley]

@hho The Generation -type properties don't apply UNLESS the gen-chat-logs profile is active. So ... it doesn't strictly belong in application.properties (which is why it's currently not there, and this problem exists)

[EricJTurley]

@hho So yes - I could put "useless" values in application.properties just to create an object that isn't used or read ... of course.
But I'm looking for a better pattern...

[EricJTurley]

@thanksforallthefish
Yes - that's what I'm currently going with.
Calling it from Java is fine, because I just get a warning that properties.getGeneration().getSomething() might throw an NPE. Not too big a deal.
But calling it from Kotlin requires treating it as strictly nullable - which I can do, but, practically, it's never null WHEN it's called, because it's only ever called from classes that are also active when that profile is active.

So - I'm using this, but wondering if there was some better pattern.

[thanksforallthefish]

but why using generation and not a non null version? you are not forced to use the same value you injected, practically I never do so I can preserve encapsulation and I feel more OO. just use publicGeneration which will ofc fails when generation is null, but since it cannot happen it is not a concern