axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Rineholt" <>
Subject Re: Axis and attachments (non-RPC)
Date Wed, 30 Jan 2002 13:06:06 GMT
>I was looking at the Axis for non-RPC messaging, and noticed that there
>isn't much there. (not even in TODO comments that I saw).
>What is the planned future?
>1) No clean way to set Content-Id of attachments.
>You have to extract all of the attachments from the Attachments class,
>change headers manually, then re add them to the Attachments.
>1b) If you update Content-Id of the Attachment, it will not be saved
>you re-add it to attachments.
1a+ b)  Content-Id is generated for you.  There should be no significance
given to the
content-id value itself.  Can you please give a usage scenario where this
would be necessary?
>1c) *BUG* Mime allows for duplicate headers, but they get eaten by HashMap
Ok. But may I ask what you are doing with headers from a SOAP/ Web Service
application that depends on this?  Mind you I'm not saying that this is
correct but I'm wondering
what the usage pattern is that would use this so I can assess how high of a
priority it would be to fix.
>2) There is no way to add an attachment to the list if you already have
>>From another message lets say.
>Attachments atts=msg.getAttachments();
>DataHandler dh=new DataHandler(new
>part.addMimeHeader(HTTPConstants.HEADER_CONTENT_ID ,
>ArrayList parts=new ArrayList(2);
>2b) Needs add(AttachmentPart), getAttachmentByContentId(), getIterator() -
>Would be nice if remove() and add() would function on iterator.
Let me consider the impact of this some more.
>3) Reading contents of the AttachementPart is awkward.
>getActiviationDataHandler() method is not public, but is on package level.
>Is it a typo or as intended?
>AttachmentUtils has     public static DataHandler
>getActiviationDataHandler(Part part)   method, but its kind of odd way of
>doing it.
As one of the requirements the core of Axis can be compiled without
support.  This is one of reasons for some of the "round about" manner of
>4) There is nice BoundaryDelimitedStream to read the attachments, but you
>still rely on scary javax.mail code to create outgoing messages. Are there
>any plans to change that?
No.  This code has been used and tested.
>P.S. What is the preferred way of sending patches, since only committers
>have write access to cvs?

Rick Rineholt
"The truth is out there...  All you need is a better search engine!"

View raw message