Just spotted this email, thought I'd update that I added the other day getObject(Class<T> cls) to Attachment and getAttachmentObject(String partName, Class<T> cls) to MultipartBody, the latter method can be handy in that one does not need to worry about the ordering of individual parts as long as one knows the required part's id
thanks, Sergey On Thu, Jul 29, 2010 at 6:40 PM, Sergey Beryozkin <[email protected]>wrote: > Hi > > On Thu, Jul 29, 2010 at 2:12 PM, Bernhard Groll > <[email protected]>wrote: > >> Hi Sergey, >> >> thanks for your explanations and please excuse my late reply. >> >> no problems - I'm replying with delays myself > > >> You wrote (2010-07-26T18:21+0100): >> > [...] the JAXRS providers which might be able to deal with >> > specific parts are not used. [...] >> > Enhancing Attachement.getObject() so that a suitable provider could >> > be found if it's not already been done could be a good enhancement >> > though. >> >> My problem obviously was the assumption that it would already work this >> way and I’m really surprised that’s not the case. > > > Well, by the time the method has been invoked by the JAXRS runtime the > providers have already been checked, and the job of MultipartProvider is to > give users access to individual parts and let them parse XML bits if such > exist, deal with binary parts whichever way they prefer. > > > >> Handling the bodies of >> multipart attachments exactly like the body of a non-multipart message >> would seem the obvious choice to me. >> >> > This is what happening when parameters represent individual parts. > But as I said, enhancing MultipartProvider a bit would make sense. > > >> Is there a way to manually call a MessageBodyReader to deserialize an >> attachment? >> >> You can have > > @Context Providers providers; > in your class and then ask 'providers' to get you a MessageBodyReader > capable of reading a given part. > > > > >> > If you expect a fixed number of parts, say the root providing some >> > info about the (2nd) binary part, then you could have say >> > >> > unpack(@Multipart("root", text/xml) MixedString str, >> > @Multipart("2ndPart") InputStream is) {} >> >> Alas I have to deal with a varying number of parts so it seems I will >> have to use MultipartBody for at least some of them. >> >> Anyway, seeing that my original approach couldn’t work I can now in good >> conscience look for a different solution. >> >> > If you have say a single XML part only or any fixed number of XMl parts > followed by a variable number of > some other parts, then you can do : > > unpack(@Multipart("root", text/xml) MixedString str, List<Attachment> atts) > { > } > > in the list the 1st entry will represent the already read MixedString, and > others will point to some binary ones > > cheers, Sergey > > >> Thanks again. >> >> Bye, >> Bernhard >> > >
