[jira] [Commented] (CMIS-578) contentStream's length become null on setContentStream method

["Florian Müller (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CMIS-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475584#comment-13475584 ] 

Florian Müller commented on CMIS-578:
-------------------------------------

Not sure if that helps you:

The AtomPub binding doesn't transmit the content length directly. That is, the length in the ContentStream object on the client side is ignored.
When you are creating a document, the content has to be buffered on the server - depending on the size, in main memory or on disk. In that case, the OpenCMIS server framework knows the size (because it has read the content) and sets the length in ContentStream object on the server side. 
When you call setContentStream, the OpenCMIS server framework hands you the original stream without reading it. Therefore, it doesn't know the length and cannot set it. The stream, however, should be fully consumable.
                
> contentStream's length become null on setContentStream method
> -------------------------------------------------------------
>
>                 Key: CMIS-578
>                 URL: https://issues.apache.org/jira/browse/CMIS-578
>             Project: Chemistry
>          Issue Type: Bug
>    Affects Versions: OpenCMIS 0.6.0
>            Reporter: linzhixing
>
> I'm developing a CMIS client and server. 
> Creating a new document and uploading an attachment of a document both work almost fine,
> but uploading has a problem. ContentStream of the attachemnt's length is 0!
> -------------------------------------------------------
> (A)
> //org.apache.chemistry.opencmis.client.bindings.spi.atompub;
> //calss ObjectServiceImpl
> //setContentStream
> //Line:588
>  // send content
>         HttpUtils.Response resp = put(url, contentStream.getMimeType(), headers, new HttpUtils.Output() {
>             public void write(OutputStream out) throws Exception {
>                 int b;
>                 byte[] buffer = new byte[4096];
>                 while ((b = stream.read(buffer)) > -1) {
>                     out.write(buffer, 0, b);
>                 }
>                 stream.close();
>             }
>         });
> >>>then
> //package org.apache.chemistry.opencmis.client.bindings.spi.http;
> //class HttpUtils
> //Line:69
> public static Response invokePOST(UrlBuilder url, String contentType, Output writer, BindingSession session) {
>         return invoke(url, "POST", contentType, null, writer, session, null, null);
>     }
> public static Response invokePUT(UrlBuilder url, String contentType, Map<String, String> headers, Output writer,
> BindingSession session) {
>         return invoke(url, "PUT", contentType, headers, writer, session, null, null);
>     }
> (*invokePUT method is executed when upgrading)
> >>>then
> (B)
> My server's code
> ----------------
> public void setContentStream(CallContext callContext,
> 			Holder<String> objectId, boolean overwriteFlag,
> 			ContentStream contentStream) {
> 		String newAttachmentId = nodeService.createAttachment(
> 				callContext.getUsername(),
> 				millisToCalendar(System.currentTimeMillis()), contentStream);
> 		Content content = nodeService.get(Document.class, objectId.getValue());
> 		// TODO use overwriteFlag
> 		content.getAttachments().add(newAttachmentId);
> 		nodeService.update(content);
> 	}
> -------------------------------------------------------
> Just before (A), the contentStream has non-zero length.
> It is our specification that my server's code creates a new document for the attachement when upgrading, anyway, when the debugger enterd into (B) method, contentStream already became zero length.
> When I create a new document with attached file(not upgrading), invokePOST method is executed and contentStream has non-zero length even on my server's part. 
> So, I guess it would not be a probelm of my developing product's behavior.
> invokePUTmethod or such thing  has Content' length bug?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira