DispatchAction: ServletException : 'method' not found

javax.servlet.ServletException: Request[/addcomponent] does not contain handler parameter named 'method'. This may be caused by whitespace in the label text.

Cause:
The error was cause by Internet Explorer because it has a concept of a default submit action when enter is pushed. So it submits the form to the server but with no specified method parameter because no button was pushed. And if you have a page with multiple submit buttons (which is the whole point of using a LookUpDispatchAction class), the &method='someMethodName' will always be dropped.

Power of java.lang.System class

The class System has a variable out that represents the standard output, and the variable err that represents the standard error device. By default, they both point at the system console. This how the standard output could be re-directed:

Stream st = new Stream(new FileOutputStream("output.txt"));
System.setErr(st);
System.setOut(st);

sleep() Vs. wait()

The code sleep(1000); puts thread aside for exactly one second. The code wait(1000), causes a wait of up to one second. A thread could stop waiting earlier if it receives the notify() or notifyAll() call. The method wait() is defined in the class Object and the method sleep() is defined in the class Thread.

Synchronized methods and Synchronized statements

Synchronized methods are methods that are used to control access to an object. A thread only executes a synchronized method after it has acquired the lock for the method's object or class. Synchronized statements are similar to synchronized methods. A synchronized statement can only be executed after a thread has acquired the lock for the object or class referenced in the synchronized statement.

Boolean Operators & Vs. &&

If an expression involving the Boolean & operator is evaluated, both operands are evaluated. Then the & operator is applied to the operand. When an expression involving the && operator is evaluated, the first operand is evaluated. If the first operand returns a value of true then the second operand is evaluated. The && operator is then applied to the first and second operands. If the first operand evaluates to false, the evaluation of the second operand is skipped.

String Vs. StringBuffer

String object is immutable, StringBuffer object is mutable.

The significant performance difference between these two classes is that StringBuffer is faster than String when performing simple concatenations. In String manipulation code, character strings are routinely concatenated.

When a String is created, it is not destroyed. It remains in the pool of memory and whenever that string is referred, the JVM searches for the String from the string pool of memory and gets the relevant data. So as such String is expensive operation.
String buffer can be changed/modified based on our requirement. There are chances that you may need to form a query based on some conditions. Such queries can be formed using String buffer. Finally you can user the toString method to get the final String version of the stringBuffer.

Abstract Class Vs. Interface

• Abstract class is a class which contain one or more abstract methods, which has to be implemented by sub classes. Interface is a Java Object containing method declaration and doesn't contain implementation.
• The classes which have implementing the Interfaces must provide the method definition for all the methods.
• Abstract class is a Class prefix with a abstract keyword followed by Class definition. Interface is a Interface which starts with interface keyword.
• Abstract class contains one or more abstract methods. where as Interface contains all abstract methods and final declarations
• Abstract classes are useful in a situation that Some general methods should be implemented and specialization behavior should be implemented by child classes. Interfaces are useful in a situation that all properties should be implemented.

Differences are as follows:

• Interfaces provide a form of multiple inheritance. A class can extend only one other class. Interfaces are limited to public methods and constants with no implementation. Abstract classes can have a partial implementation, protected parts, static methods, etc.
• A Class may implement several interfaces. But in case of abstract class, a class may extend only one abstract class.
• Interfaces are slow as it requires extra indirection to to find corresponding method in in the actual class. Abstract classes are fast.

Similarities: Neither Abstract classes or Interface can be instantiated.

Javascript : NumberFormatter

Mail notification thru Log4j

1. Add mail.jar and activation.jar to lib.
2. Add SMTPappender in Log4j.xml

Add element for mail in element.

Date Utilities

Some methods for date calcuations..

