Hi Rick, Am rolling back my changes. Code should be in sync with the code in beta-3. The spec does not explicitly state that a content-id should or should not be generated. The TCK however does enforce that the mime headers set by the user should be the ones returned during a get operation. You are welcome to take up the SAAJ TCK compliance testing.
Team, My cycles are almost up for SAAJ TCK compliance testing...So if someone wants to take over the SAAJ testing, they are most welcome to do so. I can send details on how to setup the environment. I was down to 12 failures (total of 285). Now with this rollback the failures will go up. Thanks, dims --- Rick Rineholt <[EMAIL PROTECTED]> wrote: > - Do these changes "guarantee" that when a content-id header is gotten > that the href will have a "cid:"; prefix this is a must in order to identify > the reference as a content-id and not a relative location reference. I > don't think I should worry about this as an application since the > content-id > is supposed from an application perspective be a handle to the attachment. > > - Where does it state the when an attachment is created that it many not be > automatically assigned a content-id? This is preferable since > content-id's should be considered "global unique immutable" handle to the > attachment and the previous logic did it's best to maintain this. > > -The logic before allowed me as a handler to just create the attachment and > ask for it's content-id value and the use that in an href attribute to > associate the attachment. Now to that I need to generate my own, and then > set it? > > - As far as every example I have read every attachment should have a > content-id value when sent regardless if it as being used to reference > the attachment. Does this change now still do that? > > - Not a major point the content-id generation logic seems specific to > attachments why has it been moved to SOAPUtils ? > > I still need to study this changes some more. As of right now I don't > believe anything that was implemented before violated JAX-RPC or JAX-M > specification. If this is the reason for changes, please I'd kindly > appreciate pointing out the specific sections. If the changes are solely > to facilitate TCK verification, then I argue logic prior to these change is > a VALID and more appropriate implementation of the JAX-RPC and JAX-M > specification with regard to providing useable attachment support and my > position is to VOTE a -1 to these changes. > > > Rick Rineholt > "The truth is out there... All you need is a better search engine!" > > [EMAIL PROTECTED] > > > > [EMAIL PROTECTED] on 07/01/2002 04:01:40 PM > > Please respond to [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > cc: > Subject: cvs commit: xml-axis/java/test/saaj TestAttachment.java > > > > dims 2002/07/01 13:01:39 > > Modified: java/src/org/apache/axis/attachments AttachmentPart.java > AttachmentsImpl.java MimeUtils.java > MultiPartDimeInputStream.java > MultiPartRelatedInputStream.java > java/src/org/apache/axis/encoding/ser > JAFDataHandlerSerializer.java > java/test/md5attach MD5AttachTest.java > java/src/org/apache/axis SOAPPart.java > java/test/saaj TestAttachment.java > Log: > Fixes for SAAJ compliance. > > Revision Changes Path > 1.18 +5 -24 > xml-axis/java/src/org/apache/axis/attachments/AttachmentPart.java > > Index: AttachmentPart.java > =================================================================== > RCS file: > /home/cvs/xml-axis/java/src/org/apache/axis/attachments/AttachmentPart.java,v > > retrieving revision 1.17 > retrieving revision 1.18 > diff -u -r1.17 -r1.18 > --- AttachmentPart.java 1 Jul 2002 17:40:29 -0000 1.17 > +++ AttachmentPart.java 1 Jul 2002 20:01:39 -0000 1.18 > @@ -96,7 +96,6 @@ > * Constructor AttachmentPart > */ > public AttachmentPart() { > - addMimeHeader(HTTPConstants.HEADER_CONTENT_ID, > SOAPUtils.getNewContentIdValue()); > } > > /** > @@ -105,11 +104,9 @@ > * @param dh > */ > public AttachmentPart(javax.activation.DataHandler dh) { > - addMimeHeader(HTTPConstants.HEADER_CONTENT_ID, > - SOAPUtils.getNewContentIdValue()); > datahandler = dh; > if(dh != null) > - addMimeHeader(HTTPConstants.HEADER_CONTENT_TYPE, > dh.getContentType()); > + setMimeHeader(HTTPConstants.HEADER_CONTENT_TYPE, > dh.getContentType()); > } > > /** > @@ -137,7 +134,7 @@ > * @param value > */ > public void addMimeHeader(String header, String value) { > - mimeHeaders.setHeader(header, value); > + mimeHeaders.addHeader(header, value); > } > > /** > @@ -191,7 +188,7 @@ > * @param loc > */ > public void setContentLocation(String loc) { > - addMimeHeader(HTTPConstants.HEADER_CONTENT_LOCATION, loc); > + setMimeHeader(HTTPConstants.HEADER_CONTENT_LOCATION, loc); > } > > /** > @@ -201,10 +198,7 @@ > * @returns void > */ > public void setContentId(String newCid) { > - if (newCid!=null && !newCid.toLowerCase().startsWith("cid:";)) { > - newCid = "cid:"; + newCid; > - } > - addMimeHeader(HTTPConstants.HEADER_CONTENT_ID, newCid); > + setMimeHeader(HTTPConstants.HEADER_CONTENT_ID, newCid); > } > > /** > @@ -213,20 +207,7 @@ > * @return > */ > public String getContentId() { > - String ret = > getFirstMimeHeader(HTTPConstants.HEADER_CONTENT_ID); > - // Do not let the contentID ever be empty. > - if (ret == null) { > - ret = SOAPUtils.getNewContentIdValue(); > - addMimeHeader(HTTPConstants.HEADER_CONTENT_ID, ret); > - } > - > - ret = ret.trim(); > - if (ret.length() == 0) { > - ret = SOAPUtils.getNewContentIdValue(); > - addMimeHeader(HTTPConstants.HEADER_CONTENT_ID, ret); > - } > - > - return ret; > + return getFirstMimeHeader(HTTPConstants.HEADER_CONTENT_ID); > } > > /** > > > > 1.22 +11 -11 > xml-axis/java/src/org/apache/axis/attachments/AttachmentsImpl.java > > Index: AttachmentsImpl.java > =================================================================== > RCS file: > /home/cvs/xml-axis/java/src/org/apache/axis/attachments/AttachmentsImpl.java,v > > retrieving revision 1.21 > retrieving revision 1.22 > diff -u -r1.21 -r1.22 > --- AttachmentsImpl.java 1 Jul 2002 17:40:29 -0000 1.21 > +++ AttachmentsImpl.java 1 Jul 2002 20:01:39 -0000 1.22 > @@ -223,7 +223,8 @@ > Part removedPart = getAttachmentByReference(reference); > > if (removedPart != null) { > - attachments.remove(removedPart.getContentId()); > + if(removedPart.getContentId()!=null) > + attachments.remove(removedPart.getContentId()); > attachments.remove(removedPart.getContentLocation()); > orderedAttachments.remove(removedPart); > } > @@ -250,7 +251,9 @@ > > mergeinAttachments(); > > - Part oldPart = (Part) attachments.put(newPart.getContentId(), > newPart); > + Part oldPart = null; > + if(newPart.getContentId()!=null) > + oldPart = (Part) attachments.put(newPart.getContentId(), > newPart); > > if (oldPart != null) { > orderedAttachments.remove(oldPart); > @@ -475,6 +478,8 @@ > AttachmentPart part= (AttachmentPart)i.next(); > DataHandler dh= AttachmentUtils. > getActivationDataHandler(part); > + if(part.getContentId() == null) > + > === message truncated === ===== Davanum Srinivas - http://xml.apache.org/~dims/ __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com
