Mailing-List: contact chemistry-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: chemistry-dev@incubator.apache.org
Message-ID: <929022243.2791265206288009.JavaMail.jira@brutus.apache.org>
Date: Wed, 3 Feb 2010 14:11:28 +0000 (UTC)
From: "Hinse ter Schuur (JIRA)" <jira@apache.org>
To: chemistry-dev@incubator.apache.org
Subject: [jira] Commented: (CMIS-111) Content streams not correctly served
In-Reply-To: <1856698610.201265194168883.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CMIS-111?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D128290=
80#action_12829080 ]=20

Hinse ter Schuur commented on CMIS-111:
---------------------------------------

I've tried to reproduce with a fresh checkout of Chemistry and couldn't rep=
roduce the problem. The difference with my normal situation is that I chang=
ed the dependency on Abdera. My local copy of Chemistry depends on Abdera 1=
.0 instead of 0.4.0-incubating.

Abdera 1.0 uses this isBinary() method to determine whether it should use e=
ither getOutputStream or getWriter on the ServletResponse.
{code:title=3DAbderaServlet.java|borderStyle=3Dsolid}
...
if (!request.getMethod().equals("HEAD") && context.hasEntity()) {
    if (context.isBinary()) {
      context.writeTo(response.getOutputStream());
    } else {
      context.writeTo(response.getWriter());
    }
 }
... =20
{code}

So it's not a real problem for the current version, but it will become a pr=
oblem when Chemistry starts to depend on Abdera 1.0.

> Content streams not correctly served
> ------------------------------------
>
>                 Key: CMIS-111
>                 URL: https://issues.apache.org/jira/browse/CMIS-111
>             Project: Chemistry
>          Issue Type: Bug
>          Components: server
>            Reporter: Hinse ter Schuur
>         Attachments: media-binary.txt
>
>
> When downloading (binary) content from the server the contents are not co=
rrect. This seems to be because a SizedMediaResponseContext is  treated as =
non-binary, resulting in written out to the request context=C2=B4 s writer =
instead of outputstream.
> A simple reproduction case is: run the org.apache.chemistry.test.MainServ=
let from the chemistry-test module upload a zip file and try to download it=
 again. The resulting download does not have the same size as the original =
and the archive is corrupted.
> A simple fix will be to make the SizedMediaResponseContext binary. I'll a=
ttach a patch file for this.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.