cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <j...@iona.com>
Subject RE: Provider & Dispatch usage
Date Thu, 15 Feb 2007 08:54:35 GMT


> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 2007?2?15? 2:31
> To: cxf-dev@incubator.apache.org
> Subject: Re: Provider & Dispatch usage
> 
> 
> We also seem to support SOAPBody which is not in the spec AFAIK.
> 
> On 2/14/07, Dan Diephouse <dan@envoisolutions.com> wrote:
> >
> > It seems that throughout the codebase we're using 
> Providers/Dispatches
> > with specific Source implementations. For instance 
> Provider<DOMSource>
> > instead of Provider<Source>. The JAX-WS spec seems to imply 
> that people
> > should be using Provider<Source> though and mentions 
> nothing about specific
> > Source implementations. We don't even seem to support 
> Provider<Source> which
> > is an issue I'm working on fixing, but are specific Source 
> implementations
> > something we wish to allow?

Digging into code, yes, we do not support Provider<Source>. An example of using Provider<Source>
should look like below, I believe:

@WebServiceProvider
@ServiceMode(value=Service.Mode.PAYLOAD) 
public class MyService implements Provider<Source> { 
    public MyService() { 
    } 

public Source invoke(Source request) { 
    if(DOMSource.class.isAssignableFrom(type)) {
       ....
    } else if (SAXSource.class.isAssignableFrom(type)) {     
       ....
    } else if (StreamSource.class.isAssignableFrom(type) 
      ....
   }  

   //Or using Transformer and XSLT to transforme Source to a stream
   //transformer.transform((Source)obj, new StreamResult(os));
}

The problem with our current impl is that if the MyService is declared as "MyService implements
Provider<Source>", we would not be able to transform input payload to a concrete implementation
of Source.In SOAPBodyDataReader.java, line 57, if type is Source, we should convert SOAPBody
into a default implementation of Source, DOMSource, lets say, instead of using JAXb to unmarshal
it to a object, which is wrong.   

Also for the client side, following code is valid, but I am not sure if it really works.

Dispatch<Source> disp = service.createDispatch(portName, Source.class, Service.Mode.MESSAGE);

However, except the support of Source, I do not think there is anything wrong within our current
implementation, both "public class MyService implements Provider<DOMSource>" and "Dispatch<DOMSource>
disp = service.createDispatch(portName, DOMSource.class, Service.Mode.MESSAGE);" are valid
use cases according to spec. Spec only says "A Provider based service endpoint implementation
MUST implement a typed Provider interface." and "A typed Provider interface is one in which
the type parameter has been bound to a concrete class, e.g. Provider<Source> or Provider<SOAPMessage>,",
using DOMSource/SAXSource/StreamSource should be allowed as they are implementations of Source
interface. Further more, using one of these Source implementations is more convenient because
you don't need to do the "if" block, see the code example above.



> >
> > ts an alright feature to support DOMSource & SAXSource for incoming
> > requests I suppose. Although I don't see much point in supporting
> > Provider<StreamSource> as that would be particularly 
> wasteful and of no
> > point. So I'm tempted to just remove our support for 
> specific Sources and
> > just send in whats most efficient.
> >
> > - Dan
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> 
> 
> 
> 
> -- 
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 

Mime
View raw message