FWD » Core Development » User Interface

The client is reset (back to login screen) when clicking various widgets. I found this is client log:

java.lang.NullPointerException
    at com.goldencode.p2j.ui.ConfigManager.getConfigUpdates(ConfigManager.java:350)
    at com.goldencode.p2j.ui.ClientConfigManager.getConfigUpdates(ClientConfigManager.java:217)
    at com.goldencode.p2j.ui.chui.ThinClient.getChanges(ThinClient.java:13514)
    at com.goldencode.p2j.net.Protocol.attachChanges(Protocol.java:323)
    at com.goldencode.p2j.net.Queue.enqueueOutbound(Queue.java:852)
    at com.goldencode.p2j.net.Dispatcher.processInbound(Dispatcher.java:837)
    at com.goldencode.p2j.net.Conversation.block(Conversation.java:412)
    at com.goldencode.p2j.net.Conversation.waitMessage(Conversation.java:348)
    at com.goldencode.p2j.net.Queue.transactImpl(Queue.java:1170)
    at com.goldencode.p2j.net.Queue.transact(Queue.java:641)
    at com.goldencode.p2j.net.BaseSession.transact(BaseSession.java:271)
    at com.goldencode.p2j.net.HighLevelObject.transact(HighLevelObject.java:211)
    at com.goldencode.p2j.net.RemoteObject$RemoteAccess.invokeCore(RemoteObject.java:1473)
    at com.goldencode.p2j.net.InvocationStub.invoke(InvocationStub.java:145)
    at com.sun.proxy.$Proxy4.standardEntry(Unknown Source)
    at com.goldencode.p2j.main.ClientCore.start(ClientCore.java:361)
    at com.goldencode.p2j.main.ClientCore.start(ClientCore.java:158)
    at com.goldencode.p2j.main.ClientDriver.start(ClientDriver.java:250)
    at com.goldencode.p2j.main.CommonDriver.process(CommonDriver.java:444)
    at com.goldencode.p2j.main.ClientDriver.process(ClientDriver.java:144)
    at com.goldencode.p2j.main.ClientDriver.main(ClientDriver.java:313)

I was not able to duplicate it by clicking the same sequence of widgets.

Also, the location (ConfigManager.java:350) does not make sense: the dirtyConfigs is initialized at declaration and never reassinged.

Ovidiu Maxiniuc wrote:

Also, the location (ConfigManager.java:350) does not make sense: the dirtyConfigs is initialized at declaration and never reassinged.

My bad, the dirtyConfigs is not null, but when the exception is thrown, it contains multiple entries mapped to null, so dirtyConfigs.get(wid) is null. The only location where dirtyConfigs can get a null value is in switchId().

Solution¶

Indeed, if switchId() is already populated with the new key, a call with an old key will retrieve null as the value but will overwrite the correct value already set for the new key. The solution is probably to abort switching ids if the old one is not found in the map.