[Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class

Shubhendu Tripathi shtripat at redhat.com
Wed Nov 6 14:33:53 UTC 2013


On 11/06/2013 07:41 PM, Einav Cohen wrote:
>> but if the message is not a key, and would be displayed as-is, on "." to "_"
>> replacement should take place.
> on -> no*
This solution looks fine. If the error message is not found in the map, 
we can revert back to original message which has the "."s.
Request comments from others as well.
>
>> ----- Original Message -----
>> From: "Einav Cohen" <ecohen at redhat.com>
>> Sent: Wednesday, November 6, 2013 9:10:09 AM
>>
>>> ----- Original Message -----
>>> From: "Alexander Wels" <awels at redhat.com>
>>> Sent: Wednesday, November 6, 2013 8:28:13 AM
>>>
>>> Looking at the code, if you start the error message with a $ it will not do
>>> the . to _ replacement. Not sure if your error message will now simply
>>> start
>>> with a $, but it is worth a try I guess.
>> AFAIK: the '$' prefix is for variable-value message.
>> e.g. if you have a message "cannot run VM ${vm-name}" and another one
>> "$vm-name vm1",
>> then their combination would eventually yield "cannot run VM vm1".
>> Also, I think that messages that begin with "$" cannot be displayed when they
>> are on their own.
>> i.e. if you will get message "$vm-name vm1" 'alone', nothing will eventually
>> be displayed.
>> but, as I mentioned, if you will get message "$vm-name vm1" along with
>> message "cannot run
>> VM ${vm-name}", eventually "cannot run VM vm1" will be displayed.
>>
>> I think that the replacement of "." to "_" should be done only if the message
>> represents a *key* in the relevant resource (VdsmErrors in this case).
>> but if the message is not a key, and would be displayed as-is, on "." to "_"
>> replacement
>> should take place.
>> adding Derez for his thoughts (I think that he changed something around it a
>> while ago).
>>
>>> On Wednesday, November 06, 2013 03:37:34 PM Shubhendu Tripathi wrote:
>>>> 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.
>>>>
>>>> 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 at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>




More information about the Devel mailing list