Aspect Oriented Programing

• Aspect - Think of this as the general feature you want to apply globally to your application (logging, performance monitoring, exception handling, transaction management, etc).
• Advice - A chunk of code that is invoked during program execution, and is a piece of the logic for implementing your aspect. This is the first important piece of a Spring AOP aspect implementation! I like to compare advice implementations to the decorator pattern. While an advice doesn't necessarily wrap an entire object in concept, it has the same general effect. We'll learn in a bit that how that advice is applied is more granular/formal than typically defined in the decorator pattern however.
• Joinpoint - A *single* location in the code where an advice should be executed (such as field access, method invocation , constructor invocation, etc.). Spring's built-in AOP only supports method invocation currently, so joinpoints aren't particularly important to focus on at this point.
• Pointcut - A pointcut is a set of many joinpoints where an advice should be executed. So if, in Spring, a joinpoint is always a method invocation, then a pointcut is just a set of methods that, when called, should have advices invoked around them. This is the second important pieces of a Spring AOP aspect implementation!
• Targets/Target Objects - The objects you want to apply an aspect or set of aspects to!
• Introduction - This is the ability to add methods to an object. This is closely tied to, and is almost analogous to the term 'mixins'. It's really just a way to make an object of type A also an object of type B. Introduction in Spring is limited to interfaces. 

Java Memory Leak

In a production environment, memory leaks can force organizations to add more memory and hardware resources. They can even cause an application to crash unexpectedly. In theory, Java memory leaks should not emerge as a development or production issue because the garbage collector is responsible for memory management.

Built-in Java memory management enables developers to sidestep tedious memory management considerations and is a fundamental reason why Java is a relatively straightforward development environment. Practically, however, the garbage collector function is unable to accurately address all memory management considerations, due to programming oversights and Java language program loopholes that allow memory leaks.

The garbage collector's job is to periodically collect unreferenced objects. Java memory leaks typically occur because the garbage collector reserves, or allocates, memory for each object associated with a program - whether or not the program uses the object. The garbage collector, as a result, reserves memory for each object, but does not have the intelligence to reallocate memory reserved for an idle object to another command. Consequently, the garbage collector falsely assumes that memory is being used by objects. The objects that are not being used but still hold references are not collected, thus leading to memory leaks.

Failure to adequately manage memory can significantly hinder the performance of your Java and J2EE applications. This column will outline the root causes of memory leaks and detail best practices for identifying and eliminating memory leaks in development and production to ensure robust Java and J2EE application performance.

Four Leading Causes of Memory Leaks

Memory management is a complex process, and the source of a memory leak is not always evident. Outlined below are four leading causes of memory leaks.

STATIC COLLECTION CLASSES
Static collection classes, such as HashMap and Vector, are susceptible to memory leaks because they are designed to hold other referenced objects. Static key words (as shown in Listing 1) are likely to cause memory leaks because static variables remain in memory as long as the application runs, regardless of its object creation and destruction.

LISTENERS
There are several listener types available in J2EE that provide notification when an event occurs. Until a J2EE application receives event notification, any storage held by that application will not be garbage-collected by the Java Virtual Machine (JVM). Web application listener events are new in the Servlet 2.3 Specifi-ca-tion. These listeners include servlet creation and invalidation as well as application startup and shutdown. The two listener classes, javax.Servlet.servletContextListener and javax.servlet.http.HttpSessionListener, when not implemented correctly, can lead to long-running applications that hold storage. To avoid this problem, keep the storage associated with servlet sessions small to minimize the effect on the heap. The Graphics Interchange Format (GIF), for example, should not be held in a session object that is kept in session using a listener.

PHYSICAL CONNECTIONS
Physical connections, such as database and network connections, are not going to be garbage-collected automatically unless they are disconnected explicitly. Java database connections are typically initialized using the DataSource.getConnection() method, which is used to handle physical connections. These physical connections must be freed when they are no longer required by the application using the close() method. Because the scope of such connections is independent of the JVM, the garbage collector does not have the ability to affect a physical connection. When your application server uses the connection pool, the DataSource.getConnection() method allows you to release connections back to the pool so other transactions can use the physical connection to access the database.

Connection pools bring advantages to application development by reducing the overhead of an application by physically connecting to and disconnecting from a database. The physical connections are maintained by the application server and managed from a pool that is farmed out to each application that retrieves data from a database. Using a connection pool limits the number of physical database connections. Therefore, it is very important for an application to release its connection once it has finished sharing information with a database.

JAVA NATIVE INTERFACE REFERENCES
Similar to the physical connections mentioned above, the Java Native Interface (JNI) allows Java code to run with other languages, such as C and C++. The references created in the C or C++ application environments should be unreferenced explicitly. Because the C or C++ storage is not allocated from the JVM Heap, it will not be garbage-collected by the JVM. Because the JVM does not have the ability to de-allocate JNI references, JNI memory must be managed directly by the C or C++ application.

