[WebServiceTemplate] Add support for per-request interceptors [SWS-552]

[gregturn]

Kenny MacLeod opened SWS-552 and commented

I would like to see the WebServiceOperations interface extended to support the concept of client interceptors supplied at the time of invocation. In other words, in addition to allowing interceptors to be added to the WebServiceTemplate configuration, you would also be able to supply them to the sendAndReceive methods; these interceptors would only apply to that call.

My use case is that I have a WebServiceTemplate instance which is used against various target web services, each with a different URI, so I use the sendAndReceive(uri...) methods. However, each of these web services has different authentication credentials, and I want to use the Wss4jSecurityInterceptor to supply those credentials. But since interceptors are configured for the whole WebServiceTemplate instance, they can't be used for what I want. My workaround is to have one WebServiceTemplate instance per target web service, but I'd rather have a single instance.

---

No further details from SWS-552

[gregturn]

Arjen Poutsma commented

I don't think we'll do per-invocation interceptors. The WebServiceTemplate is already pretty overloaded; adding more method variations will make it even more so. Here are some workarounds:

There is very little overhead for creating multiple WSTemplate instances, especially if you have a shared Commons HTTP client between them. I can understand you don't want a lot of template configs in your app context, but it's not so base with abstract parent bean definitions.

Alternatively, you can write a WebServiceMessageCallback/WebServiceMessageExtractor to do the security. You can take a look into the security interceptors to see how it's done. It's not trivial, but possible. It you come up with something, and contribute, I can add it to the code base :).

[gregturn]

Kenny MacLeod commented

I'd been working on the assumption that creating new WebServiceTemplate instances was expensive, due to the fact that it generates INFO log output, which in Spring I think generally means "doing something expensive enough to warrant visible logs". If this isn't the case, then can the SAAJ discovery loging (and other WSTemplate-init logging) be done once and only once, to emphasise the fact that it's a cheap operation?

As for the callback idea, would that mean implementing a "multi-callback" which handles both the SOAP Action and the security? There doesn't seem to be such a collection implementation of the callback interface, would it make sense to add one to the core?

[gregturn]

Arjen Poutsma commented

If you don't supply a message factory as constructor argument, a default SaajSoapMessageFactory is created in the WebServiceTemplate. So if you don't want to create one per template, define one in your app context, and inject it to all the templates. Once again, (abstract) parent bean definitions are your friend here.

As for the callbacks, having a composite of them makes sense. If you create a separate JIRA for that, I'll see what I can do.