[Libreoffice-bugs] [Bug 111811] The ImplementationName " com.sun.star.comp.math.FormulaDocument was changed to upper case "M" in " .Math." New incompatibilities!

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=111811

--- Comment #7 from Stephan Bergmann <sbergman at redhat.com> ---
This is a bit complicated:

1  Requesting the SmModel UNO object implementation (e.g. via ServiceManager's
css.lang.XMultiServiceFactory::createInstance) has always been done with
uppercase "com.sun.star.comp.Math.FormulaDocument", as spelled out in
SmDocument_getImplementationName (starmath/source/unodoc.cxx) ever since
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=f807e70ecddb785474289e2553968ec376b28d6f>
"INTEGRATION: CWS mav3 (1.1.2); FILE ADDED".  (First by the code in
component_writeInfo/getFactory calling SmDocument_getImplementationName since
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=726125348e86b557e27ea09148f2e7afe5361bbb>
"INTEGRATION: CWS mav3 (1.4.38); FILE MERGED".  Then by replacing
component_writeInfo (but keeping component_getFactory calling
SmDocument_getImplementationName) with starmath/util/sm.component in
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=01c2f02ec849927b69d9ec7b9c1c147ad56b599f>
"sb129: #i113189# change UNO components to use passive registration".

2  Asking the SmModel UNO object implementation for its implementation name
(via css.lang.XServiceInfo::getImplementationName, i.e., definition of
SmModel::getImplementationName in starmath/source/unomodel.cxx) had returned
various values over time, most of them not matching the value from (1) above:

** "SmModel" since
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=d791366863cf9659a01b171ce0e727bfe2f28cdf>
"initial import" in 2000.

** "com.sun.star.comp.math.FormulaDocument" since
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=495f53c8b40170a05ff95e8573131fba599c6cab>
"INTEGRATION: CWS fwkq1 (1.24.26); FILE MERGED" in 2003.

** "com.sun.star.comp.Math.FormulaDocument" since
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=3099c70b11c7e5b80fe4dbe3dc99171fb38c6fc2>
"Fix various XServiceInfo implementations" in 2015, to get the values of (1)
and (2) in sync for postprocess/CppunitTest_services.mk (which checks that such
values are actually in sync).

Now, to turn (2) back to lowercase "com.sun.star.comp.math.FormulaDocument",
there would be two options:

Either also change the value for (1) to lowercase
"com.sun.star.comp.math.FormulaDocument".  That appears to be a rather
dangerous change, potentially leading to broken 3rd party code; in the LO code
itself, there are various places that would need to be adapted (and cause "make
check" to fail if not adapted).

Or else make (1) and (2) inconsistent again.  That would mean that
postprocess/CppunitTest_services.mk needs to be dumbed down, and would
re-introduce a (potentially confusing) inconsistency.

Neither of these two options looks appealing.

3rd-party code should not rely on the implementation names of UNO objects. 
Some such code certainly does, for various reasons.  In comment 3 Wolfgang
Jäger states that two questioners in forums had issues with this, but leaves it
unclear how severe those issues were (i.e., whether it actually broke existing
code).  In comment 0 and comment 6 he remains vague ("most likely", "no bug
report about it was filed seemingly") on whether the current state has known
bad consequences.

Thus, unless evidence of known bad consequences is brought forward, I would
like to close this issue as WONTFIX.  (And will do so if there's no new input
coming.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20170816/6d232c2b/attachment-0001.html>