Hide Forgot
When url which update checker is trying to pull version.json form is unreachable, broken it have wo daults: - error messsage is: 2016-12-01_11:35:44 ERROR: Error parsing JSON: text: [unexpected token near end of file] line: [1] column: [0] position: [0], callback error: [HTTP connection error] Should be only 2016-12-01_11:35:44 [HTTP connection error] The invalid json is different issue. On addition, the json file it uses as logging output is corrupted: { ... "2016-12-01_11:20:13_22": "ERROR: Error parsing JSON: text: [unexpected token near end of file] line: [1] column: [0] position: [0], callback error: [HTTP connection error]" Th closing bracket (maybe more?) is missing. Should be not Also, if previous version.json is already stored here, it is kept. As various verisons f jdk are sharing the directory, maybe failed attempt should remove the file?
(In reply to jiri vanek from comment #0) > - error messsage is: > 2016-12-01_11:35:44 ERROR: Error parsing JSON: text: [unexpected token near > end of file] line: [1] column: [0] position: [0], callback error: [HTTP > connection error] > > Should be only > 2016-12-01_11:35:44 [HTTP connection error] I'll fix that, going to report JSON error only if actual JSON parsing have been started. > On addition, the json file it uses as logging output is corrupted: Could you send an example of corrupted file written? In simple cases (like connection error), I see locally a well-formed trace.json with an error message as a last entry. (in Linux it is currently being written to ~/.config/update_checked instead of ~/.config/<vendor_name>/update_checker as "vendor_name" is not filled in config.json, but that is a different issue and affects only config.json generation - will fix this). > Also, if previous version.json is already stored here, it is kept. As > various verisons f jdk are sharing the directory, maybe failed attempt > should remove the file? Generally different versions of jdk shouldn't share this "work directory" (and this directory is deleted on uninstall/update): - for the same major version only one MSI can be installed at the same time - to distinguish dirs for different major versions (in future) I'd like to rename path: <userdata_dir>/RedHat/update_notifier to <userdata_dir>/RedHat/jdk8_update (or to fully-qualified jdk version). Wanted to ask whether such rename could cause problems to test scripts? Otherwise I'll include it into next version.
(In reply to Alex Kashchenko from comment #1) > (In reply to jiri vanek from comment #0) > > - error messsage is: > > 2016-12-01_11:35:44 ERROR: Error parsing JSON: text: [unexpected token near > > end of file] line: [1] column: [0] position: [0], callback error: [HTTP > > connection error] > > > > Should be only > > 2016-12-01_11:35:44 [HTTP connection error] > > I'll fix that, going to report JSON error only if actual JSON parsing have > been started. thanx. > > > On addition, the json file it uses as logging output is corrupted: > > Could you send an example of corrupted file written? In simple cases (like > connection error), I see locally a well-formed trace.json with an error > message as a last entry. Hmm. Something went wrong. My apologise - I runs before lunch - the last bracket was missing. In all launches now, the bracket is there. lets consider this as resovled Untill it popup again ....?-( > > (in Linux it is currently being written to ~/.config/update_checked instead > of ~/.config/<vendor_name>/update_checker as "vendor_name" is not filled in > config.json, but that is a different issue and affects only config.json > generation - will fix this). Considering the following issue, shouldnt it be ~/.config/<vendor_name>/package_name/update_checker ? > > > Also, if previous version.json is already stored here, it is kept. As > > various verisons f jdk are sharing the directory, maybe failed attempt > > should remove the file? > > Generally different versions of jdk shouldn't share this "work directory" > (and this directory is deleted on uninstall/update): > > - for the same major version only one MSI can be installed at the same time > - to distinguish dirs for different major versions (in future) I'd like to > rename path: > > <userdata_dir>/RedHat/update_notifier > > to > > <userdata_dir>/RedHat/jdk8_update > > (or to fully-qualified jdk version). > > Wanted to ask whether such rename could cause problems to test scripts? > Otherwise I'll include it into next version. That something the tests will adapt (and reason Why I wonted them to print it out) This location - because of various issues should be probaby resolved before release. We agree on ~/.config/<vendor_name>/??1/update_checker/??2 ??! is whethere to have product (whoch contains major version) in path, or n name ??2. if Name is fully qualified, then it is making decisison more strigtforward. But that depends on URL (1400072) and on update path we agree. (handling of major versions)
As we currently have only one product inside vendor dir and only single dir is required for this product - I am proposing to used product dir directly. Changed its name to include package name and version.
changeset with cleaner error message: https://github.com/ojdkbuild/contrib_update-notifier/commit/e8e7bdb9cc85d1024d996f0ceb8fe04b96d26fd4
This case is covered by checekr testsuite