Hi,
I'd like to improve the error messages that back-config returns via LDAP to the client. Currently in many case you only get back a very generic error messages. E.g. when trying to add a second monitor database you just get: Error code LDAP_OTHER with the diagnostic message set to "<olcDatabase> failed init". To find out what really went wrong you need to dig up the logfiles.
One way to get more meaningful error messages to the client would be by adding an additional const char** text parameter to the _db_init functions (and probably some other of the BI_db_func() functions as well), similiar to what is done in many other case when error messages need to be passed to the caller.
Does somebody have better ideas how to achieve this?
Ralf Haferkamp wrote:
Hi,
I'd like to improve the error messages that back-config returns via LDAP to the client. Currently in many case you only get back a very generic error messages. E.g. when trying to add a second monitor database you just get: Error code LDAP_OTHER with the diagnostic message set to "<olcDatabase> failed init". To find out what really went wrong you need to dig up the logfiles.
One way to get more meaningful error messages to the client would be by adding an additional const char** text parameter to the _db_init functions (and probably some other of the BI_db_func() functions as well), similiar to what is done in many other case when error messages need to be passed to the caller.
Does somebody have better ideas how to achieve this?
That sounds like a good enough approach. Go ahead...
Howard Chu wrote:
Ralf Haferkamp wrote:
Hi,
I'd like to improve the error messages that back-config returns via LDAP to the client. Currently in many case you only get back a very generic error messages. E.g. when trying to add a second monitor database you just get: Error code LDAP_OTHER with the diagnostic message set to "<olcDatabase> failed init". To find out what really went wrong you need to dig up the logfiles.
One way to get more meaningful error messages to the client would be by adding an additional const char** text parameter to the _db_init functions (and probably some other of the BI_db_func() functions as well), similiar to what is done in many other case when error messages need to be passed to the caller.
Does somebody have better ideas how to achieve this?
That sounds like a good enough approach. Go ahead...
What about passing a SlapReply *, or a specific type? SlapReply already contains sr_err and sr_text, and other useful parameters that could be filled by functions for the purpose of being returned to a client (I can figure out possible uses of sr_matched and of sr_ctrls for future extensibility). Probably, a REP_INTERNAL should be added to the REP_* enum, to clearly distinguish responses to internal operations not related to the protocol.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
On Monday 07 May 2007 21:26, Pierangelo Masarati wrote:
Howard Chu wrote:
Ralf Haferkamp wrote:
Hi,
I'd like to improve the error messages that back-config returns via LDAP to the client. Currently in many case you only get back a very generic error messages. E.g. when trying to add a second monitor database you just get: Error code LDAP_OTHER with the diagnostic message set to "<olcDatabase> failed init". To find out what really went wrong you need to dig up the logfiles.
One way to get more meaningful error messages to the client would be by adding an additional const char** text parameter to the _db_init functions (and probably some other of the BI_db_func() functions as well), similiar to what is done in many other case when error messages need to be passed to the caller.
Does somebody have better ideas how to achieve this?
That sounds like a good enough approach. Go ahead...
What about passing a SlapReply *, or a specific type?
I'd like to avoid defining an addtional type. But using SlapReply for my purpose would certainly be possible I think. I'll take a look into this.
SlapReply already contains sr_err and sr_text, and other useful parameters that could be filled by functions for the purpose of being returned to a client (I can figure out possible uses of sr_matched and of sr_ctrls for future extensibility). Probably, a REP_INTERNAL should be added to the REP_* enum, to clearly distinguish responses to internal operations not related to the protocol.
Ralf Haferkamp wrote:
What about passing a SlapReply *, or a specific type?
I'd like to avoid defining an addtional type. But using SlapReply for my purpose would certainly be possible I think. I'll take a look into this.
Passing a pointer to struct, rather that a char**, would save you from reworking the whole API once more, in case you need to pass/want back more elaborate data in the future. Passing a SlapReply* could require twice the effort as soon as your needs diverge from what's available in SlapReply; this could be avoided by adding yet another structure to SlapReply's union for internal purposes, if ever required.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
On Monday 07 May 2007 21:26, Pierangelo Masarati wrote:
Howard Chu wrote:
Ralf Haferkamp wrote:
Hi,
I'd like to improve the error messages that back-config returns via LDAP to the client. Currently in many case you only get back a very generic error messages. E.g. when trying to add a second monitor database you just get: Error code LDAP_OTHER with the diagnostic message set to "<olcDatabase> failed init". To find out what really went wrong you need to dig up the logfiles.
One way to get more meaningful error messages to the client would be by adding an additional const char** text parameter to the _db_init functions (and probably some other of the BI_db_func() functions as well), similiar to what is done in many other case when error messages need to be passed to the caller.
Does somebody have better ideas how to achieve this?
That sounds like a good enough approach. Go ahead...
What about passing a SlapReply *, or a specific type? SlapReply already contains sr_err and sr_text, and other useful parameters that could be filled by functions for the purpose of being returned to a client (I can figure out possible uses of sr_matched and of sr_ctrls for future extensibility). Probably, a REP_INTERNAL should be added to the REP_* enum, to clearly distinguish responses to internal operations not related to the protocol.
After having some time to look again at this I think the easiest approach would be to just pass the ConfigArgs pointer down to the BI_db_func functions (_db_init, _db_open and _db_close). That way they could directly print into the ca->msg field which finally ends up in sr_text of the SlapReply structure.
regards, Ralf
-
Howard Chu -
Pierangelo Masarati -
Ralf Haferkamp