Difference between revisions of "Mozilla2Seamonkey/Problem Log/Common"
From Apache OpenOffice Wiki
B michaelsen (Talk | contribs) |
|||
| (3 intermediate revisions by one other user not shown) | |||
| Line 15: | Line 15: | ||
| implement <code>nsIAbLDAPAttributeMap</code>, and provide it when doing an LDAP search. | | implement <code>nsIAbLDAPAttributeMap</code>, and provide it when doing an LDAP search. | ||
|- align="left" style="background-color:#eeeeee" | |- align="left" style="background-color:#eeeeee" | ||
| − | | '' | + | | ''remark'' |
|- | |- | ||
| This opens the door for a often-requested enhancement: People want to be able to modify the attribute mapping, to accommodate it to their specific LDAP schema. So far, this is not possible, since it would require adjustments to the Mozilla code. Now, with SeaMonkey retrieving the mapping from our driver at runtime, we could implement a configuration-based solution, which loads the mapping from the configuration. This way, people could easily adjust it to their needs. | | This opens the door for a often-requested enhancement: People want to be able to modify the attribute mapping, to accommodate it to their specific LDAP schema. So far, this is not possible, since it would require adjustments to the Mozilla code. Now, with SeaMonkey retrieving the mapping from our driver at runtime, we could implement a configuration-based solution, which loads the mapping from the configuration. This way, people could easily adjust it to their needs. | ||
| Line 27: | Line 27: | ||
|- | |- | ||
| displaying LDAP data works fine the first time, but doing a simple reload times out | | displaying LDAP data works fine the first time, but doing a simple reload times out | ||
| + | |- align="left" style="background-color:#eeeeee" | ||
| ''reason'' | | ''reason'' | ||
|- | |- | ||
| There's a bug in SeaMonkey's <code>nsAbLDAPDirectoryQuery::DoQuery</code> implementation: When doing a second query on the same object, nearly all parameters passed to this query are ignored, and the parameters from the previous query are re-used. In particular, this applies to the listener object which is to be notified about query results: The second query still notifies the first listener. | | There's a bug in SeaMonkey's <code>nsAbLDAPDirectoryQuery::DoQuery</code> implementation: When doing a second query on the same object, nearly all parameters passed to this query are ignored, and the parameters from the previous query are re-used. In particular, this applies to the listener object which is to be notified about query results: The second query still notifies the first listener. | ||
I suppose is this the root cause of BugZilla's bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=124553 124553] and [https://bugzilla.mozilla.org/show_bug.cgi?id=297549 297549]. Unfortunately, the fix for those bugs is too far away from the SeaMonkey 1.1.x code base, so we cannot easily re-use it. | I suppose is this the root cause of BugZilla's bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=124553 124553] and [https://bugzilla.mozilla.org/show_bug.cgi?id=297549 297549]. Unfortunately, the fix for those bugs is too far away from the SeaMonkey 1.1.x code base, so we cannot easily re-use it. | ||
| + | |- align="left" style="background-color:#eeeeee" | ||
| ''solution'' | | ''solution'' | ||
|- | |- | ||
| − | | Fix <code>nsAbLDAPDirectoryQuery::DoQuery</code> to respect the parameters of the second query. Admittedly, I don't understand the collaboration of all involved classes, and | + | | Fix <code>nsAbLDAPDirectoryQuery::DoQuery</code> to respect the parameters of the second query. Admittedly, I don't fully understand the collaboration of all involved classes, and there might be side effects of the patch. However, I didn't find them so far :) |
| + | Patch committed as <code>moz/patches/consecutive_ldap_queries.patch</code>, and added to both <code>seamonkey-source-1.1.12.patch</code> and <code>seamonkey-source-1.1.13.patch</code>. | ||
|} | |} | ||
| + | [[Category:Database]] | ||
Latest revision as of 00:38, 16 March 2010
| displaying an LDAP directory does not work |
| problem |
connecting to an LDAP server seems to work fine, a table named LDAP directory is displayed. However, upon opening this table by double-clicking it, the data table view comes up empty, and an error message saying "SQL Status: HY000 An error occurred while executing the query." is displayed. Quite unhelpful.
|
| reason |
In SeaMonkey, the mapping between LDAP attributes (such as "ou") and address book properties (such as "Department") is not hard-coded in the source anymore, but when doing an LDAP search, an implementation of nsIAbLDAPAttributeMap has to be provided, which describes this mapping. Since in the current driver, this implementation does not yet exist, LDAP searches fail completely.
|
| solution |
implement nsIAbLDAPAttributeMap, and provide it when doing an LDAP search.
|
| remark |
| This opens the door for a often-requested enhancement: People want to be able to modify the attribute mapping, to accommodate it to their specific LDAP schema. So far, this is not possible, since it would require adjustments to the Mozilla code. Now, with SeaMonkey retrieving the mapping from our driver at runtime, we could implement a configuration-based solution, which loads the mapping from the configuration. This way, people could easily adjust it to their needs. |
| executing a statement against an LDAP connection works only once |
| problem |
| displaying LDAP data works fine the first time, but doing a simple reload times out |
| reason |
There's a bug in SeaMonkey's nsAbLDAPDirectoryQuery::DoQuery implementation: When doing a second query on the same object, nearly all parameters passed to this query are ignored, and the parameters from the previous query are re-used. In particular, this applies to the listener object which is to be notified about query results: The second query still notifies the first listener.
I suppose is this the root cause of BugZilla's bugs 124553 and 297549. Unfortunately, the fix for those bugs is too far away from the SeaMonkey 1.1.x code base, so we cannot easily re-use it. |
| solution |
Fix nsAbLDAPDirectoryQuery::DoQuery to respect the parameters of the second query. Admittedly, I don't fully understand the collaboration of all involved classes, and there might be side effects of the patch. However, I didn't find them so far :)
Patch committed as |
