On Wed, Aug 05, 2015 at 09:12:14PM -0700, Tim Gustafson wrote: > I'm trying to configure an e-mail session in my Tomcat configuration like > this: > > <Resource name="mail/session" > auth="Container" > type="javax.mail.Session" > mail.transport.protocol="smtp" > mail.smtp.host="192.168.0.2" > mail.debug="true" />
That means Tomcat will have to have access to mail.jar, typically by placing a copy in Tomcat's /lib. Otherwise it can't load javax.mail.*. > From my web application, I'm instantiating a Session object like this: > > Context initialContext = new InitialContext(); > session = (Session) initialContext.lookup("java:comp/env/mail/session"); > > When I go to send e-mail from my web applet, I'm getting: > > java.lang.ClassNotFoundException: javax.mail.Authenticator Probably because the Resource could not be created. See above. > I find that error a little odd, as I'm not doing SMTP AUTH anywhere, > but I'll let that go for now. Based on documentation I found while > Googling that error message, I copied the mail.jar file from my > Netbeans library into Tomcat's lib folder, and now I get: > > java.lang.ClassCastException: javax.mail.Session cannot be cast to > javax.mail.Session As another noted, this happens when you have two copies of mail.jar available to the classloader tree, even when they are exact copies of each other. Don't include a copy in your application if it is to be provided by the container (which is required, if you want to use it this way). > Removing Java Mail from my Netbeans project does not appear to be an > option as it will refuse to compile the project without it. I use NetBeans with Maven, and in that context I would declare the mail dependency to be <scope>provided</scope>. I don't know how to do that in a native NetBeans project, but what you'd need to do is to tell NetBeans that javax.mail is required to compile but must not be included in the output WAR. Or you can just manually remove mail.jar from the built application before deployment. I have to do that with a community project that I haven't yet had time to fully adapt to <Resource> injection. Doing it this way might be a good quick proof-of-concept for a nicer solution. In summary: place mail.jar in Tomcat's /lib and NOT in your deployed application. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu
signature.asc
Description: Digital signature