Apache OpenOffice (AOO) Bugzilla – Issue 90585
multiple assertions when attempting to check for updates / online update not working
Last modified: 2008-06-11 13:16:15 UTC
- ensure your OOo is set up to automatically search for updates - start OOo - wait a few seconds => several assertions pop up, which all together seem to suggest that some corrupt XML file is parsed If you disable the online update, then this won't happen. Also, if you manually start the online update, then the assertions will also occur, and a message "Checking for an update failed" will be displayed. So, it's quite obvious this really is an online update issue.
This is a regression between m17 and m18. Also, since it affects quite basic functionality, it certainly should be fixed for 3.0. (If there weren't the workaround to disable the automatic online update, I would even have considered this a P1, since it would have made working with a non-product version quite impossible.)
Works for me now, looks like a wrong answer from update server -> set target to 3.1
Please take over.
Hmm, the only 'broken XML detection' we could do beforehand with reasonable effort is a check for an completely empty document. It does not make sense to validate the XML document we get from one of our update servers by hand before we hand it over to the parser. @fs: do you remember whether unoxml "only" complained about an empty XML file or were there other assertions as well ?
hi, in cws xmlfix2 (merged in m18) there were changes to turn error messages from libxml2 into assertion failures. i believe that before, these error messages would printed on the stderr by libxml2, which is also bad (actually, lo did this change when he was still at sun, so i don't know for sure). generally, this approach seems sane to me, because there is some notification on the details of errors that occur, and normal users don't get to see those irrelevant details. so, is this really a problem in practice, or did you just hit some transient issue?
> do you remember whether unoxml "only" complained about an empty XML file or > were there other assertions as well ? The were a number of other assertions, something like "< expected", or like this. Unfortunately, I didn't log them in detail > in cws xmlfix2 (merged in m18) there were changes to turn error messages from > libxml2 into assertion failures. Ah, that explains why the problem did not happen in m17, which made me think it's really a problem of m18. > so, is this really a problem in practice, or did you just hit some transient > issue? Well, since it was caused by an invalid reply from the update server, I agree that this is of no practical relevance. The only thing which is left for me (but which is probably another issue), is the error message: "Checking for an update failed" is far from being useful for the user. But we can probably close this issue here, if all agree. Thanks for your investigations, and sorry for the noise.
resolving the issue as "works for me".
.