----- Original Message -----
From: "Shubhendu Tripathi" <shtripat@redhat.com> To: derez@redhat.com, "engine-devel" <engine-devel@ovirt.org> Cc: "Dusmant Pati" <dpati@redhat.com> Sent: Wednesday, November 6, 2013 12:07:34 PM Subject: IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class
Hi,
In the case of Gluster, as there are no one to one mappings available for all the error messages from Gluster, we set the error in the VdcFault object as NULL. We also populate the actual error from the Gluster as error message in the fault object.
/getReturnValue().getExecuteFailedMessages().add(error);// //getReturnValue().getFault().setMessage(error);// //getReturnValue().getFault().setError(null);/
Because of above settings and the below code snippet in /Frontend.java/ class the error message as is gets displayed on the error dialog - / //public String translateVdcFault(final VdcFault fault) {// // return getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() == null// // ? fault.getMessage() : fault.getError().toString());// //}// / Well and good till now !!
But while translation of the error messages, all the occurrences of "." get replaced with "_". This causes an issue for the gluster errors. If the error message sent from gluster has "."s (say IP Address of a host or FQDN for a host), that also gets replaced with "_" and the error message does not look correct.
This mechanism of replacing [1] has been introduced to allow proper message translation when retrieving a message key that contains dots. E.g. AppErrors.properties -> VALIDATION.ROLES.NAME.MAX is translated to VALIDATION_ROLES_NAME_MAX in AppErrors.java interface (as interface signatures cannot contain dots. Note that this process shouldn't address the message; i.e. only the key is examined for dots. As you've mentioned VdsmErrorsTranslator I guess there's an issue only when translating VdsmErrors messages. Can you please send an example of a message usage? (and maybe try the same message using AppErrors instead) [1] ErrorTranslator -> translateErrorTextSingle()
Request your suggestion for handling such a case.
*PS: *One thing I can think of is, introducing a flag called /isExternalError/ in /VdcFault/ class to identify if the source of the fault is external. From Gluster we would set the flag as /true/, and while replacement of "." with "_", if the flag is set it will not do the replacements.
Regards, Shubhendu