Using Apache Commons Lang for Commonly used String operations

Apache Commons Lang is an API which simplifies the Java development by providing easy to use methods for the classes in java.lang package. This API provides a host of helper utilities, notably String manipulation methods, basic numerical methods, object reflection, concurrency, creation and serialization and System properties. Additionally it contains basic enhancements to java.util.Date and a series of utilities dedicated to help with building methods, such as hashCode, toString and equals.
Here goes a common example for String manipulation:
Lets take a String comparison example:
The classical way we perfom String comparison is:
void stringTest(String test)  {
if((test != null) && test.equalsIgnoreCase("test") {
// do something
}
}
Now lets see how Apache LangUtil is gonna help the above scenario:

void stringTest(String test)  {

if(StringUtils.equalsIgnoreCase(test, "test") {
// do something

}

}

The advantage of using the second method is that Stringutils will take care of null check and comparison, so that u dont have to really worry about NullPointerException. A lot of pretty utility methods are available, not only it ends with String comparison but to handle Object, Numbers, Date etc.

You can download the latest version of the API from here

Hope it helps you out. All the best!!!

Java Coding Conventions

Here goes a wonderful link to have a quick look at the Java Coding Conventions

Association, Aggregation and Composition in OOPS

Association
Association is a relationship where all object have their own lifecycle and there is no owner. Let’s take an example of Teacher and Student. Multiple students can associate with single teacher and single student can associate with multiple teachers but there is no ownership between the objects and both have their own lifecycle. Both can create and delete independently.
Points:
• Is a Relationship between objects.
• Objects have independent lifecycles.
• There is no owner.
• Objects can create and delete independently.

Aggregation
Aggregation is a specialize form of Association where all object have their own lifecycle but there is ownership and child object can not belongs to another parent object. Let’s take an example of Department and teacher. A single teacher can not belongs to multiple departments, but if we delete the department teacher object will not destroy. We can think about “has-a” relationship.
Points:
• Specialize form of Association.
• has-a relationship between objects
• Object have independent life-cycles
• Parent-Child relationship
Composition
Composition is again specialize form of Aggregation. It is a strong type of Aggregation. Child object dose not have their lifecycle and if parent object deletes all child object will also be deleted. Let’s take again an example of relationship between House and rooms. House can contain multiple rooms there is no independent life of room and any room can not belongs to two different house if we delete the house room will automatically delete. Let’s take another example relationship between Questions and options. Single questions can have multiple options and option can not belong to multiple questions. If we delete questions options will automatically delete.
Points:
• Specialize form of Aggregation
• Strong Type of Aggregation.
• Parent-Child relationship
• Only parent object has independent life-cycle.

Usage of webAppRootKey in Spring application

when deploying two applications build from the riot skeleton within  

the same Tomcat servlet container, you get an IllegalStateException: Web app root system property already set to different value: 'webapp.root' = [/Users/joe/ Workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/webapps/ webapp-A/] instead of [/Users/joe/Workspace/.metadata/.plugins/ org.eclipse.wst.server.core/tmp0/webapps/webapp-B/] - Choose unique values for the 'webAppRootKey' context-param in your web.xml files!

I will try to explain where this comes from and how to circumvent it,  
but first the quick fix for the impatient reader: Place a context  
parameter named 'webAppRootKey' in every project's web.xml and assign  
a value to it, that is unique for every of your projects like the  
project name itself.

The webAppRootKey context parameter is introduced by Spring. Along  
with the WebAppRootListener it allows exposing the web applications  
root directory as a system property. The value of the context  
parameter 'webAppRootKey' names the system property to use. If the  
context parameter 'webAppRootKey' is not set in the application's  
web.xml, Spring chooses the default value 'app.root'. While some  
servlet containers like Resin do isolate each web application's  
system properties, others like Tomcat do not. And that's what the  
former mentioned IllegalStateException is telling us:  The system  
property 'app.root' already contains the root directory of the first  
web application when Spring tries to assign the root directoty of the  
second application to it.

Ok, that's the background information. A deeper look into the web.xml  
tells us, that there ist no WebAppRootListener configured. Why does  
this initialisation take place anyway? The stack trace from the  
exception reveals the culprit: The Log4jConfigListener also tries to  
set the webAppRootKey, because this is an interesting mechanism for  
the Spring/Log4j integration. It allows log and config file locations  
relative to the web applications root directory. The  
Log4jConfigListener supports three init parameters at the servlet  
context level: 'log4jConifgLocation', 'log4jRefreshInterval' and  
'log4jExposeWebAppRoot'. See JavaDocs for more informations.

But, none of these parameters are set in the riot project skeleton's  
web.xml and none of the Log4jWebConfigureres features are used by the  
riot project skeleton. As long as you do stay with default log4j  
setup, the Log4jConfigListener is superflous.

At the end there are three possible solutions for the initial problem:

(1) Provide any of your applications with a unique 'webAppRootKey'.
(2) Set the servlet context parameter 'log4jExposeWebAppRoot' to  
'false'. This eliminates the use of log file locations relative to  
the web application's root directory but still allows a log4j config  
location outside the classpath.
(3) Remove the 'Log4jConfigListener' from your application's web.xml.