| Summary: | Undocumented behavior of com.sun.star.sdb.DatabaseContext implementation of com.sun.star.uno.XNamingService | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Oleg Shchelykalnov <olegshtch> |
| Component: | sdk | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | buzea.bogdan, mentoring, mikekaganski, olegshtch, sberg.fun, xiscofauli |
| Priority: | medium | Keywords: | difficultyMedium, easyHack, skillCpp |
| Version: | 6.4.2.2 release | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
|
Description
Oleg Shchelykalnov
2020-03-30 13:46:51 UTC
@Stephan, I thought you might be interested in this issue @Mike, could you please help with this issue ? FTR: the definition of the interface behavior is given in udkapi/com/sun/star/uno/XNamingService.idl [1]. The implementation of DatabaseContext's registerObject is in dbaccess/source/core/dataaccess/databasecontext.cxx. After initial argument checks, it calls registerDatabaseLocation, which in turn calls DatabaseRegistrations::registerDatabaseLocation, and the latter calls impl_checkValidName_throw_must_not_exist. So to conform to the documented behavior, DatabaseContext::registerObject should ensure to de-register existing registration for the name before trying to register. Similar for revokeObject. [1] https://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1uno_1_1XNamingService.html By the way, OSDBCDriverManager::registerObject in connectivity/source/manager/mdrivermanager.cxx also throws in this case. Could be fixed in this easy hack. The task includes checking commit history - if it contains hints why were the throws added; and also checking which places call these functions: should they be changed to account for the changed behaviour. |