Hi Jorge,
thank you for your clarification and for looking into the patch.
Frankly, I tried a lot to guess the initial intention of the code, but without significant success. My current guess is that the code may contain a programming error, so the current behavior is "provide special guidelines when SMTP server is not set up, and ignore any other problems", while the initial intention might be "provide special guidelines when SMTP server is not set up, and let the other problems be handled in a standard way".
IMHO there are no "harmless" messaging exceptions that might be silently ignored. I'm sure any of them indicates a significant problem either with the portal infrastructure or with the visitor. I believe all of them deserve being reported and logged at ERROR level. Maybe further experience will show that some of them (visitor-related) may deserve some other handling too...
I can't say now where I've borrowed the exception chain formatting pattern. But I have a strong feeling that somewhere in Liferay
- maybe not the code itself but the idea of the formatted result. It's sure that the whole exception chain is to be unwound in order to provide meaningful message. And sure, standard printStackTrace() may do the job, but the printout looks frigtening I believe not only to me, as I have seen many similar "refined" error messages without stacktrace while setting my Liferay up.
Having revised the whole thing again, I can agree (if somebody insists) that I have removed an important feature of special guidance for the portal admin in case the mail server is not set up at all. If yes, I can add this special case back into the code...
And the last - maybe running ahead a little. IMHO any problem with e-mailing deserves handling in a way that would generate an automatic incident ticket for the help desk. Unfortunately I still did not manage to realize if there is a standard help desk engine in Liferay, so any comments of yours are more than welcome...
Regards,
Sergey
thank you for your clarification and for looking into the patch.
Frankly, I tried a lot to guess the initial intention of the code, but without significant success. My current guess is that the code may contain a programming error, so the current behavior is "provide special guidelines when SMTP server is not set up, and ignore any other problems", while the initial intention might be "provide special guidelines when SMTP server is not set up, and let the other problems be handled in a standard way".
IMHO there are no "harmless" messaging exceptions that might be silently ignored. I'm sure any of them indicates a significant problem either with the portal infrastructure or with the visitor. I believe all of them deserve being reported and logged at ERROR level. Maybe further experience will show that some of them (visitor-related) may deserve some other handling too...
I can't say now where I've borrowed the exception chain formatting pattern. But I have a strong feeling that somewhere in Liferay
- maybe not the code itself but the idea of the formatted result. It's sure that the whole exception chain is to be unwound in order to provide meaningful message. And sure, standard printStackTrace() may do the job, but the printout looks frigtening I believe not only to me, as I have seen many similar "refined" error messages without stacktrace while setting my Liferay up.Having revised the whole thing again, I can agree (if somebody insists) that I have removed an important feature of special guidance for the portal admin in case the mail server is not set up at all. If yes, I can add this special case back into the code...
And the last - maybe running ahead a little. IMHO any problem with e-mailing deserves handling in a way that would generate an automatic incident ticket for the help desk. Unfortunately I still did not manage to realize if there is a standard help desk engine in Liferay, so any comments of yours are more than welcome...
Regards,
Sergey
Community
Company
Feedback