mandy-chessell
commented
5 years ago OCFErrorCode is an enum that defines message structures. It does not capture exceptions - it puts out a debug log message whenever it is called to format an error message.
These types of errors are captured by the ConnectorBroker in exceptions. The exceptions include a detailed message generated by OCFErrorCode.
I am only guessing at the use case here as there is not much detail. However, I looked at the OMRS initialization logic and discovered the following ...
When the exception happens in one of the connectors used by the OMRS (such as the OMRS Repository Connector) then the exception is caught and wrapped in an OMRSConfigErrorException which is returned to caller. Unfortunately, for security reasons, the nested exception stack is not returned from the server so the detailed message is lost.
I have added an audit log message to each of the catch blocks in the methods that initialize the OMRS connectors. This should give some detail as to the original cause. However, this may not cover the use case referred to above.
There still seem to be areas where exceptions are being captured, and either not audit-logged / logged at all, or logged only as debug messages (without the full stack trace).
Example 1: trying to startup an connector that itself has some additional dependencies, when those additional dependencies are not also included in the
LOADER_PATHyou'll end up with aNoClassDefFoundError-- whichOCFErrorCodeappears to capture and only outputs as a debug message:This makes troubleshooting problems particularly challenging 😉