cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: svn commit: r442162 - in /incubator/cxf/trunk: api/src/main/java/org/apache/cxf/databinding/ api/src/main/java/org/apache/cxf/endpoint/ rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/ rt/core/src/main/java/org/apache/cxf/endpoi
Date Tue, 12 Sep 2006 15:03:23 GMT
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.


> 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

View raw message