Notes on Debugging
Over the years the pc2 team has debugged a number of unusual problems. We have had to work through and imagine where the problem is and then work to fix those problems.
We use the following rules:
-
It is our bug; it's not the compiler, it's not the OS; it's our code. Based on our experience, there is less than a 1:1000 chance that a reported bug in PC² is not something in our code.
-
Reproduce the bug by isolating the bug as much as possible (reduce to a unit test).
-
Do not change too much at a time. If you do you may be debugging bugs you have introduced.
-
Update libraries and JVMs to see if the bug was fixed already.
-
The Eclipse Debugger is your friend -- learn to use it well!
Summary: Fixed a problem without a code change: needed an updated library.
07:05:57.313 [AppServerThread-0] ERROR e.csus.ecs.pc2.app.AppServer.startup - Error during AppServer startup: java.lang.RuntimeException: Cannot load platform configurator java.lang.RuntimeException: Cannot load platform configurator at javax.websocket.server.ServerEndpointConfig$Configurator.fetchContainerDefaultConfigurator(ServerEndpointConfig.java:123) at javax.websocket.server.DefaultServerEndpointConfig.(DefaultServerEndpointConfig.java:85) at javax.websocket.server.ServerEndpointConfig$Builder.build(ServerEndpointConfig.java:301) at io.dropwizard.websockets.WebsocketBundle.addEndpoint(WebsocketBundle.java:86) at io.dropwizard.websockets.WebsocketBundle.lambda$new$0(WebsocketBundle.java:67) at io.dropwizard.websockets.WebsocketBundle$$Lambda$31/1912821769.accept(Unknown Source)
The code worked, but the configurator was not loaded.
We started with StackTrace and found one part of the solution here: https://stackoverflow.com/questions/39740531/jetty-websocket-java-lang-runtimeexception-cannot-load-platform-configurator
We changed
javax.websocket.server.ServerEndpointConfig.Configurator
in the MANIFEST to
javax.websocket.server.ServerEndpointConfig$Configurator.
A single character change (change a period to a dollar sign in front of the Configurator class name).
Then our team solved the problem by updating our libraries.
There was no code change needed; the problems were with the libraries.
Most of the PC2v9 system is platform-independent Java code. However, there are a few isolated places where, in order to keep the overall PC2v9 system truly "platform independent", it was necessary to include some OS-specific code. There are very few instances of this type of code -- but they do exist.
A ramification of the above is that occasionally we have found ourselves linking to (and digging through) Windows "DLL" (Dynamic Linked Library) code. We found this article to be helpful in this regard.
