chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller (JIRA) <j...@apache.org>
Subject [jira] [Commented] (CMIS-578) contentStream's length become null on setContentStream method
Date Sat, 13 Oct 2012 10:47:02 GMT

    [ 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

Mime
View raw message