The closest I can get to the HTTP connection is by adding a custom message composer, but that does not have access to the request context, reply context or cookie-related HTTP headers. If only org.switchyard.component.soap.OutbountHandler exported the dispatcher object (or the client object) in the Swithyard context, I would be well off on solving my problem. Manually maintaining cookies (as opposed to using SESSION_MAINTAIN_PROPERTY) would also allow me to keep multiple user sessions on the consumed SOAP service. This is not really a concern for me, but may be useful to someone in the future.
Of course, interceptors on the client object would solve my problem as well. But what to do in the meantime? I toyed around with the idea of supplying a custom OutbountHandler object that did what I wanted it to. In case of executing stand-alone test cases I can override org.switchyard.component.soap.deploy.SOAPComponent class using the ServiceLoader framework, but replacing this component in JBoss AS gets tricky unless I move out the code a completely separate project. If I chose to hack up the SOAP component any further I might just have to do that anyway, but I would not like to go down this path.
What am I missing? How can I get to any of the objects I'm interested in -- the dispatcher, the client, the request/response objects -- without forking the code? Any ideas would be much appreciated.