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: [email protected] > > Cc: Dan Diephouse; [email protected] > > 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 [EMAIL PROTECTED]
