Re: HTTP SPI working for us?
On 07/31/2010 05:40 AM, Glen Mazza wrote: Daniel Kulp wrote: I don't think it will as I know I haven't implemented anything using the http/spi things yet and I don't remember Jim doing so either.The JAX-WS 2.2 TCK doesn't hit it at all. Thus, it's not really something that needs to be there to claim compliance. I did see that blog entry and thought it looked interesting, but I really haven't had the time to try getting that stuff implemented. It may be pretty tricky to implement as it almost requires a whole new transport, but I haven't looked to much at it. Dan Neither have I. But if I understand the new functionality correctly, it would not be so much the need for a new transport but a need to abstract CXF's present usage of Jetty in implementing Endpoint in a manner that allows other servlet containers to be placed in. What JAX-WS 2.2 basically does (in pseudocode) is switch from this: Endpoint e21 = new Endpoint(...); to this: Endpoint e22 = new Endpoint(Jetty, ...); allowing the developer to replace "Jetty" with "Tomcat" or "Grizzly", etc., in the first parameter of the constructor above (as soon as Endpoint-supporting implementations of the latter two are created.) If my understanding here is correct, then Jetty would remain the default implementation for our Endpoint interface with its own simplified constructor, i.e., new Endpoint(...) would be the same as new Endpoint(Jetty, ...), and Endpoint reimplemented so constructors of the latter form could be created. My understanding is that completing the JAXWS 2.2 implementation covering the HTTP SPI stuff too implies being able to publish an endpoint against any http server implementing that SPI. Btw, that spi is very similar to the SPI in the jdk internal webserver, com.sun.net.httpserver.* which I believe is what the jaxws RI already supported through the Endpoint.publish(Object context) method (which currently does nothing in CXF, the Endpoint.publish(String addr) is used instead). JAXWS 2.2 added Endpoint.publish(HTTPContext context) (and the classes in javax.xml.ws.spi.http) as a "generalization" of what was already there in the RI. Now, Jitu is adding a connection between the new jaxws http spi and Grizzly -which btw is just few classes-, for supporting usecases like [1]. He correctly says that this Grizzly connection can be used with any JAXWS implementation, as of course most of the hard work (ehm, all of that) needs to be done for supporting the jaxws http spi. So, back to CXF, I agree adding support for this is basically writing a new transport. That would potentially allow running on many different http server though, including Grizzly (and the jdk internal httpserver, probably just few conversion classes required once this is done). Might allow, for instance, avoid shipping Jetty (which btw is the reason why I might be interested in working on this...) Do you agree / does this "sum up" of the situation make sense to you? [1] http://forums.java.net/jive/thread.jspa?messageID=478300 -- Alessio Soldano Web Service Lead, JBoss
Re: HTTP SPI working for us?
On Wednesday 11 August 2010 12:16:29 pm Alessio Soldano wrote: > My understanding is that completing the JAXWS 2.2 implementation > covering the HTTP SPI stuff too implies being able to publish an > endpoint against any http server implementing that SPI. > Btw, that spi is very similar to the SPI in the jdk internal webserver, > com.sun.net.httpserver.* which I believe is what the jaxws RI already > supported through the Endpoint.publish(Object context) method (which > currently does nothing in CXF, the Endpoint.publish(String addr) is used > instead). > JAXWS 2.2 added Endpoint.publish(HTTPContext context) (and the classes > in javax.xml.ws.spi.http) as a "generalization" of what was already > there in the RI. > Now, Jitu is adding a connection between the new jaxws http spi and > Grizzly -which btw is just few classes-, for supporting usecases like > [1]. He correctly says that this Grizzly connection can be used with any > JAXWS implementation, as of course most of the hard work (ehm, all of > that) needs to be done for supporting the jaxws http spi. > So, back to CXF, I agree adding support for this is basically writing a > new transport. That would potentially allow running on many different > http server though, including Grizzly (and the jdk internal httpserver, > probably just few conversion classes required once this is done). Might > allow, for instance, avoid shipping Jetty (which btw is the reason why I > might be interested in working on this...) > Do you agree / does this "sum up" of the situation make sense to you? Pretty much yea. It might not be TOO hard to implement. The ServerFactoryBean that is used during publish contains the DestinationFactory object (with setter/getter). Thus, the new publish method would just need to set that with a new Destination that wrappers the new SPI stuff. I haven't looked at the new SPI stuff to know how hard that is. I DO know that for some bizzare reason, it doesn't use HttpServletRequest/Response which would be required for a bunch of things. Thus, you'll need to create instances of those that forward into the SPI things. For the most part, if you can create an HttpServletRequest/Response, then a subclass of AbstractHttpDestination would be pretty easy to create to do all this. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: JiBX Databinding: databinding interface methods
On Saturday 07 August 2010 3:41:15 am Dennis Sosnoski wrote: > On 07/22/2010 02:16 PM, Daniel Kulp wrote: > > On Wednesday 21 July 2010 5:19:42 pm Dennis Sosnoski wrote: > > > > ... > > > >> And in > >> that case I assume the runtime DataBinding object must implement > >> WrapperCapableDatabinding, right? (Since otherwise I don't see how the > >> unwrapping could be handled). > > > > Well, yes and no. It should implement it if possible.If not, what > > happens at runtime is that the WrappedInInterceptor would strip off the > > wrapper element and it would try and call into the databinding to read > > each individual part directly. In some cases, this can be a bit slower > > as the databinding needs to set things up and such for each part instead > > of for the entire payload at once. > > So as long as the databinding code can efficiently process multiple > child elements one-at-a-time it's feasible to skip generating classes > for the wrapper elements and instead just generate the data model? Then > the WrappedInInterceptor would create a DataReader instance for each > child element of the wrapper, and call one of the read() methods? Yep. That's how Aegis works. > So does the WrappedInInterceptor know which type of DataReader to > create for each child element type by calling (at code generation time) > the DataBindingProfile String getType(QName qn, boolean element) method? No. It passes the MessagePartInfo object into the reader for the part. From there, the Databinding can figure out whatever it needs to do. If it needs to call getType, it can. If it has other ways to handle it, great. > It sounds like we could use either approach with JiBX - generate classes > for the wrapper elements, and support the DataBindingProfile String > getWrappedElementType(QName wrapperElement, QName item) method call to > provide code-generation-time information about the child element > components *and* also generate WrapperHelper classes to get data in and > out of the wrappers, or only generate the actual data classes and let > WrappedInInterceptor handle the details. Since generating the > WrapperHelper classes adds a fair amount of complexity, I'm thinking the > latter approach might be better. If it works, then yea. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: Corba Use Case: CXF/JAX-WS Server and CXF/JAX-WS Client with corba:sequence produces Unmarshalling Error: null
Any chance I can get the IDL for that simple service in the tar. I'd like to
create a pure CORBA client and server for it like we have for the CORBA demos.
That should help narrow down where the problem is. If the client can talk to
the pure CORBA server, we know the problem is in the reading/unmarshalling.
If the pure CORBA client can talk to the CXF server, we know the unmarshalling
is OK. If nothing can talk to anything, we're really screwed. :-)
At the very least, it would help narrow down where the problem is.
Dan
On Friday 06 August 2010 2:12:41 pm Andrew Lamb wrote:
> Hello,
>
> I’ve put together a fairly simple derivative of the “Hello World CORBA
> Demo” (specifically “Use Case 3 - CXF/JAX-WS Server, CXF/JAX-WS Client”)
> which may be showing a defect.
>
> This began as a rather large, complicated corba idl from an external vender
> which I converted to wsdl using the cxf idl2wsdl utility. Testing this
> using a simple CXF/JAX-WS Server and CXF/JAX-WS Client, one particular
> operation produced the exception “org.apache.cxf.interceptor.Fault:
> Unmarshalling Error: null” on the server. After verifying that all objects
> were getting fully initialized by the client without any nulls, I began
> paring away everything from the wsdl that wasn’t pertinent to this
> particular scenario.
>
> What I’ve found is that given the following types, a HelloWorld message
> works if the inparameter is of type “MyItem” but not for “MyItemVector”.
>
>
>
>
>
>
>
>
>
>type="MyItem">
>
>
>
>
> So based upon these findings, I’ve attached a HelloWorld project that
> hopefully will make reproducing this behavior fairly easy. (Note: I’ve
> only included the wsdl—not the original idl. I can produce that as well
> if this would help.) I’ve reproduced this on XP as well as HPUX and using
> both cxf-2.2.9 and the cxf-2.3.0-SNAPSHOT and I’ve been using java6 and
> Sun’s orbd.
>
> To reproduce
> 1.Untar ApacheCxfProblem.tar
> http://cxf.547215.n5.nabble.com/file/n2266930/ApacheCxfProblem.tar
> ApacheCxfProblem.tar
> 2.Configure ApacheCxfProblem/config/.profile
>
> export PROJECT_HOME=/ApacheCxfProblem
> export CXF_HOME=/apache-cxf-2.2.9
>
> 3.From the ApacheCxfProblem/bin directory execute
>
> . ../config/.profile
> ./runns.sh
> ./runserver.sh
> ./runclient.sh
>
> Thanks,
> Andrew
>
>
>
> Here is a snippet of my client code:
>
> SayingHelloCORBAService s = new SayingHelloCORBAService();
> SayingHello client = s.getSayingHelloCORBAPort();
>
> MyItem item = new MyItem();
> item.setNewMyString( "6010" );
>
> MyItemVector vector = new MyItemVector();
> vector.getItem().add( item );
>
> System.out.println("Invoking greetMe... ");
> String result = client.helloWorld( vector );
> System.out.println("greetMe.result=" + result);
>
>
> And resulting stack trace on the server:
>
> org.apache.cxf.interceptor.Fault: Unmarshalling Error: null
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:7
> 80) at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:6
> 24) at
> org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:128)
> at
> org.apache.cxf.interceptor.BareInInterceptor.handleMessage(BareInIntercepto
> r.java:138) at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
> n.java:243) at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationO
> bserver.java:110) at
> org.apache.cxf.binding.corba.runtime.CorbaDSIServant.invoke(CorbaDSIServant
> .java:175) at
> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToS
> ervant(CorbaServerRequestDispatcherImpl.java:626) at
> com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(Co
> rbaServerRequestDispatcherImpl.java:189) at
> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestReques
> t(CorbaMessageMediatorImpl.java:1682) at
> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(Corba
> MessageMediatorImpl.java:1540) at
> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMe
> ssageMediatorImpl.java:922) at
> com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(R
> equestMessage_1_2.java:181) at
> com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(Corba
> MessageMediatorImpl.java:694) at
> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(Sock
> etOrChannelConnectionImpl.java:451) at
> com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(Socket
> OrChannelConnectionImpl.java:1213) at
> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.perfor
> mWork(ThreadPoolImpl.java:471) at
> com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(Th
> readPoolImpl.java:500) Ca
