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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> >> >> To: <[email protected]> >> >> 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 >
