search

yuanshuo / jupiter-eclipse-plugin

Automatically exported from code.google.com/p/jupiter-eclipse-plugin
0 stars 0 forks source link

Only two lines shown although XML contains many #65

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Create a number of review issues with multi-line information in the
Review Editor
2. Close review
3. Open again
4. The Review Editor only shows the ~2 first lines although the XML file
contains all data. After a while, the XML fle is overwritten with the
truncated data from the Review Editor.

What is the expected output? To see the entire text of the review issue
What do you see instead? Only two out of several lines

What version of the product are you using? On what operating system?
Jupiter 3.4.1.1
Eclipse 3.4.1 Build id: M20080911-1700

If applicable, what editor does the problem occur in (Jupiter is tested
against the 'Eclipse for RCP/Plug-in Developers' so the editors may vary)?
Eclipse editor

Please provide any additional information below.
Sample of the XML file:
  <ReviewIssue id="FQP4WC1Y">
    <ReviewIssueMeta>
      <CreationDate format="yyyy-MM-dd :: HH:mm:ss:SSS z">2009-02-02 ::
13:44:43:654 CET</CreationDate>
      <LastModificationDate format="yyyy-MM-dd :: HH:mm:ss:SSS
z">2009-02-02 :: 13:49:26:050 CET</LastModificationDate>
    </ReviewIssueMeta>
    <ReviewerId>Tom</ReviewerId>
    <AssignedTo>Nik</AssignedTo>
    <File line="325">src/com/mystuff/app/factory/Factory.java</File>
    <Type>item.type.label.programLogic</Type>
    <Severity>item.severity.label.normal</Severity>
    <Summary>try too large</Summary>
    <Description>The try-catch block that takes care of XException is so
large. Only one (?) method seems to throw an XExcpetion, isn't it
sufficient to try-catch that call?

        } catch (XException e) {
            flushToFile();
            throw e;
        } catch (Exception e) {
            log( ERROR,"Factory: Broken data"+
</Description>
    <Annotation></Annotation>
    <Revision></Revision>
    <Resolution>item.label.unset</Resolution>
    <Status>item.status.label.open</Status>
  </ReviewIssue>

Sample of the output in the Review Editor:
The try-catch block that takes care of XException is so large. Only one (?)
method seems to throw an XExcpetion, isn't it sufficient to try-catch that
call?
        } catch (XException e) {

Original issue reported on code.google.com by Tommy.Mo...@gmail.com on 2 Feb 2009 at 4:13

GoogleCodeExporter commented 9 years ago 
I'm pretty sure this is related to all the other XML issues that have recently
appeared.  Probably has to do with StAX's splitting of lines and the 
IS_COALESCING
property.

Thank you for the XML file, I will test it against the Jupiter in the 
repository and
see if the problem persists.

Original comment by jsakuda on 2 Feb 2009 at 5:50

GoogleCodeExporter commented 9 years ago 
I suppose this is obvious but just to clarify, the XML sample I provided was 
just a
part of the XML file, not the entire file

Original comment by Tommy.Mo...@gmail.com on 2 Feb 2009 at 6:00

GoogleCodeExporter commented 9 years ago 
Maybe the problem is related to embedded <, > or other special characters in 
the code
samples pasted into the Review Editor? Some of the descriptions contains < or > 
and
some are "cut" at the first occurrence of a <. Example:

    <Description>        for (int i=0; i<aNoOfFilesToDelete; i++) {
            success = files[i].delete();
            if (!success) {
                // Deletion failed
                log( ERROR, this.getClass().getName() + 
                    ".deleteFile: FAILED: " + files[i].getAbsolutePath());
            }

Use logOnce() instead</Description>

The review issue above is cut at the < position. I make a wild guess here, but
maybe the translation of special characters is done in a way that later 
interfere
with the XML parsing.

Original comment by Tommy.Mo...@gmail.com on 3 Feb 2009 at 7:21

GoogleCodeExporter commented 9 years ago 
I don't know if it is possible to raise the severity of this issue, but from my 
point
of view, this is a critical flaw since the review issues isn't possible to see 
in
their entirety in the review editor.

Original comment by Tommy.Mo...@gmail.com on 3 Feb 2009 at 7:31

GoogleCodeExporter commented 9 years ago 
I reverted back to an older Jupiter version and it works with both 3.3.1 and 
3.4.0

Original comment by Tommy.Mo...@gmail.com on 3 Feb 2009 at 8:41

GoogleCodeExporter commented 9 years ago 
See Issue 58 and Issue 57

It gets cut if you pasted a piece of code in the description and it had <, >, or
another special character in it.  The sample you originally provided didn't 
seem to
have any of those so it probably was the new line causing the issue.  Some 
people
were also having clipping around new lines.

In 3.4.1 due to performance problems I removed the DOM code and moved over to 
stream
parsing.  There was a property that needed to be true to return blocks of code 
in one
block.  I had had this set to false and that is what was causing the clipping.  
I
also learned that even if I tell it not to split up long blocks of text it will 
do it
against my will if it encounters a special character.

So I think you've found two of my XML issues... I will test your samples soon 
just to
make sure.  After I test it I will either close the issue or mark it as a 
duplicate.

Original comment by jsakuda on 3 Feb 2009 at 6:03

GoogleCodeExporter commented 9 years ago

Original comment by jsakuda on 5 Feb 2009 at 6:47