Hi Lukas, none of these Provider<CorbaMessage>, Provider<SOAPMessage> or Provider<Source> is supposed to work with CORBA binding. The type class T in Provider<T> has to be something that can represent the message (or message payload) you sent on the wire DIRECTLY. What I mean by “directly” is without any extra marshaling/unmarshalling or transformation for example, using a data binding to map one type to another type. In the case of SOAP binding or XML binding, the content type is text/xml, the wire message can always be represented as Source or SOAPMessage (SOAP binding) object. The message sent on the wire for CORBA biding is in binary format. A simple question, in the Dispatch example you gave in your previous email, how can you transform a Source that represents a xml document of "<tns:add xmlns:tns= <http://schemas.apache.org/yoko/idl/calc/> http://schemas.apache.org/yoko/idl/calc/>" into a binary format of CORBA message? The T in Provider<T> or Dispatch<T> has to be something that you can take it and sent it out on the wire directly without any transformation. This is why Dispatch<Source> won’t work.
To get Dispatch/Provider interface working with CORBA binding, we need to figure out what the T is in the Provider<T>. If you use CORBA server & web services client as described in YOKO ws\hello_world sample (i.e., the server is using CORBA binding, the client is using SOAP or XML binding), Dispatch<Source> should definitely work, because what sent on the wire is SOAP or XML message. Jervis -----Original Message----- From: Lukas Zapletal [ mailto:[EMAIL PROTECTED] Sent: 2007年8月2日 23:00 To: [email protected]; [EMAIL PROTECTED] Subject: Re: YOKO & CXF CORBA Web Service using Provider<CorbaMessage> Hello, the operation info and CORBA parameters are not the reason why do we need the support. We would like to create a web service provider that will be accessible from CORBA client. We have no clue how to do this because we cannot simply create Provider<CorbaMessage>, Provider<SOAPMessage> or even Provider<Source>. Exception occurs when we try this so it seems nobody ever used it before and the code contains a bug or we are doing something wrong. On the other side we are also trying to call (normal) CORBA service with web service client implemented in CXF/Yoko dynamicaly (DII client). We do not know if is it possible to create SOAPMessage and pass it to Yoko CORBA binding along with WSDL file to make a dynamic call. It seems to me the terms "corba cxf binding" and "dynamic" cannot live together... Best regards, Lukas 2007/8/2, Liu, Jervis <[EMAIL PROTECTED]>: > 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 > -- Lukas Zapletal http://lukas.zapletalovi.com ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
