On a slightly related point, we actually already had at least three different ways of accessing the Method in an interceptor.
On the requestor side, the ClientImpl caches the Method via Message.setContent(Method.class, ...) and the EndpointInvocationHandler also sticks the Method in its context map with key "java.lang.reflect.Method", and this is then copied into the Exchange map (but not the message!) by the ClientImpl. On the responder side, its available via the BindingOperationInfo property "java.lang.reflect.Method", as you say. Currently in the WS-A (non-SOAP) interceptor, I'm looking up Message.getContent(Method.class), and falling back to the BindingOperationInfo property if the former is not set. BTW the Method is used in this case to access certain annotations that determine the wsa:Action header. Probably makes more sense though to just ensure the BindingOperationInfo property is set in ClientImpl, and then use this as the single consistent way of accessing the Method, whether on the requestor or responder sides. I make this change if there's no objection. /Eoghan > The BindingOperationInfo name should correspond to the > rpc element name and the JaxWsServiceFactory should have > already instantiated the operation with a Method. The invoker > can then invoke the service by looking up the operation from > the exchange. Also, there shouldn't be a need to look up the > class as the Databinding is handling (see all the > wrapped/bare interceptors for examples). > > Cheers, > - Dan > > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com > http://netzooid.com/blog > >
