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

需要的类：
 1 Properties
  javamail需要properties来创建一个session对象。它将寻找字符串"mail.smtp.host"。属性值就是发送邮件的主机，如：
  Properties props = new Properties();
  props.put("mail.smtp.host","smtp.sohu.com");

2 Session
这个Session类代表javamail中的一个邮件session，每一个基于javamail的应用程序至少要有一个session，但是可以有多个session，session对象需要知道用来处理邮件的smtp邮件服务器。例如：
      Session sendMailSession;
      sendMailSession = Session.getInstance(props, null);

3 Transport
javamail 用两个类来实现两个功能：Transport  和 Store。transport用来发信，store用来收信。
用javamail的session的getTransport()方法来初始化Transport 。传过去的字符串申明了对象所要用的协议。如smtp，如：
    Transport  transport ;
    transprot = sendMessageSession.getTransport("smtp");
javamail并不是支持每一个协议。目前支持imap  smtp   pop3

4 Message
Message 对象存储我们实际发送的电子邮件信息。Message对象被作为一个MimeMessage对象来创建并且需要知道应当选择哪一个JavaMail Session
    Message newMessage = new MimeMessage(sendMailSession);


创建并发送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.