Eclipse Web Service Setting

參考以下:

http://www.eclipse.org/webtools/community/tutorials/BottomUpAxis2WebService/bu_tutorial.html

<

AxisAdminServlet Class not found exception occurs as deploying the web service.

http://forums.sun.com/thread.jspa?threadID=5308003

問題簡述:
Eclipse Java EE IDE for Web Developers. (Build id: 20090621-0832)
建立 web service後, 啟動 Tomcat 5.5 顯示錯誤訊息
java.lang.NoClassDefFoundError: org/apache/http/HttpResponseFactory

解決方法:
從 Apache Axis2 官網中下載 axis2-1.5-bin.zip, 從zip檔案的lib目錄中複製httpcore-4.0.jar 至
該專案的 WEB-INF/lib 目錄中

Java Diagrams

Example 1:

The School System provides the following functions:
· Create course by teacher
· Enroll course for student
· Cancel course by teacher
· Register for user
· Modify the personal information
· View the Course information (number of students enrolled and teacher information of the course)








































Example 2:
Online test data flow diagram～

Servlet Life Cycle and TOMCAT (multi-threaded server)

http://www.iam.ubc.ca/guides/javatut99/servlets/lifecycle/index.html

Each servlet has the same life cycle:

• A server loads and initializes the servlet
  
• The servlet handles zero or more client requests
  
• The server removes the servlet
  (some servers do this step only when they shut down)

Initializing a Servlet:

When a server loads a servlet, the server runs the servlet's init method. Initialization completes before client requests are handled and before the servlet is destroyed.

Even though most servlets are run in multi-threaded servers, servlets have no concurrency issues during servlet initialization. The server calls the init method once, when the server loads the servlet, and will not call the init method again unless the server is reloading the servlet. The server can not reload a servlet until after the server has destroyed the servlet by calling the destroy method.

Interacting with Clients:

After initialization, the servlet is able to handle client requests.

Destroying a Servlet:

Servlets run until the server are destroys them, for example, at the request of a system administrator. When a server destroys a servlet, the server runs the servlet's destroy method. The method is run once; the server will not run that servlet again until after the server reloads and reinitializes the servlet.

=================

Tomcat is a multi-threaded servlet container

this means that each request needs to be executed by some thread. Prior to Tomcat 3.2, the default was to create a new thread to serve each request that arrives. This behavior is problematic for loaded sites because:

• Starting and stopping a thread for every request puts a needless burden on the operating system and the JVM.
• It is hard to limit the resource consumption. If 300 requests arrive concurrently Tomcat will open 300 threads to serve them and allocate all the resources needed to serve all the 300 requests at the same time. This causes Tomcat to allocate much more resources (CPU, Memory, Descriptors...) than it should and it can lead to low performance and even crashes if resources are exhausted.

The solution for these problems is to use a thread pool, which is the default for Tomcat 3.2. Servlet containers that are using a thread pool relieve themselves from directly managing their threads. Instead of allocating new threads; whenever they need a thread they ask for it from the pool, and when they are done, the thread is returned to the pool. The thread pool can now be used to implement sophisticated thread management techniques, such as:

1. Keeping threads "open" and reusing them over and over again. This saves the trouble associated with creating and destroying threads continuously.
   • Usually the administrator can instruct the pool not to keep too many idle threads, freeing them if needed.
2. Setting an upper bound on the number of threads used concurrently. This prevents the resources allocation problem associated with unlimited thread allocation.
   • If the container maxed out to the threads upper limit, and a new request arrives, the new request will have to wait for some other (previous) request to finish and free the thread used to service it.

You can refine the techniques described above in various ways, but these are only refinements. The main contribution of thread pools is thread-reuse and having a concurrency upper bound that limits resource usage.

Using a thread pool in Tomcat is a simple move; all you need to do is to use a PoolTcpConnector in your configuration. For example the following server.xml fragment defines ajpv12, pooled Connector: