----- Original Message ----- > From: "Shubhendu Tripathi" <shtri...@redhat.com> > To: "Daniel Erez" <de...@redhat.com> > Cc: "engine-devel" <engine-devel@ovirt.org>, "Dusmant Pati" <dp...@redhat.com> > Sent: Wednesday, November 6, 2013 4:31:52 PM > Subject: Re: IMP: Regarding an issue while translating the error messages for > gluster using ErrorTranslator class > > On 11/06/2013 07:43 PM, Daniel Erez wrote: > > > > ----- Original Message ----- > >> From: "Shubhendu Tripathi" <shtri...@redhat.com> > >> To: de...@redhat.com, "engine-devel" <engine-devel@ovirt.org> > >> Cc: "Dusmant Pati" <dp...@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? > One example of the error message which is shown on the dialog after > translation is as below - > > /"Error while executin action Create Gluster Volume: Volume create > failed error: Staging failed on //*10_70_43_122_*//Error: /export/vol1-a > is already part of a volume"/
What are the keys that been sent from the engine (i.e. the message before translation)? > > If you see the highlighted portion not only the dots in IP address but > also the full stop is changed to "_". > > (and maybe try the same message using AppErrors instead) > There are no one to one mapping of these messages in AppErrors as they > arise randomly, so in such cases we throw the VDSM error message as is > on the dialog. > > > > [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 > >> > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel