Skip to main content

Mail from log handler

Please note these forums are being decommissioned and use the new and improved forums at
3 replies [Last post]
Joined: 2006-02-14

We need to send mail from a log handler in GlassFish.

We've tried to use smtphandler-0.6 and -0.7 with limited success. We install the jarfile to domain/lib/ext. We configure smtphandler's properties in domain/config/

We've tried two ways of satisfying smtphandler's reliance on mail imports: 1) We have edited its manifest classpath to point to ../../../../modules/javax.mail.jar, and 2) we've put javax.mail.jar in domain/lib/ext alongside the smtphandler jar.

With either of these arrangements the behavior is the same: the handler loads ok and sends mail for errors and warnings that occur during domain startup. However, when we then deploy our application and cause it to emit some error logs, mail stops working. The handler still runs, but it fails with an error finding the constructor for SMTPTransport:

java.lang.NoSuchMethodException: com.sun.mail.smtp.SMTPTransport.[init](javax.mail.Session, javax.mail.URLName)

1) Are we deploying the handler to the correct location (domain/lib/ext) ?
2) Why does it send mail during an (empty, no apps) domain startup, but fail for logs emitted by our application?

P.S. In the exception cited above, pretend that "init" appears in angle brackets.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2013-09-04

Since we are collaborating on this issue, I thought I would provide more information on how to reproduce.

I am now getting the NoSuchMethodError consistently, even when the domain is first started without any applications being loaded.

To make it easier to reproduce, I started with a clean installation of GF (build 5) running on Linux. The only JAR files I have in the domains/aces3/lib directory are Oracle and MySQL JDBC jar files.

Note: My domain is named aces3 instead of domain1.

The domains/aces3/config/ was updated with the following entries:


smtphandler.SMTPHandler.smtpHost=MY SMTP HOST TO EMAIL ADDRESS
smtphandler.SMTPHandler.from=MY FROM ADDRESS
smtphandler.SMTPHandler.subject=[SMTPHandler] Application message

Finally, I added the following JAR files to domains/aces3/lib/ext

mail.jar (JavaMail 1.4.4)

So I can see the classloading output, I added the JVM option -verbose:class to the domain.xml, and start the domain as follows:

asadmin start-domain -v 2>&1 | tee /tmp/domain.log

This gives me combined logging output and classloader output in a single file--this file is attached.

I know there is already a copy of the JavaMail 1.4.4 classes in the glassfish/modules directory (javax.mail.jar), so I repeated the test as follows and get basically the same result.

- Removed mail.jar from domains/aces3/lib/ext
- Updated MANIFEST.MF file in the smtphandler-0.6.jar to contain Class-Path: ../../../../modules/javax.mail.jar

This causes the JavaMail classes to be loaded from the same file as used by Glassfish to eliminate multiple versions of these classes, but the end result is the same.

Hopefully this helps someone that knows more about the GF classloaders to reproduce this issue with minumal setup.

Thanks in advance for your assistance.

Joined: 2013-09-04

I repeated the same steps above on a clean install of GF 4 with the same exact result. I even swapped out JavaMail 1.4.4 with 1.5, with the same result.

Note: Occassionally I will receive an email caused by the SEVERE error for the expired certificate, but only if the error is logged early in the server startup. But then when it attempts to send the same email later when the certificate error occurs again, the NoSuchMethodException (and related other errors) then occur.

This happens on both versions of GF.

Joined: 2005-06-14

JavaMail Bug 6668 -skip unusable Store and Transport classes fixed in 1.5.3 corrects the issue with locating the transport. See for details.