You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dan Diephouse <da...@envoisolutions.com> on 2007/01/10 16:16:17 UTC
Understanding Partial Responses [Re: Identification of Partial Responses]
Been trying to educate myself some more on this issue, and I'm remaining
stumped. I don't see any mentions of such a feature in the 2005/02 spec or
even in the latest WS-RX draft. Searching the web didn't reveal anything
really besides CXF/Celtix artifacts.
So I have another question in addition to my one below - what is the benefit
of partial responses? I remember someone citing performance benefits to me.
However this seems rather unlikely as SequenceAcknowledgment piggybacking
will be possible in most scenarios.
Even if your application consisted solely of one way messages, the only way
to do RM with decent performance is to only acknowledge every so often. An
HTTP connection back to the message sender is unlikely to be the performance
bottleneck. Especially when you factor in the sizes of the messages.
Acknowledgments are about as small as a message gets, and I would guess that
typically the application messages will be larger. Since XML parsing is
where the bottleneck is (HTTP introduces some latency which isn't an issue
for seqacks and represents maybe 20% of the raw time), doing a partial
response seems unlikely to have any net benefit.
What am I missing here?
- Dan
On 1/9/07, Dan Diephouse < dan@envoisolutions.com> wrote:
>
> So there aren't any distinguishing characteristics of a partial response?
> Are partial responses documented anywhere?
>
> Also, what other vendors are doing partial response?
>
> On 1/9/07, Andrea Smyth <an...@iona.com> wrote:
> >
> > Dan Diephouse wrote:
> >
> > > Quick question regarding #2 - Do other RM implementations include a
> > > RelatesTo header in partial responses?
> > >
> > > Also, could we determine if its a partial response by checking to see
> > > if the
> > > Action is a SequenceAcknowledgement?
> >
> > No, partial responses do not have the action set.
> > A message with action SequenceAcknowledgement indicates that the
> > underlying message is a oneway, and was issued by an RMSource
> > out-of-band (e.g. when a timer signals as opposed to when the client
> > makes an invocation/the server sends a response). It also has an empty
> > body (info is carried in the SequenceAcknowledgement header).
> > When SequenceAcknowledgemens are piggybacked on an application message (
> >
> > in case of anonymous AcksTo on partial responses, in case of acksTo==
> > replyTo on full responses), the action is that of the underlying
> > application message (null in case of partial responses).
> >
> > Andrea.
> >
> > >
> > > - Dan
> > >
> > > On 1/9/07, Glynn, Eoghan <eo...@iona.com> wrote:
> > >
> > >>
> > >>
> > >> OK, back to the drawing board on this one :(
> > >>
> > >> A quick google on this question suggests that, notwithstanding some
> > >> confusion, an empty SOAP body is actually kosher in certain
> > >> circumstances ... see for example [1].
> > >>
> > >> So off the top of my head, I think we'd have to do something like the
> > >> following to make the partial/full response distinction more
> > >> bullet-proof:
> > >>
> > >> 1. Stop sending the wsa:RelatesTo in the partial response (this is
> > >> potentially misleading in any case)
> > >> 2. Set something like a Message.IS_RESPONSE property to false in the
> > >> WS-A layer if the wsa:RelatesTo header is not present
> > >> 3. Replace the ClientImpl.isPartialResponse() logic with
> > >> Boolean.FALSE.equals(inMessage.get(Message.IS_RESPONSE))
> > >>
> > >> Checking via Boolean.FALSE.equals() would ensure that the ClientImpl
> > >> logic would be valid even if WS-A layer was absent (in which case the
> >
> > >> IS_RESPONSE property would be null, but we can assume that a partial
> > >> response would never be received, as this may only occur if WS-A
> > headers
> > >> were present in the corresponding request).
> > >>
> > >> Cheers,
> > >> Eoghan
> > >>
> > >> [1]
> > >> http://lists.jboss.org/pipermail/jbossws-issues/2006-October/000022.html
> >
> > >>
> > >>
> > >> > -----Original Message-----
> > >> > From: Andrea Smyth [mailto: andrea.smyth@iona.com]
> > >> > Sent: 09 January 2007 09:58
> > >> > To: cxf-dev@incubator.apache.org
> > >> > Subject: Identification of Partial Responses
> > >> >
> > >> > Further to the dicussions on the
> > >> > "JaxwsInterceptorRemoverInterceptor and RM" subject on the
> > >> > different ways to identify a partial response I came accross
> > >> > an example of application messages with empty soap bodies.
> > >> > This is in the
> > >> > org.apache.cxf.systest.basicDOCBare.DOCBareClientServerTest
> > >> > system test, where the response to the putLastTradedPrice
> > >> > invocation is a soap message with an empty body.
> > >> > Addressing is not involved.
> > >> > First off, is the empty ssoap body OK and to be expected?
> > >> > Secondly, if it is, what should I expect if this
> > >> > client-server setup uses addressing and non-anonymous
> > >> > ReplyTo? It seems we can distinguish the partial response
> > >> > from the real response not by checking for an empty body
> > >> > (regardless if this results in empty of no list content in the
> > >> > message) but need to look also at the addressing headers ...
> > >> > Any ideas?
> > >> >
> > >> > Andrea.
> > >> >
> > >>
> > >
> > >
> > >
> >
> >
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Attachment support in XML binding and ProviderChainObserver (Was
: Mime support...)
Posted by James Mao <ja...@iona.com>.
Hi,
> * In ProviderChainObserver::onMessage() explictly add
> AttachmentInInterceptors in front of the DispatchInInterceptor,
> simpliest solution possibly, but not generic.
>
> * clear away only those interceptors which are not instanceof certain
> AbstractInterceptor types so that interceptors to do with the
> (de)serializing, logging, etc can be left in the chain
>
> * Update base Interceptor interface to have a method like getType() or
> smth like that so that binding interceptors dealing with SEI
> invocatins can be removed...
>
The first approach is the easiest way. and also make sense.
Cheers,
James.
Re: Attachment support in XML binding and ProviderChainObserver (Was : Mime support...)
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
Would it suffice if I do this :
* In ProviderChainObserver::onMessage() explictly add AttachmentInInterceptors in front of the DispatchInInterceptor, simpliest solution possibly, but not generic
for a start ?
endpoint.getBinding().getInInterceptors().clear();
endpoint.getBinding().getInInterceptors().add(new AttachmentInInterceptor());
endpoint.getBinding().getInInterceptors().add(new DispatchInInterceptor());
With this change my test works just fine. Provider<Source> implementation gets the root part of the multipart/related body as a Source and then it can get any other remaining parts from MessageContext as a Map<String, DataHandler> by using MessageContext.INCOMING_MESSAGE_ATTACHMENTS.
Obviosuly for SOAP XML providers, they'll have to handle XOP root body themselves with xop:Includes, but this root part will passed to them as a Source and then they would be able to retrieve all the included parts form the Map...
I reckon having an explicit AttachmentInInterceptor() in ProviderChainObserver::onMessage() won't harm in . Without it, Provider<Source> implementaions just don't work if a multipart/related message is sent to them... Not a very big deal perhaps, as one can do Provider<DataSource> to get a non-XML input, but in this case multipart/related parts will have to be parsed manually...
Cheers, Sergey
Hi
Renamed the subject to better reflect the topic of this thread.
I've spent a bit of time trying to make a test verifyiing attachments can be handled by Provider<Source> implementations working and finally I found what seems to be the last
stumbling block.
As it happens, all in-interceptors for Provider-based endpoints, specifically the ones added at XMLBinding creation time, are cleared away in ProviderChainObserver::onMessage() :
endpoint.getBinding().getInInterceptors().clear();
endpoint.getBinding().getInInterceptors().add(new DispatchInInterceptor());
As Eoghan explained to me, this is in fact compatible with the JAX-WS spec, as Providers are willing to deal with Sources (XML) directly, so any XMLBinding interceptors required to serve SEI endpoints.
Unfortunately, the way it's done at the moment causes a problem in case of the attachments coming in a multpart/related package, simply because AttachmentInInterceptors required to deserialize the message properly so that a root part of the mutlipart/related package can be presented as a Source, is cleared away. Actually, as far as I understand, the same problem would apply to Provider<Source> provideres served by HTTPBinding.
So what would be the best way to solve this problem ? Several options are possible.
* In ProviderChainObserver::onMessage() explictly add AttachmentInInterceptors in front of the DispatchInInterceptor, simpliest solution possibly, but not generic.
* clear away only those interceptors which are not instanceof certain AbstractInterceptor types so that interceptors to do with the (de)serializing, logging, etc can be left in the chain
* Update base Interceptor interface to have a method like getType() or smth like that so that binding interceptors dealing with SEI invocatins can be removed...
I'd aprerciate some feedback on this.
By the way, I've just found that by implementing Provider<DataSource> (with Service.MODE=Message), I can actually get all the raw data coming in, be they in XMl or not XML format, and also I can serve GET requests by returning non-XML data. This is great. Only thing is that it's much handier to deal with Map<String, DataHandler> then parsing all the attchment stuff manually :-) so once the pacth is applied I'd consider doing Provider<Source>. Only minor issue is that text/xml is set as Content-Type all the time, but it's a minor issue indeed.
Cheers, Sergey
Hi
What's the recommended approach for setting uninitilzied properties in JAXWS.
For ex, if message.getAttachments() returns null then should I add an empty map as
a MessageContext.INBOUND_ATTACHMENT_VALUE ? I'd prefer adding the empty map,
this would probably be consistent with the way other similar values are being setup..but I can add nothing in case of unitialized attachments if it would more consistent with the way CXF inits properties...
Thanks, Sergey
> I'm fine with just throwing everything in the Map for now. We can create a
> LazyAttachmentMap later - having the functionality is most important part at
> this point :-) A JIRA for the LazyAttachmentMap would be great too. Thanks,
> - Dan
>
> On 1/23/07, Sergey Beryozkin <se...@iona.com> wrote:
>>
>> Hi
>>
>> I suppose we can have a unmodifyable Map<String, DataHandler>
>> implementation using Collection<Attachment> internally for
>> iterating/queries. I guess the only performance benefit we can get with it
>> is that the provider's invoke() can be hit without caching in all the
>> attachemnats first...But this I think is important when a provider can
>> proceed with handling the invocation without reading all the attachments it
>> may need first which may not always be possible...
>>
>> If you reckon it's a worthy idea (creating LazyAttachmentMap) then I can
>> create a JIRA specifically to address the performance issue resulting from
>> the fact that creating a HashMap<String, DataHandler> will lead to all
>> attachments be read through the LazyAttachmentCollection and then perhaps
>> look into it later, as at the moment I need to create a basic patch to
>> ensure attachements gets delivered to XMLBinding providers...
>>
>> Thanks, Sergey
>>
>>
>> >I think that JAX-WS specifies that it be typed as Map<String,DataHandler>
>> > not Collection<Attachment>. The key in the map would be the Content-ID.
>> So
>> > we would have to convert.
>> >
>> > This kills performance as it requires us to cache all the attachments
>> > (unlike JAXB where we can lazily load do to some hackish code :-)), but
>> > there isn't much I can do about that.
>> >
>> > - Dan
>> >
>> > On 1/22/07, Sergey Beryozkin <se...@iona.com> wrote:
>> >>
>> >> Hi
>> >>
>> >> Thanks for a hint. So I've added an AttachmentInInterceptor to the list
>> of
>> >> in-interceptors in the XMLBindingFactory.
>> >> As far as I can see after looking through the code the side-effect of
>> this
>> >> addition is that an implementation of org.apache.cxf.message.Messagewill
>> >> have a Collection<Attachment> set on it by the AttachmentDeserializer.
>> >>
>> >> Now the next problem to solve is how to make this collection visible to
>> >> Provider<Source> implementations as they only see a
>> >> javax.xml.ws.handler.MessageContext. I can see
>> >> org.apache.cxf.jaxws.support.ContextPropertiesMapping, and it's there
>> >> where a MessageContext is created, in createWebServiceContext(Exchange
>> >> exchange).
>> >>
>> >> So in this method I've just added
>> >>
>> >> ctx.put(MessageContext.INBOUND_MESSAGE_ATTACHMENTS,
>> >> exchange.getInMessage().getAttachments());
>> >>
>> >> so that the incoming attachments if any can be visible to Provider
>> impls.
>> >>
>> >> I reckon that's all I need. Any comments/corrections would be
>> >> appreciated...
>> >>
>> >> Thanks, Sergey
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ----- Original Message -----
>> >> From: "Dan Diephouse" <da...@envoisolutions.com>
>> >> To: <cx...@incubator.apache.org>
>> >> Sent: Friday, January 12, 2007 8:47 PM
>> >> Subject: Re: MIME support in XML binding
>> >>
>> >>
>> >> > It shouldn't be too hard to support MIME with the XML binding. I
>> added
>> >> in
>> >> > the attachment interceptors to the HTTP binding so I've already
>> gotten
>> >> MIME
>> >> > over HTTP with no SOAP working. I think the main thing it requires is
>> >> adding
>> >> > the interceptors to the XMLBindingFactory.
>> >> >
>> >>
>> >>
>> >
>> >
>> > --
>> > Dan Diephouse
>> > Envoi Solutions
>> > http://envoisolutions.com | http://netzooid.com/blog
>> >
>>
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Attachment support in XML binding and ProviderChainObserver (Was : Mime support...)
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
Renamed the subject to better reflect the topic of this thread.
I've spent a bit of time trying to make a test verifyiing attachments can be handled by Provider<Source> implementations working and finally I found what seems to be the last
stumbling block.
As it happens, all in-interceptors for Provider-based endpoints, specifically the ones added at XMLBinding creation time, are cleared away in ProviderChainObserver::onMessage() :
endpoint.getBinding().getInInterceptors().clear();
endpoint.getBinding().getInInterceptors().add(new DispatchInInterceptor());
As Eoghan explained to me, this is in fact compatible with the JAX-WS spec, as Providers are willing to deal with Sources (XML) directly, so any XMLBinding interceptors required to serve SEI endpoints.
Unfortunately, the way it's done at the moment causes a problem in case of the attachments coming in a multpart/related package, simply because AttachmentInInterceptors required to deserialize the message properly so that a root part of the mutlipart/related package can be presented as a Source, is cleared away. Actually, as far as I understand, the same problem would apply to Provider<Source> provideres served by HTTPBinding.
So what would be the best way to solve this problem ? Several options are possible.
* In ProviderChainObserver::onMessage() explictly add AttachmentInInterceptors in front of the DispatchInInterceptor, simpliest solution possibly, but not generic.
* clear away only those interceptors which are not instanceof certain AbstractInterceptor types so that interceptors to do with the (de)serializing, logging, etc can be left in the chain
* Update base Interceptor interface to have a method like getType() or smth like that so that binding interceptors dealing with SEI invocatins can be removed...
I'd aprerciate some feedback on this.
By the way, I've just found that by implementing Provider<DataSource> (with Service.MODE=Message), I can actually get all the raw data coming in, be they in XMl or not XML format, and also I can serve GET requests by returning non-XML data. This is great. Only thing is that it's much handier to deal with Map<String, DataHandler> then parsing all the attchment stuff manually :-) so once the pacth is applied I'd consider doing Provider<Source>. Only minor issue is that text/xml is set as Content-Type all the time, but it's a minor issue indeed.
Cheers, Sergey
Hi
What's the recommended approach for setting uninitilzied properties in JAXWS.
For ex, if message.getAttachments() returns null then should I add an empty map as
a MessageContext.INBOUND_ATTACHMENT_VALUE ? I'd prefer adding the empty map,
this would probably be consistent with the way other similar values are being setup..but I can add nothing in case of unitialized attachments if it would more consistent with the way CXF inits properties...
Thanks, Sergey
> I'm fine with just throwing everything in the Map for now. We can create a
> LazyAttachmentMap later - having the functionality is most important part at
> this point :-) A JIRA for the LazyAttachmentMap would be great too. Thanks,
> - Dan
>
> On 1/23/07, Sergey Beryozkin <se...@iona.com> wrote:
>>
>> Hi
>>
>> I suppose we can have a unmodifyable Map<String, DataHandler>
>> implementation using Collection<Attachment> internally for
>> iterating/queries. I guess the only performance benefit we can get with it
>> is that the provider's invoke() can be hit without caching in all the
>> attachemnats first...But this I think is important when a provider can
>> proceed with handling the invocation without reading all the attachments it
>> may need first which may not always be possible...
>>
>> If you reckon it's a worthy idea (creating LazyAttachmentMap) then I can
>> create a JIRA specifically to address the performance issue resulting from
>> the fact that creating a HashMap<String, DataHandler> will lead to all
>> attachments be read through the LazyAttachmentCollection and then perhaps
>> look into it later, as at the moment I need to create a basic patch to
>> ensure attachements gets delivered to XMLBinding providers...
>>
>> Thanks, Sergey
>>
>>
>> >I think that JAX-WS specifies that it be typed as Map<String,DataHandler>
>> > not Collection<Attachment>. The key in the map would be the Content-ID.
>> So
>> > we would have to convert.
>> >
>> > This kills performance as it requires us to cache all the attachments
>> > (unlike JAXB where we can lazily load do to some hackish code :-)), but
>> > there isn't much I can do about that.
>> >
>> > - Dan
>> >
>> > On 1/22/07, Sergey Beryozkin <se...@iona.com> wrote:
>> >>
>> >> Hi
>> >>
>> >> Thanks for a hint. So I've added an AttachmentInInterceptor to the list
>> of
>> >> in-interceptors in the XMLBindingFactory.
>> >> As far as I can see after looking through the code the side-effect of
>> this
>> >> addition is that an implementation of org.apache.cxf.message.Messagewill
>> >> have a Collection<Attachment> set on it by the AttachmentDeserializer.
>> >>
>> >> Now the next problem to solve is how to make this collection visible to
>> >> Provider<Source> implementations as they only see a
>> >> javax.xml.ws.handler.MessageContext. I can see
>> >> org.apache.cxf.jaxws.support.ContextPropertiesMapping, and it's there
>> >> where a MessageContext is created, in createWebServiceContext(Exchange
>> >> exchange).
>> >>
>> >> So in this method I've just added
>> >>
>> >> ctx.put(MessageContext.INBOUND_MESSAGE_ATTACHMENTS,
>> >> exchange.getInMessage().getAttachments());
>> >>
>> >> so that the incoming attachments if any can be visible to Provider
>> impls.
>> >>
>> >> I reckon that's all I need. Any comments/corrections would be
>> >> appreciated...
>> >>
>> >> Thanks, Sergey
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ----- Original Message -----
>> >> From: "Dan Diephouse" <da...@envoisolutions.com>
>> >> To: <cx...@incubator.apache.org>
>> >> Sent: Friday, January 12, 2007 8:47 PM
>> >> Subject: Re: MIME support in XML binding
>> >>
>> >>
>> >> > It shouldn't be too hard to support MIME with the XML binding. I
>> added
>> >> in
>> >> > the attachment interceptors to the HTTP binding so I've already
>> gotten
>> >> MIME
>> >> > over HTTP with no SOAP working. I think the main thing it requires is
>> >> adding
>> >> > the interceptors to the XMLBindingFactory.
>> >> >
>> >>
>> >>
>> >
>> >
>> > --
>> > Dan Diephouse
>> > Envoi Solutions
>> > http://envoisolutions.com | http://netzooid.com/blog
>> >
>>
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Difference between XML and HTTP bindings
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Dan
Ok, thanks for the explanation and for the code sample.
I've just discovered that by implementing Provider<DataSource> (ServiceMode = Message) I can retrieve binary/XML data as is using GET, it was a nice surprize, but a bit unusual :-)...
On the example itself :
> EndpointInfo ei = new EndpointInfo();
> ei.setAddress("http://localhost:8080/test.html");
Would this work if I do it like this (with a stem mode) :
> ei.setAddress(http://localhost:8080/data);
and then in
> public void onMessage(Message message) {
server requests like
http://localhost:8080/data/my.jpeg
http://localhost:8080/data/my.bmp ?
> thought about it too much quite yet. Are you interested in helping with this
> feature? I will put together some thoughts and help out if so...
Lets get the conversation started :-). Would it be HTTPBinding which would have to updated slightly to help providers willing to just get input and output streams and deal with them, and such that they don't see the details like the ones shown in your example ? Or will it be done similar to your example below, without bindings involved ? What kind of interface such providers will implement ?
Thanks, Sergey
> Hi Sergey,
>
> The XMLBinding was designed with transporting xml over any transport. The
> HTTP Binding is focused on ways to build RESTful services over HTTP only. I
> wrote some documentation on it here:
>
> http://cwiki.apache.org/confluence/display/CXF20DOC/HTTP+Binding
>
> So you're looking for ways to serve non-xml content - i.e return a JPEG on a
> GET request? I would absolutely love this feature. It requires a bit of work
> to our databinding code to make this work, and to be honest I haven't
> thought about it too much quite yet. Are you interested in helping with this
> feature? I will put together some thoughts and help out if so...
>
> FWIW I have written code to serve out static resources on the HTTP Transport
> before. Here it is if you're interested:
>
> private static void serveHTML() throws Exception {
> Bus bus = BusFactoryHelper.newInstance().getDefaultBus();
> DestinationFactoryManager dfm = bus.getExtension(
> DestinationFactoryManager.class);
> DestinationFactory df = dfm.getDestinationFactory("
> http://cxf.apache.org/transports/http/configuration");
>
> EndpointInfo ei = new EndpointInfo();
> ei.setAddress("http://localhost:8080/test.html");
>
> Destination d = df.getDestination(ei);
> d.setMessageObserver(new MessageObserver() {
>
> public void onMessage(Message message) {
> try {
> // HTTP seems to need this right now...
> ExchangeImpl ex = new ExchangeImpl();
> ex.setInMessage(message);
>
> Conduit backChannel = message.getDestination().
> getBackChannel(message, null, null);
>
> MessageImpl res = new MessageImpl();
> res.put(Message.CONTENT_TYPE, "text/html");
> backChannel.send(res);
>
> OutputStream out = res.getContent(OutputStream.class);
> FileInputStream is = new FileInputStream("test.html");
> IOUtils.copy(is, out, 2048);
>
> out.flush();
>
> out.close();
> is.close();
>
> backChannel.close(res);
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
>
> });
> }
>
> - Dan
>
> On 1/25/07, Sergey Beryozkin <se...@iona.com> wrote:
>>
>> Hi,
>>
>> Just thinking aloud... So it appears there's no difference between these
>> bindings, right ?
>> Would it make sense to differentiate between them like this :
>>
>> * XMLBinding : used by Provider<Source> providers. Specifically GET
>> requests are served by returning Source (XMLs).
>>
>> * HTTPBinding : providers are dealing with request InputStream, response
>> OutputStream directly.
>>
>> They implement an interface like handleRequest(InputData, ResponseData),
>> where InputData/ResponseData encapsulate the underlying engine's details so
>> that such providers can run on Jetty/Tomcat/etc...
>>
>> For ex, I need a provider which saves (binary) attachments and then can
>> serve them through simple GET requests issued from browsers, etc.. I can
>> implement an XMLBinding (HTTPBinding) provider, but this provider can not
>> handle GET requests which would just return some non-XML data. Well, it can
>> return XOP multipart/related packages, but that is not something I need.
>>
>> Any thoughts ?
>>
>> Thanks, Sergey
>>
>>
>> Hi
>>
>> What is the difference between XML and HTTP bindings from the perspective
>> of the provider and the client ?
>> I'm looking at the org.apache.cxf.systest.test , I can see
>> RestSourcePayloadProvider and RestSourcePayloadProviderHTTPBinding
>> providers, both are absolutely identical except that the former one has one
>> extra annotation,
>> @javax.xml.ws.BindingType(value = http://cxf.apache.org/bindings/xformat)
>>
>> Corresponding test clients exercising these both providers are absoultely
>> identical between each other. Are there any subtle differences ?
>>
>> Thanks, Sergey
>>
>>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Difference between XML and HTTP bindings
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi Sergey,
The XMLBinding was designed with transporting xml over any transport. The
HTTP Binding is focused on ways to build RESTful services over HTTP only. I
wrote some documentation on it here:
http://cwiki.apache.org/confluence/display/CXF20DOC/HTTP+Binding
So you're looking for ways to serve non-xml content - i.e return a JPEG on a
GET request? I would absolutely love this feature. It requires a bit of work
to our databinding code to make this work, and to be honest I haven't
thought about it too much quite yet. Are you interested in helping with this
feature? I will put together some thoughts and help out if so...
FWIW I have written code to serve out static resources on the HTTP Transport
before. Here it is if you're interested:
private static void serveHTML() throws Exception {
Bus bus = BusFactoryHelper.newInstance().getDefaultBus();
DestinationFactoryManager dfm = bus.getExtension(
DestinationFactoryManager.class);
DestinationFactory df = dfm.getDestinationFactory("
http://cxf.apache.org/transports/http/configuration");
EndpointInfo ei = new EndpointInfo();
ei.setAddress("http://localhost:8080/test.html");
Destination d = df.getDestination(ei);
d.setMessageObserver(new MessageObserver() {
public void onMessage(Message message) {
try {
// HTTP seems to need this right now...
ExchangeImpl ex = new ExchangeImpl();
ex.setInMessage(message);
Conduit backChannel = message.getDestination().
getBackChannel(message, null, null);
MessageImpl res = new MessageImpl();
res.put(Message.CONTENT_TYPE, "text/html");
backChannel.send(res);
OutputStream out = res.getContent(OutputStream.class);
FileInputStream is = new FileInputStream("test.html");
IOUtils.copy(is, out, 2048);
out.flush();
out.close();
is.close();
backChannel.close(res);
} catch (Exception e) {
e.printStackTrace();
}
}
});
}
- Dan
On 1/25/07, Sergey Beryozkin <se...@iona.com> wrote:
>
> Hi,
>
> Just thinking aloud... So it appears there's no difference between these
> bindings, right ?
> Would it make sense to differentiate between them like this :
>
> * XMLBinding : used by Provider<Source> providers. Specifically GET
> requests are served by returning Source (XMLs).
>
> * HTTPBinding : providers are dealing with request InputStream, response
> OutputStream directly.
>
> They implement an interface like handleRequest(InputData, ResponseData),
> where InputData/ResponseData encapsulate the underlying engine's details so
> that such providers can run on Jetty/Tomcat/etc...
>
> For ex, I need a provider which saves (binary) attachments and then can
> serve them through simple GET requests issued from browsers, etc.. I can
> implement an XMLBinding (HTTPBinding) provider, but this provider can not
> handle GET requests which would just return some non-XML data. Well, it can
> return XOP multipart/related packages, but that is not something I need.
>
> Any thoughts ?
>
> Thanks, Sergey
>
>
> Hi
>
> What is the difference between XML and HTTP bindings from the perspective
> of the provider and the client ?
> I'm looking at the org.apache.cxf.systest.test , I can see
> RestSourcePayloadProvider and RestSourcePayloadProviderHTTPBinding
> providers, both are absolutely identical except that the former one has one
> extra annotation,
> @javax.xml.ws.BindingType(value = http://cxf.apache.org/bindings/xformat)
>
> Corresponding test clients exercising these both providers are absoultely
> identical between each other. Are there any subtle differences ?
>
> Thanks, Sergey
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Difference between XML and HTTP bindings
Posted by Sergey Beryozkin <se...@iona.com>.
Hi,
Just thinking aloud... So it appears there's no difference between these bindings, right ?
Would it make sense to differentiate between them like this :
* XMLBinding : used by Provider<Source> providers. Specifically GET requests are served by returning Source (XMLs).
* HTTPBinding : providers are dealing with request InputStream, response OutputStream directly.
They implement an interface like handleRequest(InputData, ResponseData), where InputData/ResponseData encapsulate the underlying engine's details so that such providers can run on Jetty/Tomcat/etc...
For ex, I need a provider which saves (binary) attachments and then can serve them through simple GET requests issued from browsers, etc.. I can implement an XMLBinding (HTTPBinding) provider, but this provider can not handle GET requests which would just return some non-XML data. Well, it can return XOP multipart/related packages, but that is not something I need.
Any thoughts ?
Thanks, Sergey
Hi
What is the difference between XML and HTTP bindings from the perspective of the provider and the client ?
I'm looking at the org.apache.cxf.systest.test, I can see RestSourcePayloadProvider and RestSourcePayloadProviderHTTPBinding providers, both are absolutely identical except that the former one has one extra annotation,
@javax.xml.ws.BindingType(value = http://cxf.apache.org/bindings/xformat)
Corresponding test clients exercising these both providers are absoultely identical between each other. Are there any subtle differences ?
Thanks, Sergey
Difference between XML and HTTP bindings
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
What is the difference between XML and HTTP bindings from the perspective of the provider and the client ?
I'm looking at the org.apache.cxf.systest.test, I can see RestSourcePayloadProvider and RestSourcePayloadProviderHTTPBinding providers, both are absolutely identical except that the former one has one extra annotation,
@javax.xml.ws.BindingType(value = http://cxf.apache.org/bindings/xformat)
Corresponding test clients exercising these both providers are absoultely identical between each other. Are there any subtle differences ?
Thanks, Sergey
Re: MIME support in XML binding
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
What's the recommended approach for setting uninitilzied properties in JAXWS.
For ex, if message.getAttachments() returns null then should I add an empty map as
a MessageContext.INBOUND_ATTACHMENT_VALUE ? I'd prefer adding the empty map,
this would probably be consistent with the way other similar values are being setup..but I can add nothing in case of unitialized attachments if it would more consistent with the way CXF inits properties...
Thanks, Sergey
> I'm fine with just throwing everything in the Map for now. We can create a
> LazyAttachmentMap later - having the functionality is most important part at
> this point :-) A JIRA for the LazyAttachmentMap would be great too. Thanks,
> - Dan
>
> On 1/23/07, Sergey Beryozkin <se...@iona.com> wrote:
>>
>> Hi
>>
>> I suppose we can have a unmodifyable Map<String, DataHandler>
>> implementation using Collection<Attachment> internally for
>> iterating/queries. I guess the only performance benefit we can get with it
>> is that the provider's invoke() can be hit without caching in all the
>> attachemnats first...But this I think is important when a provider can
>> proceed with handling the invocation without reading all the attachments it
>> may need first which may not always be possible...
>>
>> If you reckon it's a worthy idea (creating LazyAttachmentMap) then I can
>> create a JIRA specifically to address the performance issue resulting from
>> the fact that creating a HashMap<String, DataHandler> will lead to all
>> attachments be read through the LazyAttachmentCollection and then perhaps
>> look into it later, as at the moment I need to create a basic patch to
>> ensure attachements gets delivered to XMLBinding providers...
>>
>> Thanks, Sergey
>>
>>
>> >I think that JAX-WS specifies that it be typed as Map<String,DataHandler>
>> > not Collection<Attachment>. The key in the map would be the Content-ID.
>> So
>> > we would have to convert.
>> >
>> > This kills performance as it requires us to cache all the attachments
>> > (unlike JAXB where we can lazily load do to some hackish code :-)), but
>> > there isn't much I can do about that.
>> >
>> > - Dan
>> >
>> > On 1/22/07, Sergey Beryozkin <se...@iona.com> wrote:
>> >>
>> >> Hi
>> >>
>> >> Thanks for a hint. So I've added an AttachmentInInterceptor to the list
>> of
>> >> in-interceptors in the XMLBindingFactory.
>> >> As far as I can see after looking through the code the side-effect of
>> this
>> >> addition is that an implementation of org.apache.cxf.message.Messagewill
>> >> have a Collection<Attachment> set on it by the AttachmentDeserializer.
>> >>
>> >> Now the next problem to solve is how to make this collection visible to
>> >> Provider<Source> implementations as they only see a
>> >> javax.xml.ws.handler.MessageContext. I can see
>> >> org.apache.cxf.jaxws.support.ContextPropertiesMapping, and it's there
>> >> where a MessageContext is created, in createWebServiceContext(Exchange
>> >> exchange).
>> >>
>> >> So in this method I've just added
>> >>
>> >> ctx.put(MessageContext.INBOUND_MESSAGE_ATTACHMENTS,
>> >> exchange.getInMessage().getAttachments());
>> >>
>> >> so that the incoming attachments if any can be visible to Provider
>> impls.
>> >>
>> >> I reckon that's all I need. Any comments/corrections would be
>> >> appreciated...
>> >>
>> >> Thanks, Sergey
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ----- Original Message -----
>> >> From: "Dan Diephouse" <da...@envoisolutions.com>
>> >> To: <cx...@incubator.apache.org>
>> >> Sent: Friday, January 12, 2007 8:47 PM
>> >> Subject: Re: MIME support in XML binding
>> >>
>> >>
>> >> > It shouldn't be too hard to support MIME with the XML binding. I
>> added
>> >> in
>> >> > the attachment interceptors to the HTTP binding so I've already
>> gotten
>> >> MIME
>> >> > over HTTP with no SOAP working. I think the main thing it requires is
>> >> adding
>> >> > the interceptors to the XMLBindingFactory.
>> >> >
>> >>
>> >>
>> >
>> >
>> > --
>> > Dan Diephouse
>> > Envoi Solutions
>> > http://envoisolutions.com | http://netzooid.com/blog
>> >
>>
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: MIME support in XML binding
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
As promised here's the issue to track a LazyAttachmentMap :
https://issues.apache.org/jira/browse/CXF-422
Cheers, Sergey
> I'm fine with just throwing everything in the Map for now. We can create a
> LazyAttachmentMap later - having the functionality is most important part at
> this point :-) A JIRA for the LazyAttachmentMap would be great too. Thanks,
> - Dan
>
> On 1/23/07, Sergey Beryozkin <se...@iona.com> wrote:
>>
>> Hi
>>
>> I suppose we can have a unmodifyable Map<String, DataHandler>
>> implementation using Collection<Attachment> internally for
>> iterating/queries. I guess the only performance benefit we can get with it
>> is that the provider's invoke() can be hit without caching in all the
>> attachemnats first...But this I think is important when a provider can
>> proceed with handling the invocation without reading all the attachments it
>> may need first which may not always be possible...
>>
>> If you reckon it's a worthy idea (creating LazyAttachmentMap) then I can
>> create a JIRA specifically to address the performance issue resulting from
>> the fact that creating a HashMap<String, DataHandler> will lead to all
>> attachments be read through the LazyAttachmentCollection and then perhaps
>> look into it later, as at the moment I need to create a basic patch to
>> ensure attachements gets delivered to XMLBinding providers...
>>
>> Thanks, Sergey
>>
>>
>> >I think that JAX-WS specifies that it be typed as Map<String,DataHandler>
>> > not Collection<Attachment>. The key in the map would be the Content-ID.
>> So
>> > we would have to convert.
>> >
>> > This kills performance as it requires us to cache all the attachments
>> > (unlike JAXB where we can lazily load do to some hackish code :-)), but
>> > there isn't much I can do about that.
>> >
>> > - Dan
>> >
>> > On 1/22/07, Sergey Beryozkin <se...@iona.com> wrote:
>> >>
>> >> Hi
>> >>
>> >> Thanks for a hint. So I've added an AttachmentInInterceptor to the list
>> of
>> >> in-interceptors in the XMLBindingFactory.
>> >> As far as I can see after looking through the code the side-effect of
>> this
>> >> addition is that an implementation of org.apache.cxf.message.Messagewill
>> >> have a Collection<Attachment> set on it by the AttachmentDeserializer.
>> >>
>> >> Now the next problem to solve is how to make this collection visible to
>> >> Provider<Source> implementations as they only see a
>> >> javax.xml.ws.handler.MessageContext. I can see
>> >> org.apache.cxf.jaxws.support.ContextPropertiesMapping, and it's there
>> >> where a MessageContext is created, in createWebServiceContext(Exchange
>> >> exchange).
>> >>
>> >> So in this method I've just added
>> >>
>> >> ctx.put(MessageContext.INBOUND_MESSAGE_ATTACHMENTS,
>> >> exchange.getInMessage().getAttachments());
>> >>
>> >> so that the incoming attachments if any can be visible to Provider
>> impls.
>> >>
>> >> I reckon that's all I need. Any comments/corrections would be
>> >> appreciated...
>> >>
>> >> Thanks, Sergey
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ----- Original Message -----
>> >> From: "Dan Diephouse" <da...@envoisolutions.com>
>> >> To: <cx...@incubator.apache.org>
>> >> Sent: Friday, January 12, 2007 8:47 PM
>> >> Subject: Re: MIME support in XML binding
>> >>
>> >>
>> >> > It shouldn't be too hard to support MIME with the XML binding. I
>> added
>> >> in
>> >> > the attachment interceptors to the HTTP binding so I've already
>> gotten
>> >> MIME
>> >> > over HTTP with no SOAP working. I think the main thing it requires is
>> >> adding
>> >> > the interceptors to the XMLBindingFactory.
>> >> >
>> >>
>> >>
>> >
>> >
>> > --
>> > Dan Diephouse
>> > Envoi Solutions
>> > http://envoisolutions.com | http://netzooid.com/blog
>> >
>>
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: MIME support in XML binding
Posted by Dan Diephouse <da...@envoisolutions.com>.
I'm fine with just throwing everything in the Map for now. We can create a
LazyAttachmentMap later - having the functionality is most important part at
this point :-) A JIRA for the LazyAttachmentMap would be great too. Thanks,
- Dan
On 1/23/07, Sergey Beryozkin <se...@iona.com> wrote:
>
> Hi
>
> I suppose we can have a unmodifyable Map<String, DataHandler>
> implementation using Collection<Attachment> internally for
> iterating/queries. I guess the only performance benefit we can get with it
> is that the provider's invoke() can be hit without caching in all the
> attachemnats first...But this I think is important when a provider can
> proceed with handling the invocation without reading all the attachments it
> may need first which may not always be possible...
>
> If you reckon it's a worthy idea (creating LazyAttachmentMap) then I can
> create a JIRA specifically to address the performance issue resulting from
> the fact that creating a HashMap<String, DataHandler> will lead to all
> attachments be read through the LazyAttachmentCollection and then perhaps
> look into it later, as at the moment I need to create a basic patch to
> ensure attachements gets delivered to XMLBinding providers...
>
> Thanks, Sergey
>
>
> >I think that JAX-WS specifies that it be typed as Map<String,DataHandler>
> > not Collection<Attachment>. The key in the map would be the Content-ID.
> So
> > we would have to convert.
> >
> > This kills performance as it requires us to cache all the attachments
> > (unlike JAXB where we can lazily load do to some hackish code :-)), but
> > there isn't much I can do about that.
> >
> > - Dan
> >
> > On 1/22/07, Sergey Beryozkin <se...@iona.com> wrote:
> >>
> >> Hi
> >>
> >> Thanks for a hint. So I've added an AttachmentInInterceptor to the list
> of
> >> in-interceptors in the XMLBindingFactory.
> >> As far as I can see after looking through the code the side-effect of
> this
> >> addition is that an implementation of org.apache.cxf.message.Messagewill
> >> have a Collection<Attachment> set on it by the AttachmentDeserializer.
> >>
> >> Now the next problem to solve is how to make this collection visible to
> >> Provider<Source> implementations as they only see a
> >> javax.xml.ws.handler.MessageContext. I can see
> >> org.apache.cxf.jaxws.support.ContextPropertiesMapping, and it's there
> >> where a MessageContext is created, in createWebServiceContext(Exchange
> >> exchange).
> >>
> >> So in this method I've just added
> >>
> >> ctx.put(MessageContext.INBOUND_MESSAGE_ATTACHMENTS,
> >> exchange.getInMessage().getAttachments());
> >>
> >> so that the incoming attachments if any can be visible to Provider
> impls.
> >>
> >> I reckon that's all I need. Any comments/corrections would be
> >> appreciated...
> >>
> >> Thanks, Sergey
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ----- Original Message -----
> >> From: "Dan Diephouse" <da...@envoisolutions.com>
> >> To: <cx...@incubator.apache.org>
> >> Sent: Friday, January 12, 2007 8:47 PM
> >> Subject: Re: MIME support in XML binding
> >>
> >>
> >> > It shouldn't be too hard to support MIME with the XML binding. I
> added
> >> in
> >> > the attachment interceptors to the HTTP binding so I've already
> gotten
> >> MIME
> >> > over HTTP with no SOAP working. I think the main thing it requires is
> >> adding
> >> > the interceptors to the XMLBindingFactory.
> >> >
> >>
> >>
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: MIME support in XML binding
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
I suppose we can have a unmodifyable Map<String, DataHandler> implementation using Collection<Attachment> internally for iterating/queries. I guess the only performance benefit we can get with it is that the provider's invoke() can be hit without caching in all the attachemnats first...But this I think is important when a provider can proceed with handling the invocation without reading all the attachments it may need first which may not always be possible...
If you reckon it's a worthy idea (creating LazyAttachmentMap) then I can create a JIRA specifically to address the performance issue resulting from the fact that creating a HashMap<String, DataHandler> will lead to all attachments be read through the LazyAttachmentCollection and then perhaps look into it later, as at the moment I need to create a basic patch to ensure attachements gets delivered to XMLBinding providers...
Thanks, Sergey
>I think that JAX-WS specifies that it be typed as Map<String,DataHandler>
> not Collection<Attachment>. The key in the map would be the Content-ID. So
> we would have to convert.
>
> This kills performance as it requires us to cache all the attachments
> (unlike JAXB where we can lazily load do to some hackish code :-)), but
> there isn't much I can do about that.
>
> - Dan
>
> On 1/22/07, Sergey Beryozkin <se...@iona.com> wrote:
>>
>> Hi
>>
>> Thanks for a hint. So I've added an AttachmentInInterceptor to the list of
>> in-interceptors in the XMLBindingFactory.
>> As far as I can see after looking through the code the side-effect of this
>> addition is that an implementation of org.apache.cxf.message.Message will
>> have a Collection<Attachment> set on it by the AttachmentDeserializer.
>>
>> Now the next problem to solve is how to make this collection visible to
>> Provider<Source> implementations as they only see a
>> javax.xml.ws.handler.MessageContext. I can see
>> org.apache.cxf.jaxws.support.ContextPropertiesMapping, and it's there
>> where a MessageContext is created, in createWebServiceContext(Exchange
>> exchange).
>>
>> So in this method I've just added
>>
>> ctx.put(MessageContext.INBOUND_MESSAGE_ATTACHMENTS,
>> exchange.getInMessage().getAttachments());
>>
>> so that the incoming attachments if any can be visible to Provider impls.
>>
>> I reckon that's all I need. Any comments/corrections would be
>> appreciated...
>>
>> Thanks, Sergey
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> From: "Dan Diephouse" <da...@envoisolutions.com>
>> To: <cx...@incubator.apache.org>
>> Sent: Friday, January 12, 2007 8:47 PM
>> Subject: Re: MIME support in XML binding
>>
>>
>> > It shouldn't be too hard to support MIME with the XML binding. I added
>> in
>> > the attachment interceptors to the HTTP binding so I've already gotten
>> MIME
>> > over HTTP with no SOAP working. I think the main thing it requires is
>> adding
>> > the interceptors to the XMLBindingFactory.
>> >
>>
>>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: MIME support in XML binding
Posted by Dan Diephouse <da...@envoisolutions.com>.
I think that JAX-WS specifies that it be typed as Map<String,DataHandler>
not Collection<Attachment>. The key in the map would be the Content-ID. So
we would have to convert.
This kills performance as it requires us to cache all the attachments
(unlike JAXB where we can lazily load do to some hackish code :-)), but
there isn't much I can do about that.
- Dan
On 1/22/07, Sergey Beryozkin <se...@iona.com> wrote:
>
> Hi
>
> Thanks for a hint. So I've added an AttachmentInInterceptor to the list of
> in-interceptors in the XMLBindingFactory.
> As far as I can see after looking through the code the side-effect of this
> addition is that an implementation of org.apache.cxf.message.Message will
> have a Collection<Attachment> set on it by the AttachmentDeserializer.
>
> Now the next problem to solve is how to make this collection visible to
> Provider<Source> implementations as they only see a
> javax.xml.ws.handler.MessageContext. I can see
> org.apache.cxf.jaxws.support.ContextPropertiesMapping, and it's there
> where a MessageContext is created, in createWebServiceContext(Exchange
> exchange).
>
> So in this method I've just added
>
> ctx.put(MessageContext.INBOUND_MESSAGE_ATTACHMENTS,
> exchange.getInMessage().getAttachments());
>
> so that the incoming attachments if any can be visible to Provider impls.
>
> I reckon that's all I need. Any comments/corrections would be
> appreciated...
>
> Thanks, Sergey
>
>
>
>
>
>
>
>
>
> ----- Original Message -----
> From: "Dan Diephouse" <da...@envoisolutions.com>
> To: <cx...@incubator.apache.org>
> Sent: Friday, January 12, 2007 8:47 PM
> Subject: Re: MIME support in XML binding
>
>
> > It shouldn't be too hard to support MIME with the XML binding. I added
> in
> > the attachment interceptors to the HTTP binding so I've already gotten
> MIME
> > over HTTP with no SOAP working. I think the main thing it requires is
> adding
> > the interceptors to the XMLBindingFactory.
> >
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: MIME support in XML binding
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
Thanks for a hint. So I've added an AttachmentInInterceptor to the list of in-interceptors in the XMLBindingFactory.
As far as I can see after looking through the code the side-effect of this addition is that an implementation of org.apache.cxf.message.Message will have a Collection<Attachment> set on it by the AttachmentDeserializer.
Now the next problem to solve is how to make this collection visible to Provider<Source> implementations as they only see a javax.xml.ws.handler.MessageContext. I can see org.apache.cxf.jaxws.support.ContextPropertiesMapping, and it's there where a MessageContext is created, in createWebServiceContext(Exchange exchange).
So in this method I've just added
ctx.put(MessageContext.INBOUND_MESSAGE_ATTACHMENTS,
exchange.getInMessage().getAttachments());
so that the incoming attachments if any can be visible to Provider impls.
I reckon that's all I need. Any comments/corrections would be appreciated...
Thanks, Sergey
----- Original Message -----
From: "Dan Diephouse" <da...@envoisolutions.com>
To: <cx...@incubator.apache.org>
Sent: Friday, January 12, 2007 8:47 PM
Subject: Re: MIME support in XML binding
> It shouldn't be too hard to support MIME with the XML binding. I added in
> the attachment interceptors to the HTTP binding so I've already gotten MIME
> over HTTP with no SOAP working. I think the main thing it requires is adding
> the interceptors to the XMLBindingFactory.
>
Re: MIME support in XML binding
Posted by Dan Diephouse <da...@envoisolutions.com>.
It shouldn't be too hard to support MIME with the XML binding. I added in
the attachment interceptors to the HTTP binding so I've already gotten MIME
over HTTP with no SOAP working. I think the main thing it requires is adding
the interceptors to the XMLBindingFactory.
On 1/10/07, Sergey Beryozkin <se...@iona.com> wrote:
>
> Hi
>
> Is there any support available in CXF for letting XML Binding providers
> receive/handle MIME attachments ?
> We jave providers implementing a Provider<Source> interface, but the
> invoke has as just MessageContext and Source available...Now we also have a
> @ServiceMode annotation with a value Service.Mode.PAYLOAD...
>
> As far as I understand from reading JAX-WS docs, we should have
> Provider<DataSource> and Service.Mode.MESSAGE for mime attachements to be
> received...The question is whether it will work for XMLBinding or not. If
> not then what would be required to apply a patch ? (Hopefully at least the
> last question is appropriate for the dev list :-))
>
> Thanks, Sergey
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
MIME support in XML binding
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
Is there any support available in CXF for letting XML Binding providers receive/handle MIME attachments ?
We jave providers implementing a Provider<Source> interface, but the invoke has as just MessageContext and Source available...Now we also have a @ServiceMode annotation with a value Service.Mode.PAYLOAD...
As far as I understand from reading JAX-WS docs, we should have Provider<DataSource> and Service.Mode.MESSAGE for mime attachements to be received...The question is whether it will work for XMLBinding or not. If not then what would be required to apply a patch ? (Hopefully at least the last question is appropriate for the dev list :-))
Thanks, Sergey