Return-Path: Delivered-To: apmail-incubator-cxf-dev-archive@locus.apache.org Received: (qmail 7962 invoked from network); 30 Jan 2007 19:02:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Jan 2007 19:02:06 -0000 Received: (qmail 3274 invoked by uid 500); 30 Jan 2007 19:02:11 -0000 Delivered-To: apmail-incubator-cxf-dev-archive@incubator.apache.org Received: (qmail 3197 invoked by uid 500); 30 Jan 2007 19:02:11 -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 3188 invoked by uid 99); 30 Jan 2007 19:02:11 -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:02:11 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,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:02:02 -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 l0UJxOlu029642 for ; Tue, 30 Jan 2007 19:59:24 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:01:39 +0000 Message-ID: <001501c744a1$4e634320$c301020a@sberyoz> From: "Sergey Beryozkin" To: "Sergey Beryozkin" , Cc: References: <018301c74140$ac05c480$c301020a@sberyoz> Subject: Re: Attachment support in XML binding and ProviderChainObserver (Was : Mime support...) Date: Tue, 30 Jan 2007 19:03:19 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C744A1.4E5C1730" 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:01:39.0647 (UTC) FILETIME=[12A364F0:01C744A1] X-Virus-Checked: Checked by ClamAV on apache.org ------=_NextPart_000_0012_01C744A1.4E5C1730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi There's something wrong with the implementation of a utility = ByteDataSource implementing DataSource...In my system test which I'm = running in the server depending on CXF simply using like this in=20 the Provider implementation causes an instant HTTP 500 : DataSource invoke(DataSource) { return new ByteDataSource("foo".getBytes());=20 } I feel the way it implements DataSource is subtly incorrect perhaps ? = I've replaced the call with javax.mail.ByteArrayDataSource, works just = fine...=20 Cheers, Sergey ----- Original Message -----=20 From: Sergey Beryozkin=20 To: Sergey Beryozkin ; cxf-dev@incubator.apache.org=20 Cc: mmao@iona.com=20 Sent: Friday, January 26, 2007 11:54 AM Subject: Re: Attachment support in XML binding and = ProviderChainObserver (Was : Mime support...) 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... 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.=20 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=3DMessage), 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.=20 Cheers, Sergey Hi What's the recommended approach for setting uninitilzied properties = in JAXWS.=20 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,=20 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 >=20 > 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 >> > >> >=20 >=20 >=20 > --=20 > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog > ------=_NextPart_000_0012_01C744A1.4E5C1730--