>> >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 >> unless >> >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? >If you use RPC you don't care much for a content-id. However, as soon as you >step away from RPC into messaging, you will need some way for a service to >know what attachments to look for. You *could* put in the name of the >attachment into SOAP header/body you send, but it is much more processing on >the client side. Naming your attachment is much simpler. >Use case: Intermediary that does XSLT transformations. A soap header tells >it to pick up original xml from "cid:original.xml"; and xslt instructions >from "cid:instructions.xsl";. It is useful for automation purposes to have >that header prebuilt, and just rename the attachments. Content-id should be "universally" unique per attachment . From what I'm understanding of your requirements using "content-location" header would be far more appropriate. I would also suggest using a value that includes a URL plus a uuid type string. . We don't set or modify the content-location header. Second if you are creating a specification, I would strongly suggest that you not use either of these as the means of identifying your attachments. In my opinion, using an element in your XML document with an href attribute to the attachment is in most cases I can think of a better approach. In the approach you are using, you are binding your specification to the wire protocol (mail-attachments). There are emerging protocols such as DIME http://www.ietf.org/internet-drafts/draft-nielsen-dime-00.txt that are really more appropriate. By using an href and allowing the SOAP processor to resolve the attachment your specification only is dependant on the XML. Yes, you do have to do some extra processing, but I would assume that the XML would be processed eventually? Having an element associated with the attachment I think is also from a design point preferable. Also, there really should be no significance given to the value of content-id and it would not be unreasonable for an intermediary to take an in coming SOAP/MIME message and send it out as a SOAP/DIME replacing content-ids with DIME payload identifiers. The value of XML is that it is a recognized protocol for exchanging data, any thing you can do to limit your specification to just that, IMO is an important design consideration. >> >1c) *BUG* Mime allows for duplicate headers, but they get >> eaten by HashMap >> >here. >> Ok. But may I ask what you are doing with headers from a >> SOAP/ Web Service >> type >> 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. >There is no high priority in it yet, it more of a compatibility issue. >SOAP is not protocol dependent. For instance SMTP allows for multiple To: >headers. There is nothing stopping a person from using his/her SMTP server >to broadcast SOAP messages... if Axis doesn't eat duplicate headers :) >> >2) There is no way to add an attachment to the list if you >> already have >> one. >> >From another message lets say. >> >Example: >> >Attachments atts=msg.getAttachments(); >> >DataHandler dh=new DataHandler(new >> >FileDataSource("data.dat")); >> >AttachmentPart >> >part=(AttachmentPart)atts.createAttachmentPart(dh); >> >part.addMimeHeader(HTTPConstants.HEADER_CONTENT_ID , >> >"myAttachmentId"); >> >ArrayList parts=new ArrayList(2); >> >parts.add(part); >> >atts.setAttachmentParts(parts); >> >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. >Again this is not an issue related to RPC but is rather important for xml >messaging(non-RPC), and intermediaries. >> >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 >> attachment >> support. This is one of reasons for some of the "round >> about" manner of >> things. >Well... If a client is already using an AttachmentPart class, we can assume >that he does have attachment support, can we not? No, attachment support can be COMPILED in and or left out. >> >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? >> http://xml.apache.org/source.html. >> >-Taras >> >> >> Rick Rineholt >> "The truth is out there... All you need is a better search engine!" >> >> [EMAIL PROTECTED] >>
Rick Rineholt "The truth is out there... All you need is a better search engine!" [EMAIL PROTECTED]