A Best-Practice Approach to Hunting Memory Leaks

It is not always easy to detect memory leaks by scanning your code. Not all of the programmers involved with a J2EE project may have the time or experience to code memory management appropriately. Although many project managers face this issue, there is no standard solution to this problem because nearly every Java environment is unique. There are, however, guidelines that development teams should follow to optimize memory performance. An overview of best practices for ensuring a high level of memory performance throughout each phase of the "build, run, manage" application infrastructure life cycle follows.

BETTER CODING
Listing 2 illustrates how programmers can overlook memory leaks. The helper object in Listing 2 is a memory leak until another class removes it from the LongReferent class. Listing 2 shows that the garbage collector is not always responsible for collecting memory. The memory leak in this program can be avoided by removing the helper object from LongReferent explicitly, by the same class or by some other class. Objects stored in a HashMap are removed using the clear() or remove(object key) HashMap class method calls. Once the reference is removed from the HashMap, it is a candidate for garbage collection. Always double-check that the references are released, especially when you write static collection classes, listeners, database access code, and JNI code.

One approach to avoiding memory leaks is to write both "create method" and "remove method" commands in each class, then check for remove-method usage. In the unit-testing phase, you can search for create-method and remove-method usage in the code. The memory code is functioning properly if there is an equal number of calls for the create method and remove method commands. If the number of calls for these methods don't match, you should fix the code by adding or removing methods wherever they are missing.

BETTER APPLICATION PROGRAM INTERFACE
To achieve an added level of control over memory and garbage collection from the program, J2EE introduced the java.lang.ref package. For example, the WeakHashMap class java.lang.ref package uses weak keys to reference objects within the garbage collection. An object is available for the garbage collector when the WeakHashMap key is invalid. The garbage collector can make a key invalid if the memory is low, allowing the object it references to be freed. The garbage collector moves the key through three stages: finalizable, finalized, and reclaimed. It is not unlikely that the application could try to retrieve an object only to determine the object has been reclaimed by a garbage-collection cycle. This process works effectively for objects that can be re-created and easily collected whenever memory is running low.

Listing 3 shows the usage of the WeakHashMap class. Listing 3 is similar to Listing 2, except that it uses the WeakHashMap instead of the HashMap class. The difference between the two classes is that HashMap contains strongly referenced keys, which cannot be removed until the program unreferences them explicitly. The WeakHashMap class contains weakly referenced keys that can be removed by the garbage collector without unreferencing, or removing, keys in the program when memory is running low. The garbage collector algorithm determines the removal of weakly referenced keys. This varies by JVM.

The garbage collector generally removes unused, weakly referenced objects first so that it can allocate the unused memory for new objects. The program also checks for null keys and refreshes them with keys and values when it uses WeakHashMap. As part of this process, the garbage collector works in the background to remove the keys automatically. These classes are important to consider, especially when you implement memory-hog functionality - such as caching modules - that enables cached objects to be easily re-created. This approach can be used to replace the HashMap calls in the first example.

BETTER DEVELOPMENT AND TESTING TOOLS
Even when following best practices, it is virtually impossible to avoid memory leaks in medium or large projects in which many programmers are writing thousands of lines of code. Fortunately, there are effective performance tools available to pinpoint memory leaks automatically. Some products are built into development solutions, and others are stand-alone tools. Some of the newest development tools include profilers, which enable developers to monitor performance issues from the same development integrated development environment. Profiler solutions from Candle Corp. and other vendors can pinpoint memory leaks automatically as part of a broader development tool. An effective profiler tool must enable developers to:

1. Identify which method allocated the memory
2. Clarify if the memory was released by the garbage collector and how long it was allocated
3. Determine which objects are holding the reference to the memory; Listing 1 shows that the HashMap is holding the memory reference

The bar chart in Figure 1 shows the top 10 allocated object references. The table below tells the programmer what program allocated the memory and if it had been garbage-collected. An object reference tab that shows the method holding the reference to the memory is also available. Many of today's tools can make it very easy to pinpoint memory leaks and, therefore, avoid production outages.

BETTER PRODUCTION TOOLS
Although profilers excel at identifying memory leaks and other performance problems, developers and testers must be able to use the tools effectively. Memory problems that are overlooked in development will likely cascade in the production phase. Profiles provide development teams with a significant amount of performance data, which, in turn, may create more development cycles in the project due to the additional work associated with finely tuning memory management. Added production cycles may not be feasible for projects that have tight deadlines.

Fortunately, monitoring tools in production enable users to track J2EE application performance in real-world environments. Production profiling solutions from Candle, IBM, and other vendors monitor resource utilization for memory consumption. These tools provide visibility into the J2EE application environment that enables users to proactively improve performance and avoid production downtime.

Conclusion

Memory leaks often destabilize an application in production by consuming large quantities of memory or causing the JVM to crash. Moreover, whenever the system is low on memory the garbage collector tries to collect the memory more frequently, thus diminishing application performance. During development, programmers must pay special attention to memory leak problems associated with static collection classes, listeners, physical connections, and JNIs. The latest profiling tools identify memory problems long before the testing and production phases.

Production monitoring tools enable you to track application health and view otherwise-hidden performance metrics. Organizations are better able to tune memory management, which can improve the overall production stability and uptime. Organizations that address memory leaks by using a combination of development best practices and profiling and management tools can optimize memory management, which can increase the performance of their J2EE applications.

Reference : http://websphere.sys-con.com/node/44716

Spring some definitions

Spring ApplicationContext is essentially a registry of application objects.
The ApplicationContext object actually extends a Spring class called BeanFactory.
In reality, BeanFactory provides a good deal of the functionality developers often associate with an ApplicationContext.
A BeanFactory reads configuration data from a file typically, but not always, formatted in XML, and creates the types of objects desired. It manages dependencies between objects and provides a mechanism to control their lifecycles.
Spring is an 'interface-driven' framework and ApplicationContext (which includes BeanFactory) implements numerous interfaces that define its behavior.

JDBC

JDBC Drivers

The four type of jdbc drivers are

Type1. JDBC-ODBC Bridge











Pros
The JDBC-ODBC Bridge allows access to almost any database, since the database's ODBC drivers are already available. Type 1 drivers may be useful for those companies that have an ODBC driver already installed on client machines.
Cons
• The performance is degraded since the JDBC call goes through the bridge to the ODBC driver, then to the native database connectivity interface. The result comes back through the reverse process. Considering the performance issue, type 1 drivers may not be suitable for large-scale applications.
• The ODBC driver and native connectivity interface must already be installed on the client machine. Thus any advantage of using Java applets in an intranet environment is lost, since the deployment problems of traditional applications remain.

Type2. Native-API/Partly Java Driver










Pros
Type 2 drivers typically offer significantly better performance than the JDBC-ODBC Bridge.
Cons
The vendor database library needs to be loaded on each client machine. Consequently, type 2 drivers cannot be used for the Internet.

Type3.Net-protocol/All java Driver









Pros

The net-protocol/all-Java driver is server-based, so there is no need for any vendor database library to be present on client machines. Further, there are many opportunities to optimize portability, performance, and scalability. Moreover, the net protocol can be designed to make the client JDBC driver very small and fast to load. Additionally, a type 3 driver typically provides support for features such as caching (connections, query results, and so on), load balancing, and advanced system administration such as logging and auditing.
Cons
Type 3 drivers require database-specific coding to be done in the middle tier. Additionally, traversing the recordset may take longer, since the data comes through the backend server.



Type4.Native-protocol/All Java Driver











Pros
Since type 4 JDBC drivers don't have to translate database requests to ODBC or a native connectivity interface or to pass the request on to another server, performance is typically quite good. Moreover, the native-protocol/all-Java driver boasts better performance than types 1 and 2. Also, there's no need to install special software on the client or server. Further, these drivers can be downloaded dynamically.
Number of translation layers is very less i.e. type 4 JDBC drivers don't have to translate database requests to ODBC or a native connectivity interface or to pass the request on to another server, performance is typically quite good.
Cons

With type 4 drivers, the user needs a different driver for each database.

Java Heap Size

You can increase the heap size of your standalone class by
giving arguments

-Xms256m -Xmx256m

for tomcat add
export CATALINA_OPTS=-Xms512m -Xmx512m;

to the startup.sh file

Class Loaders

Class Loaders

i)Boot Strap Class Loader – load the java runtime classes(java.lang.ClassLoader)
ii)Extension Class Loader – loads the classes from the java.ext.dirs path (from .jar files) [ExtClassLoader]

iii)AppClassLoader – loads all the classes from the class path

All class loaders except the bootstrap class loader have a parent class loader. Moreover, all class loaders are of the type java.lang.ClassLoader

If a class (say Target.class) is loaded by 2 ClassLoaders separately and independently then types of both the classes(althought Target.class) will not be type compatible.
Target t1 = (Target) t2 will throw ClassCastException; where t1 and t2 are instantiated using different class loaders.This is because JVM treats 2 classes as
different types

Source : On Java

Hibernate Context Class File

import javax.naming.InitialContext;

import org.apache.log4j.Logger;
import org.hibernate.HibernateException;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;
import org.hibernate.cfg.Environment;

