You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Andreas Krüger (Created JIRA)" <ji...@apache.org> on 2012/04/04 21:48:18 UTC
[jira] [Created] (CXF-4227) AttachmentDeserializerTest contains
buggy code for reading an InputStream.
AttachmentDeserializerTest contains buggy code for reading an InputStream.
--------------------------------------------------------------------------
Key: CXF-4227
URL: https://issues.apache.org/jira/browse/CXF-4227
Project: CXF
Issue Type: Bug
Components: WS-* Components
Reporter: Andreas Krüger
Priority: Minor
Browsing through the CXF code, I stumbled over the following in AttachmentDeserializerTest, method testCXF3383():
{code}
for (int x = 1; x < 50; x++) {
String cid = "1882f79d-e20a-4b36-a222-7a75518cf395-" + x + "@cxf.apache.org";
DataSource ds = AttachmentUtil.getAttachmentDataSource(cid, message.getAttachments());
byte bts[] = new byte[1024];
InputStream ins = ds.getInputStream();
int count = ins.read(bts, 0, bts.length);
int sz = ins.read(bts, count, bts.length - count);
while (sz != -1) {
sz = ins.read(bts, count, bts.length - count);
}
assertEquals(x + 1, count);
}
{code}
I think some "count += sz" has been forgotten. Details:
* The while-loop does nothing to change the test result.
* Endless loop, should "ins" ever deliver 1025 bytes or more.
* The fix is obvious, I'll attach a patch.
The problem does not show as long as "ins" contains less than 1024 bytes and all its content is delivered with the first read operation. So no functional impairment, just code hygiene.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4227) AttachmentDeserializerTest contains
buggy code for reading an InputStream.
Posted by "Andreas Krüger (Updated JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Krüger updated CXF-4227:
--------------------------------
Description:
Browsing through the CXF code, I stumbled over the following in AttachmentDeserializerTest, method testCXF3383():
{code}
for (int x = 1; x < 50; x++) {
String cid = "1882f79d-e20a-4b36-a222-7a75518cf395-" + x + "@cxf.apache.org";
DataSource ds = AttachmentUtil.getAttachmentDataSource(cid, message.getAttachments());
byte bts[] = new byte[1024];
InputStream ins = ds.getInputStream();
int count = ins.read(bts, 0, bts.length);
int sz = ins.read(bts, count, bts.length - count);
while (sz != -1) {
sz = ins.read(bts, count, bts.length - count);
}
assertEquals(x + 1, count);
}
{code}
I think some "count += sz" has been forgotten. Details:
* The while-loop does nothing to change the test result.
* Endless loop, should "ins" ever deliver 1025 bytes or more.
* (If "ins" is 0 bytes, then count will be -1.)
* The fix is obvious, I'll attach a patch.
The problem does not show as long as "ins" contains less than 1024 bytes and all its content is delivered with the first read operation. So no functional impairment, just code hygiene.
was:
Browsing through the CXF code, I stumbled over the following in AttachmentDeserializerTest, method testCXF3383():
{code}
for (int x = 1; x < 50; x++) {
String cid = "1882f79d-e20a-4b36-a222-7a75518cf395-" + x + "@cxf.apache.org";
DataSource ds = AttachmentUtil.getAttachmentDataSource(cid, message.getAttachments());
byte bts[] = new byte[1024];
InputStream ins = ds.getInputStream();
int count = ins.read(bts, 0, bts.length);
int sz = ins.read(bts, count, bts.length - count);
while (sz != -1) {
sz = ins.read(bts, count, bts.length - count);
}
assertEquals(x + 1, count);
}
{code}
I think some "count += sz" has been forgotten. Details:
* The while-loop does nothing to change the test result.
* Endless loop, should "ins" ever deliver 1025 bytes or more.
* The fix is obvious, I'll attach a patch.
The problem does not show as long as "ins" contains less than 1024 bytes and all its content is delivered with the first read operation. So no functional impairment, just code hygiene.
> AttachmentDeserializerTest contains buggy code for reading an InputStream.
> --------------------------------------------------------------------------
>
> Key: CXF-4227
> URL: https://issues.apache.org/jira/browse/CXF-4227
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Reporter: Andreas Krüger
> Priority: Minor
> Labels: patch
> Attachments: AttachmentDeserializerTest.patch
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> Browsing through the CXF code, I stumbled over the following in AttachmentDeserializerTest, method testCXF3383():
> {code}
> for (int x = 1; x < 50; x++) {
> String cid = "1882f79d-e20a-4b36-a222-7a75518cf395-" + x + "@cxf.apache.org";
> DataSource ds = AttachmentUtil.getAttachmentDataSource(cid, message.getAttachments());
> byte bts[] = new byte[1024];
>
> InputStream ins = ds.getInputStream();
> int count = ins.read(bts, 0, bts.length);
> int sz = ins.read(bts, count, bts.length - count);
> while (sz != -1) {
> sz = ins.read(bts, count, bts.length - count);
> }
> assertEquals(x + 1, count);
> }
> {code}
> I think some "count += sz" has been forgotten. Details:
> * The while-loop does nothing to change the test result.
> * Endless loop, should "ins" ever deliver 1025 bytes or more.
> * (If "ins" is 0 bytes, then count will be -1.)
> * The fix is obvious, I'll attach a patch.
> The problem does not show as long as "ins" contains less than 1024 bytes and all its content is delivered with the first read operation. So no functional impairment, just code hygiene.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4227) AttachmentDeserializerTest contains
buggy code for reading an InputStream.
Posted by "Andreas Krüger (Updated JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Krüger updated CXF-4227:
--------------------------------
Attachment: AttachmentDeserializerTest.patch
The patch I promised.
> AttachmentDeserializerTest contains buggy code for reading an InputStream.
> --------------------------------------------------------------------------
>
> Key: CXF-4227
> URL: https://issues.apache.org/jira/browse/CXF-4227
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Reporter: Andreas Krüger
> Priority: Minor
> Labels: patch
> Attachments: AttachmentDeserializerTest.patch
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> Browsing through the CXF code, I stumbled over the following in AttachmentDeserializerTest, method testCXF3383():
> {code}
> for (int x = 1; x < 50; x++) {
> String cid = "1882f79d-e20a-4b36-a222-7a75518cf395-" + x + "@cxf.apache.org";
> DataSource ds = AttachmentUtil.getAttachmentDataSource(cid, message.getAttachments());
> byte bts[] = new byte[1024];
>
> InputStream ins = ds.getInputStream();
> int count = ins.read(bts, 0, bts.length);
> int sz = ins.read(bts, count, bts.length - count);
> while (sz != -1) {
> sz = ins.read(bts, count, bts.length - count);
> }
> assertEquals(x + 1, count);
> }
> {code}
> I think some "count += sz" has been forgotten. Details:
> * The while-loop does nothing to change the test result.
> * Endless loop, should "ins" ever deliver 1025 bytes or more.
> * The fix is obvious, I'll attach a patch.
> The problem does not show as long as "ins" contains less than 1024 bytes and all its content is delivered with the first read operation. So no functional impairment, just code hygiene.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CXF-4227) AttachmentDeserializerTest contains
buggy code for reading an InputStream.
Posted by "Freeman Fang (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang reassigned CXF-4227:
---------------------------------
Assignee: Freeman Fang
> AttachmentDeserializerTest contains buggy code for reading an InputStream.
> --------------------------------------------------------------------------
>
> Key: CXF-4227
> URL: https://issues.apache.org/jira/browse/CXF-4227
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Reporter: Andreas Krüger
> Assignee: Freeman Fang
> Priority: Minor
> Labels: patch
> Attachments: AttachmentDeserializerTest.patch
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> Browsing through the CXF code, I stumbled over the following in AttachmentDeserializerTest, method testCXF3383():
> {code}
> for (int x = 1; x < 50; x++) {
> String cid = "1882f79d-e20a-4b36-a222-7a75518cf395-" + x + "@cxf.apache.org";
> DataSource ds = AttachmentUtil.getAttachmentDataSource(cid, message.getAttachments());
> byte bts[] = new byte[1024];
>
> InputStream ins = ds.getInputStream();
> int count = ins.read(bts, 0, bts.length);
> int sz = ins.read(bts, count, bts.length - count);
> while (sz != -1) {
> sz = ins.read(bts, count, bts.length - count);
> }
> assertEquals(x + 1, count);
> }
> {code}
> I think some "count += sz" has been forgotten. Details:
> * The while-loop does nothing to change the test result.
> * Endless loop, should "ins" ever deliver 1025 bytes or more.
> * (If "ins" is 0 bytes, then count will be -1.)
> * The fix is obvious, I'll attach a patch.
> The problem does not show as long as "ins" contains less than 1024 bytes and all its content is delivered with the first read operation. So no functional impairment, just code hygiene.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4227) AttachmentDeserializerTest contains
buggy code for reading an InputStream.
Posted by "Freeman Fang (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang resolved CXF-4227.
-------------------------------
Resolution: Fixed
Fix Version/s: 2.6
2.5.3
2.4.7
2.3.10
Apply patch on behalf of Andreas Krüger with thanks
http://svn.apache.org/viewvc?rev=1310200&view=rev for trunk
http://svn.apache.org/viewvc?rev=1310214&view=rev for 2.5.x branch
http://svn.apache.org/viewvc?rev=1310216&view=rev for 2.4.x branch
http://svn.apache.org/viewvc?rev=1310218&view=rev for 2.3.x branch
> AttachmentDeserializerTest contains buggy code for reading an InputStream.
> --------------------------------------------------------------------------
>
> Key: CXF-4227
> URL: https://issues.apache.org/jira/browse/CXF-4227
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Reporter: Andreas Krüger
> Assignee: Freeman Fang
> Priority: Minor
> Labels: patch
> Fix For: 2.3.10, 2.4.7, 2.5.3, 2.6
>
> Attachments: AttachmentDeserializerTest.patch
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> Browsing through the CXF code, I stumbled over the following in AttachmentDeserializerTest, method testCXF3383():
> {code}
> for (int x = 1; x < 50; x++) {
> String cid = "1882f79d-e20a-4b36-a222-7a75518cf395-" + x + "@cxf.apache.org";
> DataSource ds = AttachmentUtil.getAttachmentDataSource(cid, message.getAttachments());
> byte bts[] = new byte[1024];
>
> InputStream ins = ds.getInputStream();
> int count = ins.read(bts, 0, bts.length);
> int sz = ins.read(bts, count, bts.length - count);
> while (sz != -1) {
> sz = ins.read(bts, count, bts.length - count);
> }
> assertEquals(x + 1, count);
> }
> {code}
> I think some "count += sz" has been forgotten. Details:
> * The while-loop does nothing to change the test result.
> * Endless loop, should "ins" ever deliver 1025 bytes or more.
> * (If "ins" is 0 bytes, then count will be -1.)
> * The fix is obvious, I'll attach a patch.
> The problem does not show as long as "ins" contains less than 1024 bytes and all its content is delivered with the first read operation. So no functional impairment, just code hygiene.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira