Hi Reza,
I hope you've been well and that you had a happy Fourth. I was running some tests using the application on different operating systems and comparing their behavior to that of the original Payara implementation. During testing, I noticed two instances of odd behavior in the original app that I can detail below. All of the observations on the original app were made using Oracle Java version 11.0.15 on Mac OS.
1. Map display needs to be accessed on app startup before routing new cargo.
- In order for the map to be loaded properly, it must be accessed on startup before routing cargo.
- If cargo is routed before map is accessed for the first time on startup, the map display will error like the image below:
- The map display problem does not occur on Open Liberty when the same actions are taken (cargo can be routed before the map is accessed on OL).
- To replicate the issue, start the app using "mvn clean package cargo:run", navigate to the administration interface, and select any route for the DEF789 cargo object. Then, return to the administration interface and select 'Map'. The map should error and look the same as the above screen capture.
2. Public tracking interface displays incorrect current status for cargo objects in ports.
- After a cargo is loaded onto a voyage and then unloaded into a new non-destination port, the public tracking interface incorrectly displays its status as at the destination.
- This cargo object was loaded onto its initial voyage and unloaded at a stop (reflected in the event logs), but the status of the object says that it is at its destination port:
- The object was unloaded in Tokyo with plans to be loaded onto its next voyage. However, the status says that the cargo object is in Melbourne (the final destination for the object) even though the logs are correct.
- This issue occurs on both Open Liberty and the original Payara implementation.
- To replicate the issue, start the app using "mvn clean package cargo:run", navigate to the administration interface, and select any route for the DEF789 cargo object. Then, open the Mobile Event Logger and log a 'load' event for object DEF789's first voyage at or before the specified load time. Then, log an 'unload' or 'customs' event for the DEF789 object at the destination for its first voyage at or before the specified unload time. The public tracking interface should look similar to the screen capture above.
Let me know if you have any questions or if you've seen this behavior before. Just wanted to bring these to your attention!
Best,
Chanun
