Closed ronaldtse closed 4 years ago
Looks like the exact error is:
Exception evaluating SpringEL expression: "pmi.fromJson('{"aliases":["JGD2011"],"definition":["Japanese Geodetic Datum 2011"],"anchorDefinition":["Equivalent to ITRF2008 at epoch 2011.395 (2011-05-24, 12:00 UTC) in Northern Honshu area. Fundamental point: Tokyo-Taisho, latitude: 35°39'29.1572\"N, longitude: 139°44'28.8869\"E (of Greenwich). Equivalent to JGD2000 elsewhere."]}')" (registry/item:212)
i.e. This message is not valid JSON:
{
"aliases": [
"JGD2011"
],
"definition": [
"Japanese Geodetic Datum 2011"
],
"anchorDefinition": [
"Equivalent to ITRF2008 at epoch 2011.395 (2011-05-24, 12:00 UTC) in Northern Honshu area. Fundamental point: Tokyo-Taisho, latitude: 35°39'29.1572\"N, longitude: 139°44'28.8869\"E (of Greenwich). Equivalent to JGD2000 elsewhere."
]
}
Maybe it's the \"N
and \"E
causing the crash.
@phuonghuynh The immediate way to fix this is to fix the data.
However we want to fix the mechanism so that this doesn't occur again. This piece of JSON looks like to be generated and then re-parsed as JSON, and there's something wrong with the escaping mechanism here.
Are the the \"N and \"E present in the anchorDefinition for the JGD2000 entry (item #111). That entry doesn't crash. Both of these entries were imported via the spreadsheet.
Some further testing...
1) The staging registry gives the same error for JGD2011 (item 138 in both registries). I noticed that when the item is submitted to the Control Body, the Details button displays the entry properly (the entry is displayed as it would be for a general user).
2) Also in the staging registry, I replaced the deg-min-sec symbols with hyphens in the anchor definition but the item still gives the display error.
3) In the staging registry, I removed the lat & lon from the anchor definition and the item still gives the display error.
4) In the staging registry, I removed the anchor definition entirely and the item still gives the display error.
5) In the staging registry, I invalidated the original item 138 and re-entered/replaced it with a new identical item 742. The new item 742 displays properly. Interestingly, when the invalidation proposal was submitted to the Registry Manager, the Details button in the Registry Manager's folder gives a display error (it didn't for Clarification action). The same occurred when submitted to the Control Body when selecting the Details button in that folder.
So it appears the anchor definition is not the problem and that there might be something else wrong with the original database entry? In any case, this can be resolved by invalidating the old item and replacing it with a new identical one.
Interesting issue ^
From @phuonghuynh:
still investigating it, look like the issue related to importing data. It is not json parser related
@ronaldtse the fix has been deployed to prod server
Thanks @phuonghuynh ! I can see the page now loads properly.
@maccraymer can you help verify? Thanks!
@ronaldtse & @phuonghuynh thanks for fixing this right away!! The page loads proper now on my iPhone, iPad, Mac mini and MacBook all using Safari & Chrome, and on my office Windoze desktop using Internet Exploder & Chrome.
@phuonghuynh just out of curiousity, what was causing the problem and how did you fix it?
@maccraymer Spring EL evaluator failed to parse the data return in this case, special characters not supported in the framework. To fix it, I moved the function into java code to remove Spring EL processing for this case.
In today's ISO GR Control Body meeting, the following error was observed (triggered by @maccraymer at approval of the datum).
Steps:
Go to https://geodetic.isotc211.org/register/geodetic/GeodeticDatum
Filter for "Japan"
Click on "Details" for "Japanese Geodetic Datum 2011" entry
It redirects to: https://geodetic.isotc211.org/item/11842bba-82c2-49bc-83bf-0333aca2cb87
The full error trace: