Hi, have a new question. I suppose the reason why you want to use Provider interface for CORBA binding is that you want to access "raw CORBA message payload" so that you can parse operation info and input parameters by yourself. However the question is what the "raw CORBA message payload" is? In the world of SOAP binding or XML binding, the content sent on the wire normally can be represented as XML, thus we can have typed provider interface like Provider<Source>, Provider<SOAPMessage>. However, in the world of CORBA, I don't think we have a well-defined type to represent "raw CORBA message payload", do we? Please note, org.apache.yoko.bindings.corba.CorbaMessage is not the one we are looking for. Same as the org.apache.cxf.binding.soap.SoapMessage and org.apache.cxf.binding.xml.XMLMessage, they are just a content holder, which represent the whole input/output message rather than the message payload. The type class that can be used in Provider<T> is sth that can be produced by Object<T> = DataReader.read(...). Before we can go ahead to support Provider<T> for CORBA binding, we really need to figure out what the T is.
BTW, if what you want is CorbaMessage, you can access it from Exchange. See Dan's previous comment in this thread on how to access Exchange. I will send this message across to yoko mailing list, hopefully Yoko guys can give some insight on this. Cheers, Jervis -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 2007年7月30日 19:52 To: [email protected]; Liu, Jervis Subject: RE: YOKO & CXF CORBA Web Service using Provider<CorbaMessage> Hi Jervis, it really sounds great, cxf would be more flexible then. Thank you for your replies. So do you plan adding support of that to cxf? And would it be possible to know when? :-) Cheers, Michael -----Original Message----- From: Liu, Jervis [mailto:[EMAIL PROTECTED] Sent: Monday, July 30, 2007 1:12 PM To: [email protected]; [EMAIL PROTECTED] Cc: Michal ?afr; [EMAIL PROTECTED] Subject: RE: YOKO & CXF CORBA Web Service using Provider<CorbaMessage> Coming to think of this again, I found supporting Provider<CorbaMessage> isn't that difficult as I originally thought. We have some manual checks of binding type in DispatchInDatabindingInterceptor\DispatchOutDatabindingInterceptor, such as if (binding == soapbinding) then blabla. Actually we were just being lazy, we should really implement DispatchInDatabindingInterceptor as DispatchInSoapBindingDatabindingInterceptor and DispatchInXMLbindingDatabindingInterceptor. This way, different dispatch/provider interceptors for different bindings can be added by corresponding binding providers, which allows the support of new bindings without the need to modify existing code base. E.g., adding CORBA binding support for dispatch/provider involves in writing a DispatchInCorbaBindingDatabindingInterceptor, doing whatever you want in this interceptor then making sure the CORBABinding provider has this DispatchInCorbaBindingDatabindingInterceptor registered into interceptor chain during provider/dispatch case. Cheers, Jervis -----Original Message----- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: 2007年7月28日 11:23 To: [email protected] Cc: Michal ?afr; [EMAIL PROTECTED] Subject: Re: YOKO & CXF CORBA Web Service using Provider<CorbaMessage> Michal, Right now, we don't support any Provider (or Dispatch) that takes the raw CXF Message types. That's a good suggestion though. Could you log a Jira for it? What's worse, looking at the code for the Dispatch/Provider stuff on trunk, it only will work for XML and SOAP bindings. It specifically checks for those and does "bad" things. I was hoping to say you could do something like: public class CalculatorImpl implements Provider<XMLStreamReader> { } to use the data from the CORBA stream reader, but that doesn't even work right now. Even trying a Source doesn't work. I think some Jira's need to be added for that as well. Dan On Friday 27 July 2007 09:29, Michal Šafr wrote: > > firstly I'm not sure, if this is CXF or YOKO problem, so please excuse > me if I've sent this problem to a wrong place. I've got the problem > described below. > > I started from simple WSDL describing service with CORBA binding. I > generated standalone server and client using CXF tool wsdl2java > -server (-client) . Implemented service and everything worked fine > without any problem. I was able to call WS using generated client and > WS was returning expected values. Then I decided to implement WS using > interface javax.xml.ws.Provider so I had: > > //Service class, annotations are not mentioned here, but i changed > @WebService annotation to @WebServiceProvider and added @ServiceMode > > public class CalculatorImpl implements Provider<CorbaMessage> { > > public CorbaMessage invoke(CorbaMessage arg0) { > > System.out.println("corba service called"); > > return arg0; > > } > > } > > > > Every time I try to call WS a receive following exception on the > client side: > > > > org.omg.CORBA.MARSHAL: vmcid: SUN minor code: 207 completed: No > > at > com.sun.corba.se.impl.logging.ORBUtilSystemException.endOfStream(ORBUt >ilSyst emException.java:6386) > > at > com.sun.corba.se.impl.logging.ORBUtilSystemException.endOfStream(ORBUt >ilSyst emException.java:6408) > > at > com.sun.corba.se.impl.encoding.BufferManagerReadStream.underflow(Buffe >rManag erReadStream.java:93) > > at > com.sun.corba.se.impl.encoding.CDRInputStream_1_1.grow(CDRInputStream_ >1_1.ja va:75) > > at > com.sun.corba.se.impl.encoding.CDRInputStream_1_2.alignAndCheck(CDRInp >utStre am_1_2.java:80) > > at > com.sun.corba.se.impl.encoding.CDRInputStream_1_0.read_longlong(CDRInp >utStre am_1_0.java:504) > > at > com.sun.corba.se.impl.encoding.CDRInputStream_1_0.read_double(CDRInput >Stream _1_0.java:526) > > at > com.sun.corba.se.impl.encoding.CDRInputStream.read_double(CDRInputStre >am.jav a:153) > > at > com.pikeelectronic.calc._CalculatorStub.add(_CalculatorStub.java:182) > > at > com.pikeelectronic.calc.CORBAClient.Client.main(Client.java:32) > > > > And following exception on the server side: > > > > 27.7.2007 13:21:05 org.apache.cxf.phase.PhaseInterceptorChain > doIntercept > > INFO: Interceptor has thrown exception, unwinding now > > java.lang.NullPointerException > > at java.lang.Class.isAssignableFrom(Native Method) > > at > org.apache.cxf.databinding.source.XMLStreamDataReader.read(XMLStreamDa >taRead er.java:56) > > at > org.apache.cxf.databinding.source.XMLStreamDataReader.read(XMLStreamDa >taRead er.java:52) > > at > org.apache.cxf.databinding.source.XMLStreamDataReader.read(XMLStreamDa >taRead er.java:48) > > at > org.apache.cxf.interceptor.BareInInterceptor.handleMessage(BareInInter >ceptor .java:138) > > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto >rChain .java:206) > > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia >tionOb server.java:67) > > at > org.apache.yoko.bindings.corba.runtime.CorbaDSIServant.invoke(CorbaDSI >Servan t.java:156) > > at > org.apache.yoko.orb.OBPortableServer.ServantDispatcher.dispatch(Servan >tDispa tcher.java:225) > > at > org.apache.yoko.orb.OBPortableServer.POA_impl._OB_dispatch(POA_impl.ja >va:160 7) > > at > org.apache.yoko.orb.OB.DispatchRequest_impl.invoke(DispatchRequest_imp >l.java > > :56) > > at > org.apache.yoko.orb.OB.DispatchSameThread_impl.dispatch(DispatchStrate >gyFact ory_impl.java:53) > > at org.apache.yoko.orb.OB.Upcall.invoke(Upcall.java:360) > > at > org.apache.yoko.orb.OB.GIOPConnectionThreaded.execReceive(GIOPConnecti >onThre aded.java:502) > > at > org.apache.yoko.orb.OB.GIOPConnectionThreaded$ReceiverThread.run(GIOPC >onnect ionThreaded.java:64) > > 27.7.2007 13:21:06 org.apache.cxf.phase.PhaseInterceptorChain > doIntercept > > INFO: Interceptor has thrown exception, unwinding now > > org.apache.yoko.bindings.corba.CorbaBindingException: > java.lang.NullPointerException > > at > org.apache.yoko.bindings.corba.interceptors.CorbaStreamFaultOutInterce >ptor.h andleMessage(CorbaStreamFaultOutInterceptor.java:113) > > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto >rChain .java:206) > > at > org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessa >ge(Abs tractFaultChainInitiatorObserver.java:86) > > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto >rChain .java:223) > > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia >tionOb server.java:67) > > at > org.apache.yoko.bindings.corba.runtime.CorbaDSIServant.invoke(CorbaDSI >Servan t.java:156) > > at > org.apache.yoko.orb.OBPortableServer.ServantDispatcher.dispatch(Servan >tDispa tcher.java:225) > > at > org.apache.yoko.orb.OBPortableServer.POA_impl._OB_dispatch(POA_impl.ja >va:160 7) > > at > org.apache.yoko.orb.OB.DispatchRequest_impl.invoke(DispatchRequest_imp >l.java > > :56) > > at > org.apache.yoko.orb.OB.DispatchSameThread_impl.dispatch(DispatchStrate >gyFact ory_impl.java:53) > > at org.apache.yoko.orb.OB.Upcall.invoke(Upcall.java:360) > > at > org.apache.yoko.orb.OB.GIOPConnectionThreaded.execReceive(GIOPConnecti >onThre aded.java:502) > > at > org.apache.yoko.orb.OB.GIOPConnectionThreaded$ReceiverThread.run(GIOPC >onnect ionThreaded.java:64) > > Caused by: java.lang.NullPointerException > > at java.lang.Class.isAssignableFrom(Native Method) > > at > org.apache.cxf.databinding.source.XMLStreamDataReader.read(XMLStreamDa >taRead er.java:56) > > at > org.apache.cxf.databinding.source.XMLStreamDataReader.read(XMLStreamDa >taRead er.java:52) > > at > org.apache.cxf.databinding.source.XMLStreamDataReader.read(XMLStreamDa >taRead er.java:48) > > at > org.apache.cxf.interceptor.BareInInterceptor.handleMessage(BareInInter >ceptor .java:138) > > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto >rChain .java:206) > > ... 9 more > > > > I have changed nothing else than WS implementation on server side. > Could anyone help please? Every advice is welcome, thank you very > much. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
