cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
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/endpoin...
Date Mon, 11 Sep 2006 20:11:05 GMT

On Monday September 11 2006 10:15 am, Dan Diephouse wrote:
> > incubator/cxf/trunk/api/src/main/java/org/apache/cxf/endpoint/Endpoint.ja
> >va (original) +++
> > incubator/cxf/trunk/api/src/main/java/org/apache/cxf/endpoint/Endpoint.ja
> >va Mon Sep 11 03:11:15 2006 @@ -44,4 +44,6 @@
> >      Executor getExecutor();
> >
> >      Interceptor getFaultInterceptor();
> > +
> > +    Object getImplementor();
> >  }
> I'm -1 on this change. Why is this on the Endpoint? It looks like you're
> looking up the method from the implementor methods and the class names,
> which isn't a real good way to do it. 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).

Dan beat me to this one.    Also a very strong -1 to this change. 

The SOAP binding should have no knowledge of the method or target objects or 
anything like that.    The whole point of the service model is to abstract 
out all of that information .   The RPCInInterceptor should use the message 
to find the OperationInfo (specifically, the BindingOperationInfo) from the 
service model and only use the information that is available from there.

The frontend could be something like a javascript engine or Ruby engine or 
similar where there either isn't a target object or the target object doesn't 
have any java methods on it that have any relation to the data in the 

J. Daniel Kulp
Principal Engineer
P: 781-902-8727    C: 508-380-7194   F:781-902-8001

View raw message