Bug 100715 - [logview] LogReader does not read in multi-line messages
Summary: [logview] LogReader does not read in multi-line messages
Status: VERIFIED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.1   Edit
Hardware: All All
: P3 trivial (vote)
Target Milestone: 3.4 M4   Edit
Assignee: Jacek Pospychala CLA
QA Contact:
URL:
Whiteboard:
Keywords: bugday, contributed
: 139729 219066 236519 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-06-18 22:29 EDT by Brock Janiczak CLA
Modified: 2008-06-10 21:21 EDT (History)
5 users (show)

See Also:
baumanbr: review? (caniszczyk)


Attachments
mylyn/context/zip (807 bytes, application/octet-stream)
2007-11-07 20:06 EST, Chris Aniszczyk CLA
no flags Details
patch (2.70 KB, patch)
2007-11-29 18:54 EST, Jacek Pospychala CLA
no flags Details | Diff
mylyn/context/zip (1.35 KB, application/octet-stream)
2007-11-29 18:54 EST, Jacek Pospychala CLA
no flags Details
logfile (2.63 KB, text/plain)
2007-11-29 18:55 EST, Jacek Pospychala CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brock Janiczak CLA 2005-06-18 22:29:16 EDT
Version: 3.1.0
Build id: I20050617-1618

Multi line log messages are being parsed but only the first line is being put
into the LogEntry record.  When you open a log entry in the log viewer you
should be able to see the entire message.

The entry i am trying to read looks like this:

!ENTRY org.tigris.jira.core 1 -1 2005-06-19 12:01:30.15
!MESSAGE URL:
http://jira.atlassian.com/secure/IssueNavigator.jspa?view=rss&decorator=none&reset=true&tempMax=100&pid=10240&createdPrevious=604800000&sorter/field=created&sorter/order=DESC
Processed: 257 kb at 193.35938 kb/s in 1.329 second(s)
Compression ratio of 83.34071 percent (42 kb read)
Comment 1 Stephen White CLA 2006-08-29 09:38:37 EDT
I am seeing the same problem in Eclipse 3.2, however the problem only occurs if the multi-line log entry is the last entry in the log file.  Earlier entries in the file are read fine.

Looking at LogReader.java it is clear why this is the case.  When the state is changed away from TEXT_STATE the writerState is checked, with code such as:

if (writerState == MESSAGE_STATE && current != null){
	String message = current.getMessage() + swriter.toString();
	message = message.trim();
	current.setMessage(message);
}

being invoked to save any further lines of text that have been read, prior to calling: writer.close();

However, if the end of file is reached the state is never changed away from TEXT_STATE, and it is down to the finally block to close the writer - which it does.  However the finally block doesn't save the text contained in the writer, it just throws it away.  I should be able to grab a current copy of the code and produce a patch if that'd help get this issue resolved.
Comment 2 Brian Bauman CLA 2006-08-29 11:27:55 EDT
Not sure we could turn down an offer for help ;-)  Attaching a patch would help get the issue resolved faster.
Comment 3 Chris Aniszczyk CLA 2007-11-07 20:05:39 EST
*** Bug 139729 has been marked as a duplicate of this bug. ***
Comment 4 Chris Aniszczyk CLA 2007-11-07 20:06:39 EST
tagging bugday
Comment 5 Chris Aniszczyk CLA 2007-11-07 20:06:46 EST
Created attachment 82401 [details]
mylyn/context/zip
Comment 6 Jacek Pospychala CLA 2007-11-29 18:54:50 EST
Created attachment 84115 [details]
patch

The only problem I found with multiline messages was that only the last message in log file didn't have complete message. 

Also regarding the duplicate bug -  it refered to eating empty lines in messages, which is also fixed in attached patch.

Note, it may conflict with bug 207344
Comment 7 Jacek Pospychala CLA 2007-11-29 18:54:54 EST
Created attachment 84116 [details]
mylyn/context/zip
Comment 8 Jacek Pospychala CLA 2007-11-29 18:55:49 EST
Created attachment 84117 [details]
logfile

logfile used to test this bug.
Comment 9 Brian Bauman CLA 2007-11-30 10:39:54 EST
Chris, after you get over your jet lag can you review this patch?  If you are too busy, let me know.
Comment 10 Chris Aniszczyk CLA 2007-12-01 04:54:29 EST
Cool stuff. It worked in my tests. Released to HEAD.

Thanks Jacek :)
Comment 11 Chris Aniszczyk CLA 2007-12-01 04:56:36 EST
By the way, I can't believe how long this one was open for :)
Comment 12 Brian Bauman CLA 2007-12-11 13:44:49 EST
verified in I20071211-0010.

Nice job fixing this bug Jacek. I remember looking at this one in the past thinking it should not be too hard, but then finding out it required a lot of investigation to get it right.  Good job!
Comment 13 Chris Aniszczyk CLA 2008-02-19 14:58:32 EST
*** Bug 219066 has been marked as a duplicate of this bug. ***
Comment 14 Chris Aniszczyk CLA 2008-06-10 21:21:34 EDT
*** Bug 236519 has been marked as a duplicate of this bug. ***