前提：需要有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.

java classloader overview
  Classloader are a fundamental module of the Java language,A classloader is a part of the  Java virtual machine that loads the class into memory.a classloader is responsible for finding and loading class files at the run time.Every programmer needs to understand classloaders and their behavior.This section provides an overview of Java classloaders.
  Java Classloader Hierachy
  The bootstrap classloader is the root of the Java classloader hierarchy.
The Java virtual machine (JVM) creates the bootstrap classloader, which loads the Java development kit (JDK) internal classes and java.* packages included in the JVM. (For example, the bootstrap classloader loads java.lang.String.)

The extensions classloader is a child of the bootstrap classloader. The extensions classloader loads any JAR files placed in the extensions directory of the JDK. This is a convenient means to extending the JDK without adding entries to the classpath. However, anything in the extensions directory must be self-contained and can only refer to classes in the extensions directory or JDK classes.

The system classpath classloader extends the JDK extensions classloader. The system classpath classloader loads the classes from the classpath of the JVM. Application-specific classloaders (including WebLogic Server classloaders) are children of the system classpath classloader.
What BEA refers to as a "system classpath classloader" is often referred to as the "application classloader" in contexts outside of WebLogic Server. When discussing classloaders in WebLogic Server, BEA uses the term "system" to differentiate from classloaders related to J2EE applications (which BEA refers to as "application classloaders").

Classloaders use a delegation model when loading a class. The classloader implementation first checks its cache to see if the requested class has already been loaded. This class verification improves performance in that its cached memory copy is used instead of repeated loading of a class from disk. If the class is not found in its cache, the current classloader asks its parent for the class. Only if the parent cannot load the class does the classloader attempt to load the class. If a class exists in both the parent and child classloaders, the parent version is loaded. This delegation model is followed to avoid multiple copies of the same form being loaded. Multiple copies of the same class can lead to a ClassCastException.

java classloader overview
  Classloader are a fundamental module of the Java language,A classloader is a part of the  Java virtual machine that loads the class into memory.a classloader is responsible for finding and loading class files at the run time.Every programmer needs to understand classloaders and their behavior.This section provides an overview of Java classloaders.
  Java Classloader Hierachy
  The bootstrap classloader is the root of the Java classloader hierarchy.
The Java virtual machine (JVM) creates the bootstrap classloader, which loads the Java development kit (JDK) internal classes and java.* packages included in the JVM. (For example, the bootstrap classloader loads java.lang.String.)

The extensions classloader is a child of the bootstrap classloader. The extensions classloader loads any JAR files placed in the extensions directory of the JDK. This is a convenient means to extending the JDK without adding entries to the classpath. However, anything in the extensions directory must be self-contained and can only refer to classes in the extensions directory or JDK classes.

The system classpath classloader extends the JDK extensions classloader. The system classpath classloader loads the classes from the classpath of the JVM. Application-specific classloaders (including WebLogic Server classloaders) are children of the system classpath classloader.
What BEA refers to as a "system classpath classloader" is often referred to as the "application classloader" in contexts outside of WebLogic Server. When discussing classloaders in WebLogic Server, BEA uses the term "system" to differentiate from classloaders related to J2EE applications (which BEA refers to as "application classloaders").

Classloaders use a delegation model when loading a class. The classloader implementation first checks its cache to see if the requested class has already been loaded. This class verification improves performance in that its cached memory copy is used instead of repeated loading of a class from disk. If the class is not found in its cache, the current classloader asks its parent for the class. Only if the parent cannot load the class does the classloader attempt to load the class. If a class exists in both the parent and child classloaders, the parent version is loaded. This delegation model is followed to avoid multiple copies of the same form being loaded. Multiple copies of the same class can lead to a ClassCastException.

Organizing Shared Classes in a Split Development Directory

  The weblogic split develepment directory helps you store shared utility classes and libraries that are required by modules in your Enterprise Application. 
 

Shared Utility Classes

Enterprise Applications frequantly  use java utility classes that are shared among application modules.Java utility classes differ from third-party JARs in that the source files are part of the application and must be compiled. Java utility classes are typically libraries used by application modules such as EJBs or Web applications.

  Place the source for Java utility classes in a named subdirectory of the top-level Enterprise Application directory. Beneath the named subdirectory, use standard package subdirectory conventions.
  the wlcompile Ant task invokes the javac compiler and compiles Java classes into the APP-INF/classes/ directory under the build directory. This ensures that the classes are available to other modules in the deployed application.

Third-party JARs are generally not compiled, but may be versioned using the source control system for your application code. For example, XML parsers, logging implementations, and Web Application framework JAR files are commonly used in applications and maintained along with editable source code.

The classes and libraries stored under APP-INF/classes and APP-INF/lib are available to all modules in the Enterprise Application. The application classloader always attempts to resolve class requests by first looking in APP-INF/classes, then APP-INF/lib.
(在APP-INF/classes和APP-INF/lib下的類和jar文件能被所有的模塊來調用。應用程序的類加載器經常在解決類調用請求的時候嘗試先調用/classes下，然后才是/lib下)。

Organizing Libraries and Classes Shared by Multiple EARs

For single ear projects, the split develepment directory conventions suggests keeping third-party jar files in the APP-INF/lib directory of EAR source directory,However a multiple-ear project would require you to maintain a copy of the same third-party jar files in the APP-INF/lib directory of each EAR source directory.This introduces multiple copies of the source JAR files, increases the possibility of some JAR files being at different versions, and requires additional space in your source control system.

To address these problems, consider editing your build script to copy third-party JAR files into the APP-INF/lib directory of the build directory for each EAR that requires the libraries. This allows you to maintain a single copy and version of the JAR files in your source control system, yet it enables each EAR in your project to use the JAR files.

這幾天終于忙完了，可以好好休息會了，剛剛參與做好了自己的模塊，呵呵，今天PM要我看weblogic，因為剛把項目打成ear發布上去，查了下，發現自己寫的模塊沒有任何問題。呵呵