前提：需要有javamail的類文件包，JAF（javabean activation framework）。

需要的類：
 1 Properties
  javamail需要properties來創(chuàng)建一個session對象。它將尋找字符串"mail.smtp.host"。屬性值就是發(fā)送郵件的主機(jī)，如：
  Properties props = new Properties();
  props.put("mail.smtp.host","smtp.sohu.com");

2 Session
這個Session類代表javamail中的一個郵件session，每一個基于javamail的應(yīng)用程序至少要有一個session，但是可以有多個session，session對象需要知道用來處理郵件的smtp郵件服務(wù)器。例如：
      Session sendMailSession;
      sendMailSession = Session.getInstance(props, null);

3 Transport
javamail 用兩個類來實(shí)現(xiàn)兩個功能：Transport  和 Store。transport用來發(fā)信，store用來收信。
用javamail的session的getTransport()方法來初始化Transport 。傳過去的字符串申明了對象所要用的協(xié)議。如smtp，如：
    Transport  transport ;
    transprot = sendMessageSession.getTransport("smtp");
javamail并不是支持每一個協(xié)議。目前支持imap  smtp   pop3

4 Message
Message 對象存儲我們實(shí)際發(fā)送的電子郵件信息。Message對象被作為一個MimeMessage對象來創(chuàng)建并且需要知道應(yīng)當(dāng)選擇哪一個JavaMail Session
    Message newMessage = new MimeMessage(sendMailSession);


創(chuàng)建并發(fā)送Message對象

message.setFrom(new InternetAddress(request.getParameter("from")));
message.setRecipient(Message.RecipientType.TO, new InternetAddress(request.getParameter("to")));
message.setSubject(request.getParameter("subject"));
message.setSentDate(new Date());
message.setText(request.getParameter("text"));

transport.send(message);
 

prefer-web-inf-classes Element
  The weblogic.xml Web application deployment descriptor contains a prefer-web-inf-classes element(a sub element of container-descriptor element ).By default this element is set to false,Setting this element to true subverts the classloader delegation model so that class definitions from the web application are loaded in preference to class definitions in high-leavel classloader.This allows web application to use its own version of a third-party class,which might also be part of weblogic server.
  When using this feature.you must be careful not to mix instances created from the web application's class definition with issuances created from the server application's class definition If such instance is mixed , a ClassCastException results.
  Changing classes in running program
  Weblogic Server allows you to deploy newer versions of application modules such as EJB modules while server is running.this process is known as hot-deploy or hot-redeploy and is closely related to classloading.
  java classloader do not have a standard mechanism to undeploy or unload a set of class ,nor can they load new version of classes .In order to make updates to classes in a running virtual machine.the classloader that loaded the changed classes  must be replaced with a new classloader.When a classloader is replaced ,all classes that were loaded from that classloader (or any classloaders  that are offspring of that classloader) must be reloaded.Any instance of these classes must be re-instantiated.
  In weblogic Server ,each application has a hierarchy of classloaders that are offspring of the system classloader.These hierarchies allows applications or parts of applications to be individually reloaded   without affecting the rest of the system.

Weblogic Server application classloader overview
Application Classloading
  Weblogic Server application classloading is centered on the concept of an application.An application is normally packaged in an Enterprise Archive file containing application classes .Everything within an EAR file is considered part of the same application.The following may be part of an EAR or can be loaded as standalone applications.
 1 EJB jar files
 2 WAR files
 3 A resource adapter RAR files
If you deploy an EJB and a web applciation seperately ,they are considered two applications.If they are deployed together within an EAR file.they are on one application.You deploy modules together in an EAR file for them to be considered part of the same application.
Every application receives its own classloader hierarchy; the parent of this hierarchy is system classpath classloader ,this isolates applications so that application A can not see the clasloaders or classes of application B, In classloader hierarchy,no sibling or friend concepts exist.
Application Classloader Hierarchy
  Weblogic Server automatically creates a hierarchy of classloaders when an application is deployed.The root classloader in this hierarchy loads any EJB jar files in the application.A child classloader is created for each Web application war file.
Because it is common for web application to call  EJBs,the weblogic server application classloader architecture allows jsp files and servlets to see the EJB interfaces in their parent classloader .This architecture   also allows web applications to be redeployed without redeploying the EJB tier .In practice it is common to change jsp files than to change the EJB tier.
  If your application includes servlets and jsp files that use EJBs
  1.Package the servlets and jsp files in a war file
  2.Package the Enterprise javaBeans in an EJB jar file
  3.Package the war and jar files in an Ear file
  4.Deploy the EAR file
Although you could deploy war file and jar file seperately.deploying them together in an ear file produces a classloader arrangement that allows the servlets and jsps to find EJB classes,If you deploy tha war and jar seperately ,Weblogic Server creates sibling classloaders for them This means that you might include the EJB home and remote interfaces in the war file.and weblogic server must use the RMI stub and skeleton classes for EJB calls.just as it does when EJB clients and implementation classes in different JVMs.
Note: The web application classloader contains all classes for the web application except for the jsp class.The jsp class obtains its own classloader which is a child of the web application classloader this allows jsp to be individully reloaded.

Custom Module Classloader Hierarchies
You can create custom classloader hierarchy for an application allowing for better control over class visibility and reloadability ,you achieve this by defining a classloader-structure element in the weblogic-application.xml deployment descriptor files.