hotswap debugging: changing class files on the fly in debugger in java

When you connect your debugger to server, you can make changes to the code and force the server to reload the classfiles on the fly. You don’t have to restart the server. You can continue debugging with the changed code. This feature of JPDA is called hotswap debugging.

More on this at :

Related topic: Hot deploy

static getters for bean in JSP JSTL

When you write static getters for a bean’s static properties, you won’t be able to access it using the dot (.) notation in a jsp. Instead you should use a non static public method to access those fields in jsp using the ‘dot’ notation.

Storing common files in EAR under glassfish

Common jars like struts.jar, log4j.jar etc can be just dumped under the ear like this:


You can also club them under the lib directory like this:


Note that you cannot keep unjarred or expanded classes in EAR. Glassfish won’t pick them up. You’ve to jar them up to work.

More on this at

list of useful eclipse plugins in j2ee development

  1. anyedit
  2. filesync
  3. extended vs presentation
  4. implementors
  5. jadclipse
  6. regex util
  7. ntail
  8. mousefeed
  9. subclipse

Calling a procedure from oracle sql developer

Look for the package in the left
Double click the package declaration
Now click on the green colored ‘Run’ button. it will show you a dialog to run the proc.

easy steps for going live

Read this

what is serailVersionUID?

As per sun java doc at

The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender’s class, then deserialization will result in an InvalidClassException. A serializable class can declare its own serialVersionUID explicitly by declaring a field named "serialVersionUID" that must be static, final, and of type long:

 ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;

If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification. However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class–serialVersionUID fields are not useful as inherited members.

keywords: why override serailVersionUID, serialization serailVersionUID,InvalidClassException serailVersionUID

J2EE listeners mini tutorial

You can listen to servlet container  and http session events using

  • javax.servlet.ServletContextListener
  • javax.servlet.http.HttpSessionListener

ServletContextListener :
This interface contains two methods :

  • public void contextInitialized(ServletContextEvent sce);
  • public void contextDestroyed(ServletContextEvent sce);

The HttpSessionListener interface also contains just two methods, for session creation and invalidation events respectively :

  • public void sessionCreated(HttpSessionEvent se);
  • public void sessionDestroyed(HttpSessionEvent se);

There are also these:



(These are only available from a particular j2ee version. So check the j2ee version before using them)

How does the JNDI lookup for the ejb work when the ejb is bound to a different EJB location in sun-ejb-jar.xml?

The lookup is:
The acutal JNDI location is:

This EJB lookup using JNDI with a layer of indirection

Using the ejb-local-ref tag in web.xml

The actual sun-ejb-jar.xml


So the app server is smart enough to understand the look ups for java:comp/env/OMParticipantServicesEJB as the lookup for the EJB ‘OMParticipantServicesEJB’ and is able to locate home interface. If you remove the <ejb-local-ref> entry from web.xml, the lookup will fail with NameNotFoundException

More on this here:

This is for glassfish. Has details about mapping the JNDI name (resource-ref-name) in web.xml with actual JNDI (global):

You can also read more about this sun-web.xml here: Sun GlassFish Enterprise Server 2.1 Application Deployment Guide

Printing ant classpath

Here is the trick to debug ant classpath.  

 <property name=”myclasspath” refid=”wsit.classpath”/>

    <echo message=”Compiling the webservice classes. The classpath is ${myclasspath}” />

More on ant debugging from: