Sunday, March 16, 2008

Java Bytecode

When javac is used to compile a Java program, bytecode(.class files) is generated which can be run on JVM.
Command javap can be used to display content of .class files in a meaningful way.
    javap ClassName        //print out field/method definition.
    javap -c ClassName    //print out all disassembled code.

A simple introduction:
http://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/

JVM specification:
http://java.sun.com/docs/books/jvms/

Java Reflection and bytecode ...

I found a series of very useful articles about Java. Here is the address:http://www.ibm.com/developerworks/java/library/j-dyn0429/.
In this series, the author introduces classloading, bytecode, reflection, Class-transformation on-the-fly...

Javassist --- manipulation of bytecode
Introduction from official site:
"Javassist (Java programming assistant) is a load-time reflective system for Java. It is a class library for editing bytecodes in Java; it enables Java programs to define a new class at runtime and to modify a class file before the JVM loads it. Unlike other similar systems, Javassist provides source-level abstraction; programmers can modify a class file without detailed knowledge of the Java bytecode. They do not have to even write an inserted bytecode sequence; Javassist instead can compile a fragment of source text on line (for example, just a single statement). This ease of use is a unique feature of Javassit against other tools."
http://labs.jboss.com/javassist/
http://www.csg.is.titech.ac.jp/~chiba/javassist/

Configuration Of Tomcat

(Part of this post is cited from Tomcat Offcial site)
    I have been using Tomcat as JSP/Servlet container in current project. However, I have not got full understanding about Tomcat configuration. Every time I need to modify configuration, I search on the web and learn those related elements. I don't have a big picture about it. To fully understand the configuration, I read through official document at this site http://tomcat.apache.org/tomcat-6.0-doc/config/. And as I expect, it helps me a lot.
The configuration file of Tomcat is $TOMCAT_HOME/conf/server.xml.
(1) Server

Root element is server.
(2) Service
    A Service element represents the combination of one or more Connector components that share a single Engine component for processing incoming requests. So it looks like a container to enclose related Connector and Engine.
(3) Connector
    Connector receives requests from clients. There are two kinds of connector:HTTP and AJP.
HTTP Connector enables Tomcat to function as a stand-alone web server. An instance of connector listens for connections on a specific port number. One service can contain more than one connector. Normally, every connector maintains its own thread pool. However, this can be altered by setting property executor. If so, the connector will use the executor and all thread related properties are ignored. One advantage of using executor is that it can shared between components.
    "Each incoming request requires a thread for the duration of that request. If more simultaneous requests are received than can be handled by the currently available request processing threads, additional threads will be created up to the configured maximum (the value of the maxThreads attribute). If still more simultaneous requests are received, they are stacked up inside the server socket created by the Connector, up to the configured maximum (the value of the acceptCount attribute. Any further simultaneous requests will receive "connection refused" errors, until resources are available to process them."
    If SSL on HTTP is needed, corresponding connector element should be modified. Property redirectPort can be used to redirect SSL request received by a plain connector to another connector which supports SSL.
(4) Engine
    Following all connector elements in a service component is engine element. Engine element represents processing machinery associated with a service. It gets and processes all requests from connectors and returns the response to Connector. Note: exactly one engine element should be defined inside a service element.
(5) Host
    Inside engine element, multiple host elements can be nested. Each host element represents a virtual host. At least one host is required, and one of the hosts MUST match value of property defaultHost of engine element. Element alias can be used to give alias. Property appBase is used to specify application base directory of the virtual host. Properties deployOnStartUp and autoDeploy can be configured to set functionality of auto-deployment.
(6) Context
Context element represents a web application which is run inside a certain virtual host. "Each web application is based on a Web Application Archive (WAR) file, or a corresponding directory containing the corresponding unpacked contents, as described in the Servlet Specification (version 2.2 or later)." However, in high version of Tomcat, Context elements do not need to written in server.xml. Detailed information is:
    "For Tomcat 6, unlike Tomcat 4.x, it is NOT recommended to place <Context> elements directly in the server.xml file. This is because it makes modifing the Context configuration more invasive since the main conf/server.xml file cannot be reloaded without restarting Tomcat.
Context elements may be explicitly defined:
  • in the $CATALINA_HOME/conf/context.xml file: the Context element information will be loaded by all webapps
  • in the $CATALINA_HOME/conf/[enginename]/[hostname]/context.xml.default file: the Context element information will be loaded by all webapps of that host
  • in individual files (with a ".xml" extension) in the $CATALINA_HOME/conf/[enginename]/[hostname]/ directory. The name of the file (less the .xml extension) will be used as the context path. Multi-level context paths may be defined using #, e.g. context#path.xml. The default web application may be defined by using a file called ROOT.xml.
  • if the previous file was not found for this application, in an individual file at /META-INF/context.xml inside the application files
  • inside a Host element in the main conf/server.xml

How to map incoming request to specific web app?
    "The web application used to process each HTTP request is selected by Catalina based on matching the longest possible prefix of the Request URI against the context path of each defined Context. Once selected, that Context will select an appropriate servlet to process the incoming request, according to the servlet mappings defined in the web application deployment descriptor file (which MUST be located at /WEB-INF/web.xml within the web app's directory hierarchy)."

Deployment
    If you want to develop and deploy your JSP/Servlet applications, consult this page: http://tomcat.apache.org/tomcat-6.0-doc/appdev/deployment.html. It contains information about: Standard directory layout, where to put shared libraries, web.xml and deployment. This link also contains some useful information: http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Automatic%20Application%20Deployment.

Configuration of virtual host:
http://hi.baidu.com/zouziting/blog/item/7e3ad7808f3491d79123d936.html