oops forgot to attach the change. :) > -----Original Message----- > From: Taras Shkvarchuk > Sent: Tuesday, February 12, 2002 1:18 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Attachment support Diffs for review (Message & Part & > SOAPPar t af fected) > > > > 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 > > > > > > > > > > > > > > > > > > > > > > >
AttachmentsImpl.diff
Description: Binary data
