Hi Sergey! Sergey Beryozkin <[email protected]> wrote on 07/09/2010 10:18:43 PM: > > [...] > > List<?> contentList = message.getContent(List.class); > > [...] > > For retrieving the attachments I also tried to invoke getAttachments on the > > message but this returns null. > > I think JAXRS MessageContextImpl is just not setting attachments on the > message (as in message.setAttachments()), this is because Attachments that > MultipartBody deals with and those which are set in message.setAttachments > are of different types
I guess so too. Did not have any troubles witjh that part so far. > > The other thing I experience is when writing the file, I > > have to invoke reset on the InputStream to reset the the file read position > > back to the initial mark of 0. Would this be the proper way to get hold of > > the attachments? > > I'm presuming the CXF input stream representing an attachment is supporting > reset() - so yes, it's fine if it works :-) I had some troubles with this solution. It seems that some attachments use a different type of InputStream that does not support reset(). Maybe this is, if an attachment is over a certain size. But I realized that the InputStream returned is in fact of type DelegatingInputStream that passes on all the operations to another InputStream. This class provides a setInputStream method where I can replace the InputStream. :) Only downside DelegatingInputStream has package visibility. So, I currently have added a class to that package (yes, an ugly hack) that exposes the function to me. That seems to work. Does anybody know whether cxf could make the visibility of the DelegatingInputStream public? > At the moment you may want to replace the existing MultipartBody instance > with a new one by initializing it with a new collection of Attachments, > getting some from the immutable collection and adding some new attachcment > to the new collection Replacing the entire MultipartBody is quite a bit of work. Generating new attachments, copying all the other meta-data, etc. In this case, I rather live with the above hack. Thanks, Thomas