public class DateUtils {

public static final String DATE_FORMAT = "dd/MM/yyyy";

/** * This method gives difference(number of days) in two dates.
* @param newDate
* @param oldDate
* @return
* @throws Exception
*/
public static int dateDiff (String newDate, String oldDate) throws Exception{

int noOfDays = 0;
int MILLIS_IN_DAY = 1000 * 60 * 60 * 24;
Date date1 = new SimpleDateFormat(DATE_FORMAT).parse(newDate);
Date date2 = new SimpleDateFormat(DATE_FORMAT).parse(oldDate);
long diff = date1.getTime() - date2.getTime();
if (diff > 0) {
noOfDays = (int)(diff/MILLIS_IN_DAY);
}
return noOfDays;
}


/**
* This method subtracts given number of days from specified date
* and returns resultant date as a string.
* @param newDate
* @param days
* @return
* @throws Exception
*/

public static String subtractDaysFromDate (String newDate,int days) throws Exception
{
Date date1 = new SimpleDateFormat(DATE_FORMAT).parse(newDate);
int MILLIS_IN_DAY = 1000 * 60 * 60 * 24;
long diff = date1.getTime() - MILLIS_IN_DAY;
Date tempDate1 = new Date(diff);
SimpleDateFormat format = new SimpleDateFormat(DATE_FORMAT);
String returnString = format.format(tempDate1);
return returnString;
}
/**
* This method adds given number of days to specified date and returns result date.
* @param strDate
* @param days
* @return
* @throws Exception
*/
public static String addDaysToDate (String strDate , int days) throws Exception{
String strDateNew = "";
Date tempDate = new SimpleDateFormat
(DATE_FORMAT).parse(strDate);
SimpleDateFormat format = new SimpleDateFormat(DATE_FORMAT);
Calendar cal = Calendar.getInstance();
cal.setTime(tempDate);
cal.add(Calendar.DATE,days);
Date tempDate1 = new Date(cal.getTimeInMillis());
strDateNew = format.format(tempDate1);
return strDateNew;
}

Decorator Pattern

In object-oriented programming, the decorator pattern is a design pattern that allows new/additional behavior to be added to an existing method of an object dynamically.

Introduction

The decorator pattern works by wrapping the new "decorator" object around the original object, which is typically achieved by passing the original object as a parameter to the constructor of the decorator, with the decorator implementing the new functionality. The interface of the original object needs to be maintained by the decorator.
Decorators are alternatives to subclassing. Subclassing adds behaviour at compile time whereas decorators provide a new behaviour at runtime.

Motivation (Good example..do read)

As an example, consider a window in a windowing system. To allow scrolling of the window's contents, we may wish to add horizontal or vertical scrollbars to it, as appropriate. Assume windows are represented by instances of the Window class, and assume this class has no functionality for adding scrollbars. We could create a subclass ScrollingWindow that provides them, or we could create a ScrollingWindowDecorator that merely adds this functionality to existing Window objects. At this point, either solution would be fine. (Another solution is to simply modify the existing Window class, but this is not always possible—we might not have access to its implementation, or we might be adding storage overhead for new functionality that the majority of objects will not use.)

Now let's assume we also wish the option to add borders to our windows. Again, our original Window class has no support. The ScrollingWindow subclass now poses a problem, because it has effectively created a new kind of window. If we wish to add border support to all windows, we must create subclasses WindowWithBorder and ScrollingWindowWithBorder. Obviously, this problem gets worse with every new feature to be added. For the decorator solution, we need merely create a new BorderedWindowDecorator—at runtime, we can decorate existing windows with the ScrollingWindowDecorator or the BorderedWindowDecorator or both, as we see fit.



Implementaion

If the subject class is heavyweight, with lots of data or methods, it may make decorators too costly. Instead of changing the skin of the object, you can change the guts, via the Strategy pattern. Strategies do not have to conform to the subject's interface. The Strategy pattern can always replace the Decorator pattern, but it requires more anticipation. The Decorator pattern requires virtually no anticipation.


Consequences

· A subject and its decorators are decoupled. The author of the subject does not need to do anything special for it to be decorated. Similarly, decorators do not need to prepare for being decorated.

· It is easy to add any combination of capabilities. The same capability can even be added twice. This is difficult with inheritance.

· The same object may be simultaneously decorated in different ways. Clients can choose what capabilities they want by sending messages to the appropriate decorator.

· Objects do not pay for capabilities they do not use. Thus we have efficiency and generality at the same time.

· While a decorator has the same interface as its subject, it is not the same object. Hence object identity is not compatible with decorators. This also makes it hard to add a new decorator at run-time, since all client pointers must be changed. See the Implementation section for a remedy.

· Delegation may be required for self calls to work properly.