Here’s some more detailed information on how I tested the new MailPro version:
I currently have two Servoy test setups. One is a copy of our production system (including all other plugins like VelocityReports, etc.), and the other one is a completely clean Servoy installation. I updated both to the latest stable Servoy release (2025.12.0) a few hours ago.
I started with the copied production setup. I removed all old MailPro JARs and replaced them with the new ones. Then I exported a WAR file with all plugins included (including the default mail plugin) and deployed it to Tomcat on our test server. Everything looked fine until I tried to check the SMTP connection. Unfortunately, I don’t remember the exact exception anymore because I already cleared the log for this test, sorry about that. What I do remember is that it said something like “cannot initialize NULL”, and it happened at the exact same line of code as last year:
var smtp = plugins.MailPro.SMTPAccount()
At that point, the Electron Client went into an “Internal Server Error” state.
After that, I tested the same steps with the clean Servoy installation, as you had recommended earlier. The process was identical up until the SMTP connection test. This time, I got a different exception at the same line of code:
org.mozilla.javascript.WrappedException: Wrapped java.lang.ClassCastException:
class org.eclipse.angus.mail.smtp.SMTPTransport cannot be cast to class com.sun.mail.smtp.SMTPTransport
(org.eclipse.angus.mail.smtp.SMTPTransport and com.sun.mail.smtp.SMTPTransport are in unnamed module
of loader org.apache.catalina.loader.ParallelWebappClassLoader @71e693fa)
(HVO2go/forms/settings_tpuser_benutzerverwaltung_user_email_setup/onCheckConnectionClicked#82)
This time there was no Internal Server Error in the client. After looking at the exception, it became clear that Angus was interfering with Jakarta, so I checked the “lib” folder of the deployed webapp for deployed JAR files. There I found angus-activation.jar and angus-mail.jar, which should come from Servoy’s default mail plugin. I removed those JARs and tested again, and everything worked.
To be sure the default mail plugin was the cause, I exported another WAR file, this time without mail.jar. With that setup, everything worked as well and no angus JAR files were found in the “lib” folder of my webapp. I also tested again with our production setup (which previously had the Internal Server Error issue) and excluded mail.jar from the export, this time everything worked fine.
So in conclusion: I can’t say for sure how MailPro might rely on Angus internally, but removing Angus (either manually from the “lib”folder or by excluding mail.jar during WAR export) fixed the issue for us. While trying to manually update the plugin a few months ago, I did some research and, if I remember correctly, read that you have to choose between Angus and Jakarta, and that mixing both can cause issues. Since I am completely unexperenced in the whole java mail topic, I can’t really tell if this is true or not.
The only remaining question for me is: if MailPro really depends on Angus, why does it only ship Jakarta JARs for mail and activation? If am I seeing things wrong here?
If you need more details or have any other questions, just let me know. I’ll try to provide as much information as I can
