If you get an error debugging an Olingo service (one of the Java libraries for OData), you often get an error like “An exception occurred.”
This, apparently, is a result of decision by the Olingo team to not be dependent on a specific logging library (although I’m not sure how this makes sense, since they are dependent on CXF, which seems pretty heavy).
The simple solution to this problem they recommend is to add a callback method to your ODataServiceFactory implementation:
public T getCallback(final Class callbackInterface)
{
return (T) (callbackInterface.isAssignableFrom(ScenarioErrorCallback.class) ?
new ScenarioErrorCallback() :
callbackInterface.isAssignableFrom(ODataDebugCallback.class) ?
new ScenarioDebugCallback() :
super.getCallback(callbackInterface));
}
And then, classes for each:
private final class ScenarioDebugCallback implements ODataDebugCallback {
@Override
public boolean isDebugEnabled()
{
return true;
}
}
private final class ScenarioErrorCallback implements ODataDebugCallback {
@Override
public boolean isDebugEnabled()
{
return true;
}
}
Now, it seems silly that you’d want to have both of these, but this adds error messages to the JSON response, with each line of Java stack traces as a separate JSON object.
With these attributes set, add “odata-debug=json” to any Olingo URL and you’ll get debug information back.
Once you do this, you will then discover that the JSON payloads of Olingo are monstrous, and to deal with this you need a browser plugin – I like JSON Formatter, which auto-detects JSON, then formats and colorizes it:
