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: Attachment support in XML binding and ProviderChainObserver (Was : Mime support...)
Date Tue, 30 Jan 2007 19:06:05 GMT
Hi Dan

It's compliant...Root attachment part maps to either raw XML or SOAP message, other parts
are usual attachments...

Cheers, Sergey



>I suppose the fix is OK, although I don't claim to know if its compliant at
> all.
> 
> Ultimately I'd like to see the ProviderChainObserver go away. The only
> difference between Providers and normal jax-ws services is that they use a
> different databinding. So what we really need to do is just create a
> ProviderDataBinding or something like that to handle Source objects. Then
> all that custom code can go away...
> 
> - Dan
> 
> On 1/26/07, Sergey Beryozkin <sergey.beryozkin@iona.com> wrote:
>>
>> The only concern is whether it actually JAXWS-compliant to have a
>> Provider<Source> implementations to get a root part of the multipart/related
>> request as the invoke Source and get to other parts through a Map<String,
>> DataHandler>...
>>
>> Looks like it's compliant...A useful matrix is here :
>>
>> http://weblogs.java.net/blog/arungupta/archive/2006/03/jaxws_20_provid_1.html
>>
>> so it says Provider<Source> represents either a primary part (of
>> multipart/related) or content...
>>
>> That said, I have things working just fine using Provider<DataSource>, can
>> get both POSTed (raw) multipart/related data and even GET even binary data
>> back this is really good. That said, I can have an initial patch sent in the
>> next few days or so if I can get an approval for the
>> ProviderChainObserver::onMessage() change as described below...
>>
>>
>> Cheers, Sergey
>>
>>
>>
>>   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 <sergey.beryozkin@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 <sergey.beryozkin@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" <dan@envoisolutions.com>
>>   >> >> To: <cxf-dev@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
>>   >
>>
> 
> 
> 
> -- 
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>

Mime
View raw message