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
