[Engine-devel] IMP: Regarding an issue while translating the error messages for gluster using ErrorTranslator class
This is a multi-part message in MIME format. --------------020507040501040703080208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------020507040501040703080208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi,<br> <br> 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.<br> We also populate the actual error from the Gluster as error message in the fault object.<br> <br> <font color="#000099"><i>getReturnValue().getExecuteFailedMessages().add(error);</i><i><br> </i><i>getReturnValue().getFault().setMessage(error);</i><i><br> </i><i>getReturnValue().getFault().setError(null);</i></font><br> <br> Because of above settings and the below code snippet in <i>Frontend.java</i> class the error message as is gets displayed on the error dialog -<br> <font color="#000099"><i><br> </i><i>public String translateVdcFault(final VdcFault fault) {</i><i><br> </i><i> return getVdsmErrorsTranslator().TranslateErrorTextSingle(fault.getError() == null</i><i><br> </i><i> ? fault.getMessage() : fault.getError().toString());</i><i><br> </i><i>}</i><i><br> </i></font><br> Well and good till now !!<br> <br> But while translation of the error messages, all the occurrences of "." get replaced with "_".<br> 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.<br> <br> Request your suggestion for handling such a case.<br> <br> <b>PS: </b>One thing I can think of is, introducing a flag called <i>isExternalError</i> in <i>VdcFault</i> class to identify if the source of the fault is external. From Gluster we would set the flag as <i>true</i>, and while replacement of "." with "_", if the flag is set it will not do the replacements.<br> <br> Regards,<br> Shubhendu <br> </body> </html> --------------020507040501040703080208--
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. 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
----- Original Message ----- From: "Alexander Wels" <awels@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
but if the message is not a key, and would be displayed as-is, on "." to "_" replacement should take place.
on -> no*
----- Original Message ----- From: "Einav Cohen" <ecohen@redhat.com> Sent: Wednesday, November 6, 2013 9:10:09 AM
----- Original Message ----- From: "Alexander Wels" <awels@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> Sent: Wednesday, November 6, 2013 9:10:09 AM
----- Original Message ----- From: "Alexander Wels" <awels@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/06/2013 07:40 PM, Einav Cohen wrote:
----- Original Message ----- From: "Alexander Wels" <awels@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). There is an upstream patch according to Einav's suggestion above. http://gerrit.ovirt.org/#/c/21083/
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message ----- From: "Shubhendu Tripathi" <shtripat@redhat.com> Sent: Saturday, November 9, 2013 4:07:44 AM
On 11/06/2013 07:40 PM, Einav Cohen wrote:
----- Original Message ----- From: "Alexander Wels" <awels@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). There is an upstream patch according to Einav's suggestion above. http://gerrit.ovirt.org/#/c/21083/
Many thanks, Shubhendu. @Derez - any chance that you can take a look (as you probably understand best this particular code/logic)?
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 11/11/2013 08:48 PM, Einav Cohen wrote:
----- Original Message ----- From: "Shubhendu Tripathi" <shtripat@redhat.com> Sent: Saturday, November 9, 2013 4:07:44 AM
----- Original Message ----- From: "Alexander Wels" <awels@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). There is an upstream patch according to Einav's suggestion above. http://gerrit.ovirt.org/#/c/21083/ Many thanks, Shubhendu. @Derez - any chance that you can take a look (as you probably understand best
On 11/06/2013 07:40 PM, Einav Cohen wrote: this particular code/logic)? Daniel, any comments on the patch ?
http://gerrit.ovirt.org/#/c/21083/
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- 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
This is a multi-part message in MIME format. --------------080803010008020502090907 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/06/2013 07:43 PM, Daniel Erez wrote:
----- 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?
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"/ 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
--------------080803010008020502090907 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 07:43 PM, Daniel Erez wrote:<br> </div> <blockquote cite="mid:1626430710.26900628.1383747210835.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: <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> One example of the error message which is shown on the dialog after translation is as below -<br> <br> <i>"Error while executin action Create Gluster Volume: Volume create failed error: Staging failed on </i><i><font color="#ff0000"><b>10_70_43_122_</b></font></i><i> Error: /export/vol1-a is already part of a volume"</i><br> <br> If you see the highlighted portion not only the dots in IP address but also the full stop is changed to "_".<br> <blockquote cite="mid:1626430710.26900628.1383747210835.JavaMail.root@redhat.com" type="cite"> <pre wrap=""> (and maybe try the same message using AppErrors instead)</pre> </blockquote> 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.<br> <blockquote cite="mid:1626430710.26900628.1383747210835.JavaMail.root@redhat.com" 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> <br> </body> </html> --------------080803010008020502090907--
----- Original Message -----
From: "Shubhendu Tripathi" <shtripat@redhat.com> To: "Daniel Erez" <derez@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Dusmant Pati" <dpati@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@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?
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
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@redhat.com> To: "Daniel Erez" <derez@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Dusmant Pati" <dpati@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
----- 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? One example of the error message which is shown on the dialog after
On 11/06/2013 07:43 PM, Daniel Erez wrote: 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--
participants (4)
-
Alexander Wels -
Daniel Erez -
Einav Cohen -
Shubhendu Tripathi