JavaMail is not that hard to use, though it may seem like a lot when you
first approach it. If you want a "simple" API, just wrap it up and I'm sure
it's not too hard to make a single API call that would send an email just
fine.
You will need to include mail.jar (JavaMail) and activation.jar (JAF) -- but
these are freely downloaded from the java.sun.com site.
Here's a snippets of the relevant code that works for me, and wrapping so
that you can do something like:
test.SimpleEmail emailMsg = new test.SimpleEmailMsg();
emailMsg.addTo(emailAddr);
emailMsg.setMessage(msg);
emailMsg.send();
should not really be hard to do.
import javax.mail.Message;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;
in my doPost():
InternetAddress[] toAddresses = new InternetAddress[1];
try
{
toAddresses[0] = new InternetAddress(emailTo); // emailTo is a
String like '[EMAIL PROTECTED]'
}
catch( javax.mail.internet.AddressException e )
{
throw new ServletException("Invalid email TO address: " +
emailTo + " - " + e.getMessage() );
}
StringBuffer message = new StringBuffer(1000);
message.append("my message").append("\n");
message.append(...);
sendEmail( toAddresses, emailSubject, message.toString());
in my servlet init:
public void init( ServletConfig config )
throws ServletException
{
try
{
fromAddress = new InternetAddress("[EMAIL PROTECTED]");
}
catch( javax.mail.internet.AddressException e )
{
throw new ServletException("Invalid from email address: " +
e.getMessage() );
}
String smtpServer = config.getInitParameter(PARAM_SMTP_SERVER);
if ( smtpServer == null )
throw new ServletException("Missing servlet parameter: " +
PARAM_SMTP_SERVER);
Properties prop = new Properties();
prop.put("mail.smtp.host",smtpServer);
session = Session.getDefaultInstance(prop,null);
super.init(config);
}
boolean sendEmail( InternetAddress[] toAddresses,
String subject,
String message
)
throws ServletException, java.io.IOException
{
try
{
Message msg = new MimeMessage(session);
msg.setFrom(fromAddress);
msg.setRecipients(Message.RecipientType.TO, toAddresses);
msg.setSubject(subject);
msg.setContent(message, "text/plain" );
Transport.send( msg );
return true;
}
catch( javax.mail.MessagingException e )
{
throw new java.io.IOException("Failed to send Email: " +
e.getMessage());
}
}
private Session session = null;
private InternetAddress fromAddress = null;
-----Original Message-----
From: Chris Pratt <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, March 17, 1999 9:51 AM
Subject: Re: Servlet using sun.net.smtp.SmtpClient?
>These are the internal classes that make up the runtime of the system, it's
>like saying that since all operating systems have internal device
>manipulation calls, why not call them directly instead of using the
accepted
>C or C++ interfaces to those calls. These aren't "hidden treasure" that
are
>there for the taking, there are real risks involved in using undocumented
>(actually these are documented as "DON'T USE") code. It's just bad
>practice, especially when there are numerous alternatives.
> (*Chris*)
>
>----- Original Message -----
>From: Patrick McGovern <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Wednesday, March 17, 1999 8:54 AM
>Subject: Re: Servlet using sun.net.smtp.SmtpClient?
>
>
>>One might ask...then why does sun include these api's in the JDK releases?
>I think enough people are using this particular set of classes that sun
>would be foolish to make any changes that would break existing code. I,
>personally, cant include my code in JDK releases (although it would make my
>life easier) so sun shouldnt either.
>>
>>Patrick
>>
>>>>> "Craig R. McClanahan" <[EMAIL PROTECTED]> 03/17 11:15 AM >>>
>>Jason Hunter wrote:
>>
>>> Danny Rubis wrote:
>>> >
>>> > But, but... Jason Hunter uses this in one of his examples
>>> > in his new book.
>>> >
>>> > Jason can you please comment on this.
>>> >
>>> > Thank you Chris.
>>>
>>> As it says in the book: "For the purposes of this example, we'll
>>> demonstrate a servlet that uses the sun.net.smtp.SmtpClient class.
>>> It's conveniently provided with Sun's JDK and most JVMs descended
>>> from it, but we should warn you that it's unsupported and subject
>>> to change (though it hasn't changed since JDK 1.0)."
>>>
>>> I personally find SmtpClient much easier to use than JavaMail. I've
>>> used both, and even teach a servlets class that demonstrates the use of
>>> both. In the lab I let students choose which they want to use and I
>>> haven't seen anyone choose JavaMail yet! :-)
>>>
>>> JavaMail requires the installation of two .jar files (and therefore
>>> modifications to the server classpath), and has an API clearly designed
>>> for robust mail handling services driven by a front end GUI, not
>>> programatically sending a simple text email to one person. It's the
>>> politically correct way to go, however. That's why I gave the warning,
>>> and made sure to provide the URL for JavaMail in the book.
>>>
>>> Course, I personally would rather use a third party SmtpClient
>>> equivalent before JavaMail in my servlets. That way you can be
>>> politically correct *and* enjoy a simple API. I'll use JavaMail
>>> when I'm writing a GUI mailer. That's the use for which it was
>>> designed.
>>>
>>> -jh-
>>>
>>> --
>>> Jason Hunter
>>> [EMAIL PROTECTED]
>>> Book: http://www.servlets.com/book
>>> Article: http://www.javaworld.com/jw-12-1998/jw-12-servletapi.html
>>>
>>
>>This is going to sound a little harsh, but IMHO it is irresponsible for a
>>respected author to encourage Java developers to learn and use bad habits.
>I
>>already have to undo enough bad habits in Java developers that I utilize
>... I
>>don't need more of them.
>>
>>Throughout the JDK documentation, you will find warnings against the use
of
>>the sun.* series of APIs, because they only represent the Sun
>implementation
>>of particular features. They are undocumented and subject to change, so
>that
>>anyone who relies on them is risking the correct behavior of their code
>when
>>they do something as innocent as upgrading to the next rev. The fact that
>>this particular class has not changed yet is no excuse!
>>
>>If you don't want to use JavaMail, that's fine ... it is overkill for
>sending
>>a simple EMAIL message from a servlet. But there are lots of open source
>>examples of simple SMTP senders that you could have included in your
>utility
>>classes (and these would work even if you are running on a JVM that is
>*not*
>>provided by Sun, and does not include this class :-).
>>
>>Relying on sun.net.smtp.SmtpClient in a Java program is a poor programming
>>practice -- just as poor as relying on "undocumented" Windows APIs when
>>programming in the Microsoft arena.
>>
>>Craig McClanahan
>>
>>
>>>
>>>
>___________________________________________________________________________
>>> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
>body
>>> of the message "signoff SERVLET-INTEREST".
>>>
>>> Archives: http://archives.java.sun.com/archives/servlet-interest.html
>>> Resources: http://java.sun.com/products/servlet/external-resources.html
>>> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>>
>>__________________________________________________________________________
_
>>To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
>>of the message "signoff SERVLET-INTEREST".
>>
>>Archives: http://archives.java.sun.com/archives/servlet-interest.html
>>Resources: http://java.sun.com/products/servlet/external-resources.html
>>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>>
>>__________________________________________________________________________
_
>>To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
>>of the message "signoff SERVLET-INTEREST".
>>
>>Archives: http://archives.java.sun.com/archives/servlet-interest.html
>>Resources: http://java.sun.com/products/servlet/external-resources.html
>>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>>
>
>___________________________________________________________________________
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff SERVLET-INTEREST".
>
>Archives: http://archives.java.sun.com/archives/servlet-interest.html
>Resources: http://java.sun.com/products/servlet/external-resources.html
>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
