Thank you for your answer. It is very helpful. But I kept wondering since email keeps attachment file names but CXF MTOM does not, it is purely implementation dependent and most Soap related toolkits choose not to do it due to the reason you give. Is this right?
Boxiong ----- Original Message ---- From: Daniel Kulp <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, June 9, 2008 12:19:38 PM Subject: Re: Does MTOM keep filename? Yea, in general, the name is considered a system dependent property and the client should get to chose what makes sense for them . If the name is important, it should be transferred in the actual data. I suppose we COULD throw the name into a mime header on the part, but we'd be the only toolkit to really do that or understand that. Thus, it wouldn't exactly be portable. Dan On Jun 9, 2008, at 3:10 PM, Glen Mazza wrote: > > Pardon the non-answer, but for my MTOM example > (http://www.jroller.com/gmazza/date/20071102), in step #11, I let > the client > set the name. Wouldn't it seem more natural to let the client > decide what > it wants the file it obtains to be called? > > As an alternative, perhaps best to send a separate String element > for the > filename in the SOAP response, then your client can name the file > based on > that name. Perhaps even a more portable solution. > > Glen > > > Boxiong Ding wrote: >> >> I have a service that uses MTOM to send a image file. As a client I >> can >> get the data, but the file name is lost. I have tried to set it in >> ByteArrayDataSource.setName() and create a DataHandler using it on >> server >> side. But still, the client always get null from >> DataSource.getName() and >> when I use tcpmon to look at the traffic, I couldn't find the file >> name >> any where. >> >> Is this how it works? And how can I preserver the file name? >> >> Thanks, >> Boxiong >> >> >> >> >> > > -- > View this message in context: > http://www.nabble.com/Does-MTOM-keep-filename--tp17739479p17739632.html > Sent from the cxf-user mailing list archive at Nabble.com. > --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
