1:31 a.m.
This is a multi-part message in MIME format.
--------------040302010801050202030308
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 11/06/2013 09:29 PM, Daniel Erez wrote:
----- Original Message -----
> From: "Shubhendu Tripathi" <shtripat(a)redhat.com>
> To: "Daniel Erez" <derez(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Dusmant Pati"
<dpati(a)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" <shtripat(a)redhat.com>
>>> To: derez(a)redhat.com, "engine-devel"
<engine-devel(a)ovirt.org>
>>> Cc: "Dusmant Pati" <dpati(a)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)?
We set message code as NULL and error message is set as is whatever is
received from VDSM. Message contains dots (".") as part of it.
Code snippet is shown below -
/getReturnValue().getExecuteFailedMessages().add(error);
getReturnValue().getFault().setMessage(error);
getReturnValue().getFault().setError(null);/
> 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
>>>
>
--------------040302010801050202030308
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/06/2013 09:29 PM, Daniel Erez
wrote:<br>
</div>
<blockquote
cite="mid:1514562916.26958300.1383753561998.JavaMail.root@redhat.com"
type="cite">
<pre wrap="">
----- Original Message -----
</pre>
<blockquote type="cite">
<pre wrap="">From: "Shubhendu Tripathi" <a
class="moz-txt-link-rfc2396E"
href="mailto:shtripat@redhat.com"><shtripat@redhat.com></a>
To: "Daniel Erez" <a class="moz-txt-link-rfc2396E"
href="mailto:derez@redhat.com"><derez@redhat.com></a>
Cc: "engine-devel" <a class="moz-txt-link-rfc2396E"
href="mailto:engine-devel@ovirt.org"><engine-devel@ovirt.org></a>,
"Dusmant Pati" <a class="moz-txt-link-rfc2396E"
href="mailto:dpati@redhat.com"><dpati@redhat.com></a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">
----- Original Message -----
</pre>
<blockquote type="cite">
<pre wrap="">From: "Shubhendu Tripathi" <a
class="moz-txt-link-rfc2396E"
href="mailto:shtripat@redhat.com"><shtripat@redhat.com></a>
To: <a class="moz-txt-link-abbreviated"
href="mailto:derez@redhat.com">derez@redhat.com</a>,
"engine-devel" <a class="moz-txt-link-rfc2396E"
href="mailto:engine-devel@ovirt.org"><engine-devel@ovirt.org></a>
Cc: "Dusmant Pati" <a class="moz-txt-link-rfc2396E"
href="mailto:dpati@redhat.com"><dpati@redhat.com></a>
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.
</pre>
</blockquote>
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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"/
</pre>
</blockquote>
<pre wrap="">
What are the keys that been sent from the engine (i.e. the message before
translation)?</pre>
</blockquote>
We set message code as NULL and error message is set as is whatever
is received from VDSM. Message contains dots (".") as part of it.<br>
Code snippet is shown below -<br>
<pre wrap=""><font
color="#3333ff"><i>getReturnValue().getExecuteFailedMessages().add(error);
getReturnValue().getFault().setMessage(error);
getReturnValue().getFault().setError(<font
color="#ff0000">null</font>);</i></font></pre>
<br>
<blockquote
cite="mid:1514562916.26958300.1383753561998.JavaMail.root@redhat.com"
type="cite">
<blockquote type="cite">
<pre wrap="">
If you see the highlighted portion not only the dots in IP address but
also the full stop is changed to "_".
</pre>
<blockquote type="cite">
<pre wrap="">(and maybe try the same message using AppErrors
instead)
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">
[1] ErrorTranslator -> translateErrorTextSingle()
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------040302010801050202030308--