Avoid calling BusFactory.setThreadDefaultBus(null) in JBossWSInvoker

The invocation BusFactory.setThreadDefaultBus(null) in JBossWSInvoker (just before invoking the actual user endpoint business code) is problematic performance-wise because CXF internally removes the ThreadLocal association of the current thread bus with the thread. When the JBossWSInvoker restores the former thread default bus just after the user endpoint business code execution, that ThreadLocal being unset causes CXF to access the BusFactory THREAD_BUSSES WeakHashMap within a synchronized block. Under heavy load, this easily become one of the contention hot spots in the WS invocation.
Now, the reason why the JBossWSInvoker calls BusFactory.setThreadDefaultBus(null) is to prevent the user from having access to the Bus that the integration code uses for running the deployment endpoints, to prevent users from influencing or breaking the integration (response processing, for example) in any way.
To be honest this also has a minor side effect of always wiping a thread default Bus the user might have set in its endpoint business code, regardless of which thread the code is being executed on.
As a consequence, it makes sense to create an additional Bus for the user endpoint code; that Bus will be set as thread default each time the JBossWSInvoker handles control to business methods of endpoints from the same deployment. This would prevent the BusFactory ThreadLocal from being removed (performance improvement when the integration deployment bus is later restored) and give back the same bus to the user on multiple invocations to the same deployment's endpoints.