RE: Attachment support Diffs for review (Message & Part & SOAPPar t af fected)

[Taras Shkvarchuk <ta...@grandcentral.com>]

oops forgot to attach the change. :)

> -----Original Message-----
> From: Taras Shkvarchuk 
> Sent: Tuesday, February 12, 2002 1:18 PM
> To: 'axis-dev@xml.apache.org'
> 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:rineholt@us.ibm.com]
> > Sent: Tuesday, February 12, 2002 6:27 AM
> > To: axis-dev@xml.apache.org
> > 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!"
> > 
> > rineholt@us.ibm.com
> > 
> > 
> > 
> > Taras Shkvarchuk <ta...@grandcentral.com> on 02/05/2002 03:51:32 PM
> > 
> > Please respond to axis-dev@xml.apache.org
> > 
> > To:    "'axis-dev@xml.apache.org'" <ax...@xml.apache.org>
> > 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
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
>