Apache OpenOffice (AOO) Bugzilla – Issue 107512
comphelper: some services, singletons are no more registered.
Last modified: 2017-05-20 10:28:53 UTC
During debugging of something, I found out that too many exceptions are generated in sfx2. It turned out to be thanks to attempts to write to a log that is (I suppose) turned off in the production builds. But still, the code tries to construct the log, creates a ComponentContext, and eventually throws an exception - which seems highly inefficient to me ;-) I'll attach a patch - please have a look if it does not break the original intent of the log.
Created attachment 66546 [details] The patch.
Created attachment 66547 [details] Ah, forgotten initialization in SfxObjectShell_Impl constructor.
Mikhail, I think this is part of your "mysterious writer errors" debuggin code. Please comment.
This log-ring is intended to be used in the pro-version. It is memory-based and has small length, so that it does not affect the performance. The log file is generated only in case of document saving problem ( that is also not interesting from the performance point of view, since the UI-interaction is used in this case ). The log is important to investigate some mysterious problems, that are not reproducible by us, or reproducible once pro year. Of course the problems look to be not so important in this case, but if a problem is reproducible once pro year for a user, it affects a firm with 700 users about twice a day. As for the exceptions, the service is pretty simple, it should be always be possible to instantiate it. If it is not possible, then there is a bug in the service implementation or usage. I will take a look. For now I set the issue to OOo3.2, since it looks to be important to have the locking mechanics in 3.2.
The registration of the singleton was just thrown away in DEV300_m60. Probably an integration problem, after integration of the dba32b ( that seems to introduce a new file, that implements the registration of comphelper services ), the singleton is no more registered. mav->ul: I would like to fix it as a showstopper since the fix is very easy ( the singleton should be just registered again ), and the singleton would be very helpful to allow a user provide more feedback in case of problems during document storing.
"com.sun.star.task.InteractionHandlerWrapper" is also no more registered. Changing the description accordingly. I am not sure whether other services in comphelper are affected.
The last comment from me is not correct. The implementation of the service "com.sun.star.task.InteractionHandlerWrapper" was never registered, it is possible to register it, but for now it created directly. Sorry for inconvenience. So as before, the bug is only about the LogRing singleton.
The situation looks to be clear now. That was a problem during integration of cws fwk103. The cws was based on m47 and was integrated in m51. The cws dba32b was integrated in m50. So during the integration of fwk103 it was not detected that it contains changes in the deleted file. The log also shows that there were some other problems with integration of the cws ( one new file was forgotten during integration of the cws to the master, but that was detected during master building and fixed ).
Should be fixed in jl146 now.
mav->tm: Please verify the issue. To do so please let a document file be readonly, and try to overwrite it using SaveAs. As result a number of error-messages will be shown ( although there should be only one error message, this is actually also a bug, but of low priority ). After all the error-messages has been shown there should be a file in <ooo user directory>/temp/ named document_io_logring.txt
checked and verified in cws jl146 -> OK !