Ok this change is actually working right. <sigh> Having attachment support optional makes it not auto rebuild on dependency checks :(
> -----Original Message----- > From: Taras Shkvarchuk > Sent: Tuesday, February 12, 2002 1:51 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Attachment support Diffs for review (Message & Part & > SOAPPar t af fected) > > > 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
