ADMINGUI : Log viewer - search command not works fine

[glassfishrobot]

server -> general -> click - view log files

log viewer screen:

Search criteria does not work as expected.

Issue 1 : select log level as "SEVERE" and click search button.

Expected : Only SEVERE messages to be shown Actual : all the messages are showned ( including INFO, WARNINING etc )

Issue 2 : clicking "Records before xxx" and Records After xxx" does not displays the records actually and changes the record numbers ( incrementing to 10+ or decrementing to 10- )

Issue 3 : Change the log level values as "FINE" or "FINEST". ( server-config --> logger settings --> log level ) open the log viewer now you can see only very few records are listing.

Issue 4 : Text search does not works as it is expected. provide the "string" in the text and do the search and no changes in the listing values.

Issue 4 : Log file option (in modify search) does not displays any values.

Issue 6 : Advanced search is not working select the logger you want to see – click search button it is not filtering the logger you wanted.

In short logviewer is not working as it is expected.

checked in FF19, IE8

Environment

WIN 7 FF19

Affected Versions

[4.0_dev]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/20258
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @yaminikb
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented anilam said: I have tested all the different situations thats listed, and all of them works as expected in the latest build. All this is actually fixed when fixing #18950. Marking as resolved. Please verify with b84.

[glassfishrobot]

@glassfishrobot Commented ramesht said: I tested in windows FF / IE with Build 84 ( promoted ) and Build 85 (nightly). Both has the issues. Hence reopening the issues. Screen shot sent in mail.

[glassfishrobot]

@glassfishrobot Commented anilam said: Which of the 6 issues you reported above doesn't work for you ? The screen capture that you sent looks like for other instance than "server". Do you experience the issues with other instance only or you saw that with "server' also ?

[glassfishrobot]

@glassfishrobot Commented ramesht said: I am facing the search issue in server and also other instances. Issue 1 : Failed Issue 2 : Failed Issue 3 : Failed Issue 4 : works fine Issue 5 : Throws error Issue 6 : Failed

Screen shots sent as mail.

[glassfishrobot]

@glassfishrobot Commented anilam said: Sound like this is a platform issue. It works fine on Mac, but when i try this on Windows, I see the above issue you are seeing. Will investigate this. Can you also repeat the test on other platform, maybe a Linux also ? thanks.

[glassfishrobot]

@glassfishrobot Commented ramesht said: Here is the report done on Linux platform.

Issue 1 : working fine. But for INFO selection it displays "WARNING" also. Issue 2 : Working Fine Issue 3 : Working Fine Issue 4 : Working Fine Issue 5 : Error : "An error has occured". scenario : advance search ( Select a logger value and select "100" per page ) .

screen shot sent as mail.

[glassfishrobot]

@glassfishrobot Commented anilam said: For #1. Did you select the "Do not include more severe message' checkbox ? If you don't, then it will display more severe msg also, ie, if you select INFO, it will show 'INFO, WARNING, SEVERE, ALERT and EMERGENCY' also. Or, if you select 'FINEST', It will display everything from FINEST to EMERGENCY. so, if that checkbox is not selected, thats whats designed.

If you check the checkbox, then it will display only that level.

I cannot reproduce #5, and the image thats sent to me doesn't match that scenario.

[glassfishrobot]

@glassfishrobot Commented anilam said: This is a windows platform issue. All the issue reported is due to the fact that no logfile name is returned if run on Windows.

The following URL http://localhost:4848/management/domain/view-log/details/lognames.json?instanceName=server returns the list of lognames correctly on Mac and Linux. eg.

{"InstanceLogFileNames": ["server.log","server.log_2013-04-15T14-46-37"]}

However, on windows platform, it returns an empty list, not even "server.log"

{"InstanceLogFileNames": []}

The current gui code depends on the logfile name and thats causing all the issues mentioned in this bug report. I have tried that if the logfile name returned is correct, then all the above issues go away.

I am transferring this to 'logging' and upgrading this to P2 since this is major feature broken on windows platform.

[glassfishrobot]

@glassfishrobot Commented ntramesh said: Issue #1 is not selected "Do not include more severe message". – No issues – working as per the design. Issue #5 This is a corner case. 1 change all the loglevels to "FINEST". 2. ( wait for some time ) and now open the log viewer 3. select advance search. ( now you can see the "specific range" option is not selected bug the range is displayed ) 4. select display to 100 entries per page and click search. 5. you will hit with the error page. ( attached with this ).

Sent the screenshot in mail.

[glassfishrobot]

@glassfishrobot Commented anilam said: I have tested this with the logging.jar that Sandeep provided that has the fix on both Windows and Mac. I cannot reproduce any of the issues mentioned. So, the fix is working. As for the corner case that Ramesh reported above, I cannot reproduce it following the exact steps.

[glassfishrobot]

@glassfishrobot Commented sandeep.shrivastava said:

• What is the impact on the customer of the bug?

This affects the log viewer functionality on the Windows platform. The initial display of log records is from the current log file only. Subsequent log search criteria and viewing from rotated files does not work.

How likely is it that a customer will see the bug and how serious is the bug?

It is highly likely that the customer will run into this issue.

Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?

Yes. There has been refactoring of the log viewer back end code to support the new default ODL format in addition to the Uniform format.

What CTS failures are caused by this bug?

None

• What is the cost/risk of fixing the bug?

The fix involves using the absolute path returned from the File object instead of the string values read from the config which contained unix style separator.

How risky is the fix? How much work is the fix? Is the fix complicated?

The fix is fairly straight forward to the use the absolute path from the File object, which works on all platforms.

• Is there an impact on documentation or message strings?

No

• Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

This only affects the UI. Anissa has verified the fix on Windows and Mac.

• Which is the targeted build of 4.0 for this fix?

4.0_b85

• If this an integration of a new version of a component from another project, what are the changes that are being brought in? This might be list of Jira issues from that project or a list of revision messages.

N/A

[glassfishrobot]

@glassfishrobot Commented tmueller said: Approved for 4.0.

[glassfishrobot]

@glassfishrobot Commented sandeep.shrivastava said: This is fixed with revision 61489.

[glassfishrobot]

@glassfishrobot Commented Was assigned to sandeep.shrivastava

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-20258

[glassfishrobot]

@glassfishrobot Commented Reported by ramesht

[glassfishrobot]

@glassfishrobot Commented Marked as fixed on Thursday, April 18th 2013, 5:00:39 am