| "Invalid ZIP archive" error reports [message #1767388] |
Wed, 05 July 2017 09:27  |
Eclipse User |
|
|
|
The AERI system is flooded with entries of kind "Invalid ZIP archive: ......somefile". The files are not necessarily actual Jar or Zip files that are in error, but often also other kind of files (pom.xml, .dll's and many more). The error usually is logged in JarPackageFragmentRoot.computeChildren.
There is not much Eclipse can do about this. It seems that users have invalid files on their classpath or corrupt Jars. So that is a user error from my perspective.
However, they usually get this kind of error popping up and some of them report them to AERI. There are currently >15k incidents of this kind. Only yesterday there were > 80 new entries.
I am wondering how we could improve the user experience. The first alternative is to suppress the error popping up and log them maybe with lower priority. The users might wonder if their projects don't behave as expected and might be not aware of a configuration issue.
The other alternative is to configure AERI to auto-reject these kind of errors with a detailed description that explains that it is not JDT's fault if something corrupt or invalid is on the classpath. This way at least those who try to report get notice that they have an invalid state that causes the issue. But those who don't report might get annoyed.
What idea your idea to address this issue?
~Karsten
|
|
|
|
|
|
|
| Re: "Invalid ZIP archive" error reports [message #1767471 is a reply to message #1767453] |
Thu, 06 July 2017 05:42  |
| Eclipse User |
|
|
|
Hi,
Karsten contacted me to look into this issue.
As there are some misconceptions about what happened with users experiencing that exception, let me first explain what happened for users until now.
- Eclipse logged the exception in question
- The Aeri client asked the Eclipse Error Reporting server whether it was interested in receiving the report
- The server then matched the exception to two problems (problem 1, problem 2), each with their own bug.
- As one of the problems was still open, the server replied that it was interested in the report.
- The client then asked the user to report
The two possible solutions I discussed with Karsten are to close both issues as NOT_ECLIPSE which would result in the AERI client not displaying anything to the user and no report being sent.
The second solution is to close both issues as WON'T FIX and set a "Custom Resolution Message" for both within the Error Reporting server UI.
This results in the user to get a message that states:
Thank you for your report. This problem has been marked as "Won't Fix." {customResolutionMessage}. If you disagree with this assessment, please visit bug 469591 and get in touch with the developers.
Karsten asked me to close the existing incidents/problems and draft a message for the users.
Thus, I've linked both problems to Bug 469591 which already was closed as "Won't Fix". and added a custom resolution message. Users now gets a message of:
Thank you for your report. This problem has been marked as "Won't Fix." It is caused by an invalid or corrupt classpath. Please check your classpath. If you disagree with this assessment, please visit bug 469591 and get in touch with the developers.
Note that the parts before and after the custom resolution message can only be changed for every problem that is marked as "Won't Fix".
Note further, that we have a very limited space for the custom resolution message in the notification. Thus it has to be kept quite short.
If you want to change that message, you can do so in both problems (problem 1, problem 2).
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04681 seconds
Home