Stack trace highlights the method 'reloadResponseContext' in the class 'org.apache.cxf.endpoint.ClientImpl' as it is loaded from the EAP patch-provided jar cxf-core-3.1.16.redhat-1.jar.

This version of ClientImpl is changed from the previous version (cxf-core-3.1.12.redhat-1.jar) which did not show the problem. The particular problem can be seen in this code / stack trace snippet:

------------------- Code from the EAP-patch jar (v3.1.16) -------------------------------

protected Map<String, Object> reloadResponseContext(Map<String, Object> o) {
Thread t = Thread.currentThread();
ResponseContext ctx = (ResponseContext)this.responseContext.get(t); <<<<<<<<<<<<<<<<<<<<<<<---------------- This is line 277, matches the provided stack trace.

----------------- Portion of the stack trace --------------------------------------------

2018-10-04 10:02:32,685 E (pool-612-thread-1) [com.redacted.customername.productionOrderRetrieval] ProductionOrder | Retrieve | 9250003 | java.lang.ClassCastException: java.util.HashMap cannot be cast to org.apache.cxf.endpoint.ClientImpl$ResponseContext

---------------------------------------------------------------------------------------------

So we see that we have a 'HashMap' in hand (from this.responseContext.get(t)) and we want to cast it to a ResponseContext. But the compiler catches us and tells us this cannot be done.

Looking more closely at the inner class 'ResponseContext', we see this:

----------------- From ClientImpl.ResponseContext --------------------------

class ResponseContext extends HashMap<String, Object>

--------------------------------------------------------------------------------------------------------

So we see we are very close, but not close enough. We have a HashMap, but ResponseContext is more particular than that. It wants a HashMap<String, Object>.