10 Replies Latest reply on Apr 25, 2014 7:48 AM by Artem Egorkine

    OutInterceptor in SOAP bindings a.k.a how do I access HTTP request context?

    Artem Egorkine Newbie

      Hi,

       

      I have a Switchyard application that consumes an external SOAP service. This service uses cookies to track user sessions. By default, the SOAP component doesn't track cookies itself, nor does it set the SESSION_MAINTAIN_PROPERTY (http://docs.oracle.com/javase/7/docs/api/javax/xml/ws/BindingProvider.html#SESSION_MAINTAIN_PROPERTY) on the underlying BindingProvider. I could maintain the HTTP cookies myself if only I had access to the HTTP request/reply contexts from code. I had a clever idea of using CXF's outInterceptors, but having configured out interceptors in the SOAP binding in my switchayard.xml, I couldn't see it executed at all. I tried to check the code for a place, where the outInterceptors would be installed on the client object at all. I can see the in/outInterceptors being installed only in the code that handles providing SOAP services, not consuming it.

       

      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.

       

      --Artem