cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
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 16:15:24 GMT

Guys, 

The point is mashalling and unmarshalling is NOT something the soap binding 
should be doing.   It should get the reader/writer from the Service and be 
calling on that.   If the read/writer needs some extra information, the 
frontend (like jax-ws) or databinding should put it in the service model as a 
property.    In no case should the soap binding need to know anything about 
what is being written or called.

It's possible that the reader/writer methods may need an additional parameter 
to provide it with additional information.   One thought is to include the 
MessageInfo/MessagePartInfo to the reader/writer so the reader/writer knows 
what it's actually trying to do.    THAT would make sense to me.

If the databinding layer needs more information for it to accurately do it's 
job, lets find a way to get that information there that doesn't pollute the 
bindings/transports/etc...


Dan




On Monday September 11 2006 10:23 pm, James Mao wrote:
> Hi two Dans,
>
> Yes, I think what Tom looking for is what i was looking for days, We
> still need those type class info for marshalling/unmarshalling, i dont'
> know if you guys have resolve this problem, and i definitely need to
> find a place for those, not just the RPC, i think if it's doc-lit-bare
> style, and if it's use the type, it will also need the type info.
>
> Thanks,
> James.
>
> Li, Tao (Tom) 写道:
> > Hi Dan.K & Dan.D,
> >
> > My purpose of adding getImplementor() is to find the java class
> > information matched with the message part in the input/output message. In
> > the case of RPC style, the messagepart using type="...", to unmarshall
> > this using JAXB, we need to provide the QName and java class of this
> > message part, and the java class can't be found only with service model.
> >
> > e.g. <wsdl:part type="x1:myComplexStruct" name="in">
> >
> > I'm looking for some other way to solve this problem, but still have no
> > good solution, any help are most welcomed! Thanks Tom
> >
> >
> >
> >
> > -----Original Message-----
> > From: Kulp, John Daniel
> > Sent: Monday, September 11, 2006 1:11 PM
> > To: cxf-dev@incubator.apache.org
> > Cc: Dan Diephouse; cxf-commits@incubator.apache.org
> > 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
> >
> > 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 methods.

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194   F:781-902-8001
daniel.kulp@iona.com

Mime
View raw message