Return-Path: Delivered-To: apmail-incubator-cxf-dev-archive@locus.apache.org Received: (qmail 8329 invoked from network); 30 Jan 2007 19:04:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Jan 2007 19:04:50 -0000 Received: (qmail 6887 invoked by uid 500); 30 Jan 2007 19:04:56 -0000 Delivered-To: apmail-incubator-cxf-dev-archive@incubator.apache.org Received: (qmail 6854 invoked by uid 500); 30 Jan 2007 19:04:56 -0000 Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cxf-dev@incubator.apache.org Delivered-To: mailing list cxf-dev@incubator.apache.org Received: (qmail 6844 invoked by uid 99); 30 Jan 2007 19:04:56 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Jan 2007 11:04:56 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of sergey.beryozkin@iona.com designates 62.221.12.33 as permitted sender) Received: from [62.221.12.33] (HELO emea-smg1.iona.com) (62.221.12.33) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Jan 2007 11:04:48 -0800 Received: from emea-ems1.ionaglobal.com (dutec.ie [10.2.1.125]) by emea-smg1.iona.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id l0UK2Av6029805 for ; Tue, 30 Jan 2007 20:02:10 GMT Received: from sberyoz ([10.2.1.195]) by emea-ems1.ionaglobal.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Jan 2007 19:04:25 +0000 Message-ID: <002601c744a1$b167ecf0$c301020a@sberyoz> From: "Sergey Beryozkin" To: References: <018301c74140$ac05c480$c301020a@sberyoz> <7b774c950701261002ia9df9cah72c4716a1c2d338@mail.gmail.com> Subject: Re: Attachment support in XML binding and ProviderChainObserver (Was : Mime support...) Date: Tue, 30 Jan 2007 19:06:05 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 30 Jan 2007 19:04:25.0775 (UTC) FILETIME=[75A883F0:01C744A1] X-Virus-Checked: Checked by ClamAV on apache.org 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 wrote: >> >> The only concern is whether it actually JAXWS-compliant to have a >> Provider implementations to get a root part of the multipart/related >> request as the invoke Source and get to other parts through a Map> 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 represents either a primary part (of >> multipart/related) or content... >> >> That said, I have things working just fine using Provider, 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 >> 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 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 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 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 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 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 >> (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 then parsing all the attchment stuff >> manually :-) so once the pacth is applied I'd consider doing >> Provider. 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 wrote: >> >> >> >> Hi >> >> >> >> I suppose we can have a unmodifyable Map >> >> implementation using Collection 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 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 >> >> > not Collection. 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 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 set on it by the >> AttachmentDeserializer. >> >> >> >> >> >> Now the next problem to solve is how to make this collection >> visible to >> >> >> Provider 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" >> >> >> To: >> >> >> 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 >