"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:[EMAIL PROTECTED]
Sent: 2007?2?15? 2:31
To: [email protected]
Subject: Re: Provider & Dispatch usage
We also seem to support SOAPBody which is not in the spec AFAIK.
On 2/14/07, Dan Diephouse <[EMAIL PROTECTED]> 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
