Closed jkburges closed 8 years ago
That stuff would have been logged by the app (as that is the part that actually checks the validity of proxied requests). If we wanted POs to be able to diagnose these sorts of problems then we would need to log it on the client side as you suggest.
That is what I'm suggesting. In the first instance, it would've enabled @xhoenner to rectify the problem himself without having to rely on developers to troubleshoot. Yet to get to the bottom of the second issue but I wouldn't be surprised if the same thing plays out.
Yeah, I think this would be a useful thing for POs.
I reckon it's worth bringing this up with @pblain and get it planned. (ie. it's not a bug, IMO)
I agree, it is tenuous to call it a bug but I thought it was the most likely way to get it done :-) @pblain I think doing this would save us time and increase PO happiness for relatively little effort.
Improved logging of some sort is a good idea, but it won't pass our own triage (which we set up to stop bugs becoming a backdoor for features). Best thing would be for Xav to include it in Seb's list of JPSR pre-planning items. I'll then support it at JPSR for inclusion in the next iteration.
@xhoenner @lbesnard if you agree that improved error reporting in portal for failed to load layers would be worthwhile, please let @smancini know :-)
I have just investigated two separate layers, both failing to load, both for different reasons. It was not immediately apparent (even from looking at the javascript console) why they were failing to load.
One was failing because the metadata record was referencing geoserver-rc, the other failing because of an unknown layer in an external ncwms server.
I think we could do a bit better here in terms of reporting errors and possible steps to rectify, thereby saving on waste and time to fix things.