cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject Re: Provider & Dispatch usage
Date Thu, 15 Feb 2007 11:04:21 GMT
"Digging into code, yes, we do not support Provider<Source>. An example of using Provider<Source>
should look like below, I 
believe..."


We have Provider<Source> implementations in our code...And it works for us...

Cheers, Sergey




> -----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