Friday, March 13, 2009
Enabling Selective SSL
Monday, July 14, 2008
Take Control of Class loading in Java
The Java Classpath
Java relies on the environment property/variable, CLASSPATH, to designate the path that the Java runtime will use to search for classes and other resources, as they are needed. The CLASSPATH property can be designated using the CLASSPATH environment variable or the command-line option, -classpath.
A Java runtime typically finds and loads classes in the following order:
1) In the list of bootstrap classes – Classes which embody the Java platform, such as the classes in rt.jar.
2) In the list of extension classes – Classes utilizing the Extension Mechanism Framework (http://java.sun.com/j2se/1.4.2/docs/guide/extensions/spec.html) to extend the Java platform, stored in archive files (.jar, .zip, etc.) located in the
3) User classes – Classes that do not utilize the extension mechanism architecture identified using the -classpath command-line option or the CLASSPATH environment variable.
JDK 1.3 introduced the Class-Path manifest entry to be used to specify optional jars and directories that will be loaded if needed. The following illustrates a sample Class-Path entry:
Class-Path: mystuff/utils.jar mystuff/logging.jar mylib/
Consider the situation when a different version of a library exists on the classpath than an executing class may be expecting.
Classpath Version Conflicts
The runtime identity of a class in Java is defined by its fully-qualified name (the package name prepended to the class name), sometimes known as the FQN, and the ID of the classloader that loaded the class. Thus, each instance of a class loaded by multiple classloaders instances (In a JVM, each and every class is loaded by some instance of a java.lang.ClassLoader), is regarded as separate entities by the Java runtime. This means that multiple versions of the same class can be loaded into the Java runtime at any given time. This is a very powerful and flexible feature; however, the side effects of this can be confusing to a developer if not used intelligently.
Imagine that we load a new version of a database DAO with a slightly different API to meet the demands of a new feature of a DAO client, but we still need the old DAO for other clients not ready for the new API. In typical runtime environments, the new DAO will simply replace the old version and all new instances will be created from the new version. However, if the update takes place without stopping the runtime environment (hot-loading) any already existing instances of the old DAO will reside in memory alongside any instances of the new version of the DAO as they are created. This is confusing at best.
Even worse is the danger of a DAO client expecting to create an instance of the old version of the DAO, but actually getting an instance of the new version with the altered API.To ensure stability and safety, calling code must be able to designate the exact version of a class that it intends to use. This can be addressed with the introduction of a class-loading, component-container model and some simple class-loading techniques.
The success of a Java component packaged and deployed within an archive depends on:
a) The developer being able to specify which version of a component to instantiate
b) Loading the correct version of the component’s ancillary classes (dependency) based on information found in the same jar file as the component.
This gives complete control to developers and consumers of the component as to which version of each component is actually created and used.One of the biggest problems when dealing with shared libraries in Java, using standard classloaders, is the single namespace into which all classes are loaded. This makes it very difficult to use different versions of the same library at any given time. What is needed is the ability for a component to define its own namespace into which the component and all of its ancillary libraries reside.
Will discuss the concept of defining components and component namespaces by the archive into which they are stored.
Thursday, July 3, 2008
Action Form and Struts 2 Actions
An Action class with I/p fields:-
import com.opensymphony.xwork2.ActionSupport;
public class LoginAction extends ActionSupport{
private String username;
private String password;
public getUsername(){
return username;
}
public setUsername(String username){
this.username = username;
}
public getPassword(){
return password;
}
public setPassword (String password){
this.password = password;
}
public String execute() throws execution{
// some logic
return SUCCESS;
}
public void validate(){
// logic to validate
}
}
These input fields (username/password) should be set prior to the execution of the execute() method.
What is required for setting all input parameters before execute() method is invoked.. This is an interceptor named param(ParametersInterceptor). This interceptor is a part of basicstack and default stack interceptor stack. ParameterInterceptor sets all parameters on the value stack using ValueStack.setValue(String, Object) methods.
Model Driven Actions
Struts 2 also supports ActionForm pattern and POJO form objects. The concept of Model Driven action is used to inject the POJO from the Object (model) into the action. But for the action to process over it , the model of the action needs to be added to the action in its value stack making it available in the action.
This approach needs some additional implementation, The action class must implement com.opensymphony.xwork2.ModelDriven interface. The only method which is exposed by Model driven interface is the Object getModel(). This method provides the model to be pushed into the value stack.
Let’s see a sample example of POJO form, which can be injected in the action as its model.
public class user{
private String username;
private String password;
public getUsername(){
return username;
}
public setUsername(String username){
this.username = username;
}
public getPassword(){
return password;
}
public setPassword (String password){
this.password = password;
}
}
The loginAction described earlier can be converted into ModelDriven action by removing input properties with their getter/setter methods and implementing interface ModelDriven
import com.opensymphony.xwork2.ActionSupport;
import com.opensymphony.xwork2.ModelDriven;
public class LoginAction extends ActionSupport
implements ModelDriven, Preparable{
User user;
public void prepare(){
user = new User();
}
public User getModel(){
return user;
}
public String execute() throws execution{
// some logic
If(user.getUsername().equals(“ashu”)){
return SUCCESS;
}
else
return ERROR;
}
public void validate(){
// logic to validate
}
}
The getModel() method must be invoked earlier for populating its input properties with the data from request parameters, to make sure that the model is available in the value stack when input parameters are being set, the model driven interceptor is configured for the action. This interceptor should be configured before ParameterInterceptor and staticParameterInterceptor in the interceptor stack. We can use defaultStack as default interceptor stack.
The model object to be pushed into stack cannot be null, hence the model must be initialized before it is returned by getModel() method to be populated and pushed into Value stack. We can initialize model Object at a number point, Struts 2 provides an interface/interceptor duo which can be used to prepare action for execution. The interface to be implemented here is preparable which exposes the prepare () method, and the configuration of PrepareInterceptor makes sure that this method is invoked. So, the flow of execution of various methods can be controlled by the position of interceptors in the interceptor stack. The default stack is the good one to use.
Wednesday, July 2, 2008
Configuring Struts 2
- Configuring web.xml, struts.xml, struts. properties, struts-default.xml and strtus-plugin.xml.
- Zero configuration using Annotations. Only Web.xml is required to specify, FilterDispactcher and action packages.
In this blog I am posting a sample code to understand the 1st way of configuration, than after this will take you to other advance configuration.
Web.xml :- Struts 2 uses FilterDispactcher which is a servlet class that initializes struts framework and handles all the request.
<filter>
<filter-name>struts2</filter-name>
<filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
</filter>
<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Struts.xml:- This file is a default file for the struts 2 framework also known as the core configuration file for this framework. This file include configuration for <result-type>, <interceptors>, <interceptor-stack>, <global-results> and <action>. Explaining these in depth will require me to write one more blog only on struts.xml; here I am listing a sample struts.xml file which is usually used in configuring struts 2 application.
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE struts PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
"http://struts.apache.org/dtds/struts-2.0.dtd ">
<struts>
<include file=”struts-defualt.xml” />
<package name="default" extends = “struts-default”>
<action name="displayAction" class="com.struts2.ashu.DisplayAction">
<result name="success" >/success.jsp</result>
</action>
</package>
</struts>
Struts-default.xml:- This file may be included at the top of struts.xml file to include the standard configuration setting without having to copy them. The struts-default.xml file contains default configuration for the framework results, interceptors and interceptors stacks. The package defined in our sturts.xml file can extend <package> defined in struts-default.xml file. This makes all the default results, interceptors and interceptors stacks available to be used in our struts.xml file.
Struts. properties:- This file is used to override the default values set for different keys in default. properties file. This setting of keys help in customizing struts application.
For example :- To load application resources file for setting the values for internationalization/ property / label name on jsp is loaded in struts 2 using struts.properties.
// sample property file.
### Resources for parameter “com.struts2.ashu.ApplicationResources”
App.title=struts 2 Application
App.title=personal Information
##### stuts.properties will have an entry to load this file. The file will contain only a single line of code.
struts.custom.i18n.resources=com.struts2.ashu.ApplicationResources.
struts.properties files is used to customize/ override the default behavior of struts 2 application, this default behavior is present in default.properties file. This file contains number of other parameters to configure or override the default behavior in struts.properties.
Creating Right Indexes
Some cardinal rules:
- Create indexes for the column(s) in 'Where' clause. For e.g. "SELECT * FROM Employees WHERE Salary BETWEEN 10000 AND 20000". A index on 'Salary' would help here.
- Keep the indexes as short as possible.
- Select columns which high percentage of unique values for Indexes.
- Consider composite indexes if it avoid full table scan. This is in violation of short indexes. But you need to work on the trade off in your performance testing and tuning.
- Check the execution plan of the query using tools provided by Database vendor
- Indexes can become performance drag if overused. Please note that Indexes needs to be updated whenever data is modified.