Changed behaviour of BaseThingHandler.getConfig() in OH 3.0.0 snapshot

[mherwege]

I set up an install of an OH 3.0 snapshot to see how the binding I developed, Niko Home Control, would behave. It turns out it does not work anymore. I could pinpoint the problem to a changed behaviour of the BaseThingHandler.getConfig() method.
Here is the log:

2020-05-14 09:45:50.998 [WARN ] [re.config.core.internal.ConfigMapper] - Could not set field value for field 'addr': addr
java.lang.NoSuchFieldException: addr
	at java.lang.Class.getDeclaredField(Class.java:2411) ~[?:?]
	at org.openhab.core.config.core.internal.ConfigMapper.writeField(ConfigMapper.java:113) ~[bundleFile:?]
	at org.openhab.core.config.core.internal.ConfigMapper.as(ConfigMapper.java:102) [bundleFile:?]
	at org.openhab.core.config.core.Configuration.as(Configuration.java:80) [bundleFile:?]
	at org.openhab.binding.nikohomecontrol.internal.handler.NikoHomeControlBridgeHandler2.setConfig(NikoHomeControlBridgeHandler2.java:234) [bundleFile:?]
	at org.openhab.binding.nikohomecontrol.internal.handler.NikoHomeControlBridgeHandler2.initialize(NikoHomeControlBridgeHandler2.java:62) [bundleFile:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
	at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [bundleFile:?]
	at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:834) [?:?]

The problem is that the NikoHomeControlBridgeConfig2 class (https://github.com/openhab/openhab-addons/blob/127f05d7cbb865ae2f7a939c761707f0479d5143/bundles/org.openhab.binding.nikohomecontrol/src/main/java/org/openhab/binding/nikohomecontrol/internal/handler/NikoHomeControlBridgeConfig2.java) extends the NikoHomeControlBridgeConfig class (https://github.com/openhab/openhab-addons/blob/127f05d7cbb865ae2f7a939c761707f0479d5143/bundles/org.openhab.binding.nikohomecontrol/src/main/java/org/openhab/binding/nikohomecontrol/internal/handler/NikoHomeControlBridgeConfig.java). Before, when calling getConfig().as(NikoHomeControlBridgeConfig2.class) (https://github.com/openhab/openhab-addons/blob/127f05d7cbb865ae2f7a939c761707f0479d5143/bundles/org.openhab.binding.nikohomecontrol/src/main/java/org/openhab/binding/nikohomecontrol/internal/handler/NikoHomeControlBridgeHandler2.java#L127), the configuration fields from the base call would be included. In OH 3.0.0, these are missing, resulting in an incomplete configuration and a handler that stays in INITIALIZING phase.
As this works perfectly well in OH 2.5.4 and I am looking at the release code, something has changed in between. I suspect a change in behaviour due to Java 11, but I am not sure about that.
I logged this issue in core, as it looks like a changed behaviour in core.

[mherwege]

@cweitkamp Could it be the problem was introduced with #1433 ?
In the new writeField() method (

openhab-core/bundles/org.openhab.core.config.core/src/main/java/org/openhab/core/config/core/internal/ConfigMapper.java

Line 111 in 583ea02

private static void writeField(Object target, String fieldName, Object value, boolean forceAccess)

), we do not look for fields in the super classes anymore, while these fields are considered in the getAllFields() method.

[cweitkamp]

Thanks for reporting. This is probably related to my changes in #1433. We have to check up the superclass hierarchy instead of the target class only. I will submit a fix for it.

[cweitkamp]

See #1474