/**
* @author hennebrueder This class garanties that only one single SessionFactory
*         is instanciated and that the configuration is done thread safe as
*         singleton. Actually it only wraps the Hibernate SessionFactory.
*         When a JNDI name is configured the session is bound to to JNDI,
*         else it is only saved locally.
*         You are free to use any kind of JTA or Thread transactionFactories.
*/
public class InitSessionFactory {

 /**
  * Default constructor.
  */
 private InitSessionFactory() {
 }

 /**
  * Location of hibernate.cfg.xml file. NOTICE: Location should be on the
  * classpath as Hibernate uses #resourceAsStream style lookup for its
  * configuration file. That is place the config file in a Java package - the
  * default location is the default Java package.

  * 

  * Examples: 

  * CONFIG_FILE_LOCATION = "/hibernate.conf.xml". 
  * CONFIG_FILE_LOCATION = "/com/foo/bar/myhiberstuff.conf.xml".
  */
 private static String CONFIG_FILE_LOCATION = "/hibernate.cfg.xml";

 /** The single instance of hibernate configuration */
 private static final Configuration cfg = new Configuration();

 /** The single instance of hibernate SessionFactory */
 private static org.hibernate.SessionFactory sessionFactory;

 /**
  * initialises the configuration if not yet done and returns the current
  * instance
  * 
  * @return
  */
 public static SessionFactory getInstance() {
  if (sessionFactory == null)
   initSessionFactory();
  return sessionFactory;
 }

 /**
  * Returns the ThreadLocal Session instance. Lazy initialize the
  * SessionFactory if needed.
  * 
  * @return Session
  * @throws HibernateException
  */
 public Session openSession() {
  return sessionFactory.getCurrentSession();
 }

 /**
  * The behaviour of this method depends on the session context you have
  * configured. This factory is intended to be used with a hibernate.cfg.xml
  * including the following property 
  * name="current_session_context_class">thread This would return
  * the current open session or if this does not exist, will create a new
  * session
  * 
  * @return
  */
 public Session getCurrentSession() {
  return sessionFactory.getCurrentSession();
 }

 /**
  * initializes the sessionfactory in a safe way even if more than one thread
  * tries to build a sessionFactory
  */
 private static synchronized void initSessionFactory() {
  /*
   * [laliluna] check again for null because sessionFactory may have been
   * initialized between the last check and now
   * 
   */
  Logger log = Logger.getLogger(InitSessionFactory.class);
  if (sessionFactory == null) {
 

   try {
    cfg.configure(CONFIG_FILE_LOCATION);
    String sessionFactoryJndiName = cfg
    .getProperty(Environment.SESSION_FACTORY_NAME);
    if (sessionFactoryJndiName != null) {
     cfg.buildSessionFactory();
     log.debug("get a jndi session factory");
     sessionFactory = (SessionFactory) (new InitialContext())
       .lookup(sessionFactoryJndiName);
    } else{
     log.debug("classic factory");
     sessionFactory = cfg.buildSessionFactory();
    }

   } catch (Exception e) {
    System.err
      .println("%%%% Error Creating HibernateSessionFactory %%%%");
    e.printStackTrace();
    throw new HibernateException(
      "Could not initialize the Hibernate configuration");
   }
  }
 }
 
 public static void close(){
  if (sessionFactory != null)
   sessionFactory.close();
  sessionFactory = null;
 
 }
}

MP3 Tag lib (JID3 0.5.4) Saving ID3V2 Tags

Updating ID3V2 tags require to use frames (AbstractID3V2Frame) for each attribute and need to save the mp3File as many times as there are attributes.

1.Title (SongTitle) - FrameBodyTIT2
AbstractID3v2Frame titleFrame = id3v2.getFrame("TIT2");
if(titleFrame != null){
((FrameBodyTIT2)titleFrame.getBody()).setText(title);
}
else{
titleFrame = new ID3v2_4Frame(new FrameBodyTIT2((byte) 0, title));
id3v2.setFrame(titleFrame);
}
mp3File.setID3v2Tag(id3v2);
mp3File.save();

2.Album - FrameBodyTALB;
3.Artist - FrameBodyTPE1;
4.Composer - FrameBodyTCOM;

5.Year - FrameBodyTYER;
6.Track - FrameBodyTRCK;
7.Genre - FrameBodyTCON;
8.Copyright - FrameBodyTCOP;

9.Url - FrameBodyWXXX;
10.Encoded By - FrameBodyTENC;
11.Comment - FrameBodyCOMM;
12.Original Artist - FrameBodyTOPE;

/*While updating the id3 tag*/
While updating the id3 tag a file with a .original.mp3 extension of the same name is created.
The way i tackled this problem was by deleting this additionally created file by finding the file with .original extension to it.