> I don't want at this point to lose the association of > attachments to the message they are attached to. What is the reasoning behind this? I do not see why child data should always know of its parent. And attachments logically do not depend on SOAP part. Its the other way around. Also if AttachmentPart is tied to a message, it is not as easy to forward attachments in new messages.
> why does content-location not work? It does. However, for backwards compatibility and higher toolkit flexibility with misbehaved services it is desired. Putting such an option in, does not break functionality. It only makes lives easier for people who already have existing services that depend on Content-Id > There was a design goal to not obtain all the attachments > from the incoming stream unless they are reference and thus > I'm not going to integrate this change in. Very good point. I forgot I had the same functionality in the parser I wrote. I'll change that... Ok what I did I added a method that copies references on 1st use. It is a small functions checking against null. Should be inlined by hotspot. If you prefer to maintain 2 separate lists, one with incoming one with outgoing attachments, I'll be glad to do so if you could explain the reason. -Taras > -----Original Message----- > From: Rick Rineholt [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 12, 2002 6:27 AM > To: [EMAIL PROTECTED] > Subject: Re: Attachment support Diffs for review (Message & Part & > SOAPPart af fected) > > > I'm not for the most part in agreement with these patches. > By item: > The attachment implementation should be configurable and I > just added this. > > I don't want at this point to lose the association of > attachments to the > message they are attached to. > > You've added setContentID we've discussed this and I asked if > was really > necessary to know attachments > by name why content location header is not the correct > choice. I admit, I > have purposely left this out since it is > from my understanding that ContentId is supposed to be > universally unique > and there is logic to do this as best as can > be done. I ask again why do you need this and why does > content-location > not work? > > Applied the UTF-8 patch to SOAPPart > > The lack of the public specifier is that the preferred method > to obtain > this through the AttachmentUtils > > I'm still looking at the addAttachmentPart and removeAttachmentPart > > There was a design goal to not obtain all the attachments > from the incoming > stream unless they are reference and thus > I'm not going to integrate this change in. > > > Rick Rineholt > "The truth is out there... All you need is a better search engine!" > > [EMAIL PROTECTED] > > > > Taras Shkvarchuk <[EMAIL PROTECTED]> on 02/05/2002 03:51:32 PM > > Please respond to [EMAIL PROTECTED] > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > cc: > Subject: Attachment support Diffs for review (Message & > Part & SOAPPart > af fected) > > > > Here are some changes I made to Attachments implementation. (diffs > attached) > > ***************************************************************** > AttachmentsImpl.java: > removed reference to Message object. > When Message gets SOAPPart it sets itself as a parent. > > added orderedAttachments list that keeps local copy of attachments. > attachments HashMap now holds CID & Content-Location -> Part mappings > > removed MultiPartRelatedInputStream local var, attachment > references are > copied from there to local list > So that searches and serialization does not have to worry > about 2 lists. > > Added removeAttachmentPart(String reference) method. > > Added addAttachmentPart(Part newPart) method. > > fixed getAttachmentByReference to find new attachments > > Added setRootPart(Part rootPart) used by Message class > > > ***************************************************************** > Attachments.java: > Added addAttachmentPart, removeAttachmentPart, setRootPart method > definitions > > > ***************************************************************** > AttachmentPart.java: > removed reference to Message object > > made getActiviationDataHandler a public method. This does not > mean that > Attachment support is required to build. But it is highly > convenient for > clients to use. > > > ***************************************************************** > SOAPPart.java: > moved reference to Message from parent Part class here, as > private Message > msgObject; > > Added get/setMessage() methods. > > When String <--> byte[] conversion is done, made it use UTF-8 > character > set, > since this is what content type is hard coded to. Just a temp > fix, until > proper character set support is added. > > > ***************************************************************** > Part.java: > removed reference to Message object. > > Added method to setContentId() of the Part. While this may > not the optimal > way to manage attachments, it still should be present, since > there are some > applications that require this. > > > ***************************************************************** > MimeUtils.java: > changed createMP(...) method to take Collection of parts > rather than a map. > > > ***************************************************************** > Message.java: > Added ability to define alternate Attachments Implementation. > > changed serialization to register self with SOAPPart, and add *new* > SOAPParts to Attachments for proper serialization. > ***************************************************************** > > -Taras > > > > > > > > > > >
