WildFly support for MailHandler #110
Description
The MailHandler only supports setting mail properties through a properties object. Per the WildFly docs: All properties must be accessible via a setter method.
See also:
- How do I send error logs through e-mail on Wildfly? for more information.
- WildFly logging
- jboss-logmanager
- Custom Filters in WildFly
- https://issues.redhat.com/projects/LOGMGR/issues/LOGMGR-86?filter=allopenissues
- https://issues.redhat.com/browse/WFLY-43?jql=project%20%3D%20WFLY%20AND%20component%20%3D%20Logging
In order to support WildFly, one option would be to add a new public method that takes a string that is the path to a resource which then loads the properties file. Just need to verify that WildFly allows this. This would be the preferred option as it would be useful for loading the logging.properties as mail properties when using the standard LogManager.
Another option would be to create a new method which takes a string that can be parsed as the contents of properties file. Splitting string key/value pairs where semicolon is used to delimit the entries would be one option assuming that is not used in any other property values. Need to look at:
- Adding a new method setMailProperties(String). This would clear and set the new properties. Name might have to change if overloads don't work correctly..
- Adding a new method setMailEntries(String). This would simply add new properties without removing existing ones.
- Consider adding getter methods for these.
- Determine if the setAuthenticator(char[]) can be used in WildFly.
- Might need to adjust the behavior of setAuthenticator to perform a classname lookup.
Final option to consider would be adding property setters for Jakarta Mail API properties and Angus SMTP provider properties.
Things to consider before implementing this change are:
- This option has a lot of code smell.
- This will only add support for Angus SMTP even though other providers could be loaded instead.
- The number of public methods could grow out of hand.
- There would now be multiple ways to set properties.
- Every time a new property is defined in the API or SMTP provider we would have to consider if that property needs to be converted into a setter method.
- Order of when these properties are set will matter to ensure the correct protocol (smtp vs. smtps) is used. It also matters that the verify type is set last.
List of properties from API (draft):
- mail.debug
- mail.from
- mail.protocol.host
- mail.transport.protocol
- mail.user
- mail.protocol.port
- mail.mime.allowutf8
List of properties from Angus (draft):
- mail.smtp.connectiontimeout
- mail.smtp.timeout
- mail.smtp.auth
- mail.smtp.auth.mechanisms
- mail.smtp.ssl.enable
- mail.smtp.starttls.enable
List of properties from MailHandler (draft)
- authenticator
- mail.to
- mail.sender
- mail.bcc
- mail.cc
- mail.reply.to
- mail.sender
- verify