Nice book written by Chuck Cavaness.
I wanted to share few quotations found from the next 2 chapters(9-10) from this book.
1) The Struts framework provides a mechanism to allow components to be plugged in and loaded dynamically. This feature was added in Version 1.1 and is supported through the use of the org.apache.struts.action.PlugIn interface. Any Java class can function as a plug-in, as long as it implements the PlugIn interface.
2) An example of using the Struts PlugIn mechanism
import java.util.Hashtable;
import javax.naming.InitialContext;
import javax.naming.Context;
import org.apache.struts.action.ActionServlet;
import org.apache.struts.config.ApplicationConfig;
import org.apache.struts.action.PlugIn;
import javax.servlet.ServletException;
public class JNDIConnectorPlugin implements PlugIn {
private String jndiFactoryClass;
private String jndiURL;
private Context initCtx = null;
public JNDIConnectorPlugin( ) {
super( );
}
public void init(ActionServlet servlet, ApplicationConfig config)
throws ServletException{
// Get the host and port where the JNDI service is running
jndiFactoryClass = servlet.getInitParameter("jndi-factory-class");
jndiURL = servlet.getInitParameter("jndi-url");
try{
Hashtable props = new Hashtable( );
// The EJB spec also allows these to be read from the jndi.properties file
props.put( Context.INITIAL_CONTEXT_FACTORY, jndiFactoryClass );
props.put( Context.PROVIDER_URL, jndiURL );
initCtx = new InitialContext(props);
}catch( Exception ex ){
throw new ServletException( ex );
}
// Store the JNDI Context into the ServletContext
servlet.getServletContext( ).setAttribute( "Storefront.InitCtx", initCtx );
}
public void destroy( ){
try{
if ( initCtx != null ){
initCtx.close( );
initCtx = null;
// No need to remove from ServletContext because app is being shut down
}
}catch( Exception ex ){
ex.printStackTrace( );
}
}
}
3) Adding the plug-in to the configuration file
The plug-in must be declared in the Struts configuration file in order for the framework to be aware of it and initialize it at startup. It's specified in the configuration file using the plug-in element:
<plug-in className="JNDIConnectorPlugin"/>
If more than one plug-in element is specified, they will be initialized in the order in which they are listed in the configuration file.
4) The JVM uses a method invocation stack, also referred to as a call stack, to keep track of the succession of method invocations of each thread. The stack holds local information about each method that has been called, going all the way back to the original main( ) method of the application. When each new method is invoked, a new stack frame is pushed onto the top of the stack, and the new method becomes the executing method. The local state of each method is also saved with each stack frame.
5) When a Java method completes normally, the JVM pops the current method's stack frame from the stack and continues processing in the previous method where it left off. When an exception condition occurs, however, the JVM must find a suitable exception handler. It first checks to see if the current method catches the exception or one of its parent exceptions. If so, execution will continue in that catch clause. If the current method doesn't provide a catch clause to handle the exception raised, the JVM will start popping method frames off the call stack until it finds a handler for the exception or one of its parent exceptions. Eventually, if it pops all the way back to the main( ) method and still doesn't find a handler for the exception, the thread will terminate. If that thread is the main thread and there are no other non-daemon threads running, the application itself will terminate. If the JVM does find an exception handler along the way, that method frame will become the top of the stack and execution will continue from there.
6) Java exceptions can be separated into two distinct groups: checked and unchecked. A checked exception signals an abnormal condition that the client must handle. All checked exceptions must either be caught and handled within the calling method or be declared in the throws clause following the method signature. This is why they are called "checked." The compiler and the JVM will verify that all checked exceptions that can occur in a method are handled. The compiler and JVM don't care if unchecked exceptions are ignored, because these are exceptions that the client usually cannot handle anyway. Unchecked exceptions, such as java.lang.ClassCastException, are typically the result of incorrect logic or programming errors.
The determination of whether an exception is checked or unchecked is based simply on its location in the exception hierarchy. All classes that are descendants of the java.lang.Exception class, except for subclasses of RuntimeException , are checked exceptions; the compiler will ensure that they are either handled by the method or listed in the throws clause. RuntimeException and its descendants are unchecked exceptions, and the compiler will not complain about these not being listed in a throws clause for a method or being handled in a try/catch block. This is why they are referred to as "unchecked."
About the Author
Chuck Cavaness is a graduate from Georgia Tech with degrees in computer engineering and computer science, has built Java-based enterprise systems in the healthcare, banking, and B2B sectors. Working at an Internet company to design and develop software architecture, Chuck has spent many frustrating hours figuring out the dos and the don'ts of web applications. With each enterprise system he's developed, Chuck has learned several valuable lessons about building "real-world" web applications, information that he's made available to developers who haven't had the opportunity to work on large systems.
Chuck is the co-author of Special Edition Using Java 1.3 and Special Edition Using EJB 2.0, both available from QUE.
No comments:
Post a Comment