I'm not a huge fan of passing in a loggingContext, loggingExecContext and a loggingContextFunction in order to facilitate logging strategy use. The strategy gets passed in upon initialization along with the context and execContext and the API will be able to create the correct logging context for the WS and REST APIs. This is desired but needs some fine tuning. Perhaps instead of using withLoggingBitMEXWrapper and withLoggingBitMEXConfig try creating a type class and create instances for BitMEXConfig and BitMEXWrapperConfig?
Additional tasks:
* Refine the granularity of source names (i.e each queue should have a unique source name)
I'm not a huge fan of passing in a
loggingContext,loggingExecContextand aloggingContextFunctionin order to facilitate logging strategy use. The strategy gets passed in upon initialization along with the context and execContext and the API will be able to create the correct logging context for the WS and REST APIs. This is desired but needs some fine tuning. Perhaps instead of usingwithLoggingBitMEXWrapperandwithLoggingBitMEXConfigtry creating a type class and create instances forBitMEXConfigandBitMEXWrapperConfig?Additional tasks:
* Refine the granularity of source names (i.e each queue should have a unique source name)