Some Java, JEE and WebSphere stuffs | Something about JEE and WebSphere. Java, JEE and WebSphere tips and tutorials

Last day I was taking an interview in my company. The interview was for WebSphere Commerce. So I thought of going directly to WCS questions. But that guy said that he was working on WCS long back and he forgot everything in WebSphere Commerce. Then I thought I will ask some JSP questions as he was mentioned JSP in each and every project in his resume.

I thought of starting with a usual JSP interview question. So I asked him what is the difference between static include and dynamic include in JSP. His answer was partially correct. So I though I will write a post on what are the differences between static include and dynamic include in JSP. So the difference between static include and dynamic include are

• The syntax for static include is <%@ include file=”filename.jsp” %> and the syntax for dynamic include is <jsp:include page=”filename.jsp” />

• Static include is an inline inclusion. i.e., the contents of the file will be included at translation phase. It’s something like a copy and paste . In case of dynamic include the response of the file will be included to the original response at runtime. The file will be processed separately and only the response will become the part of the original files’ response.

• Static include cannot have a dynamic filename. This is because the servlet container needs the files for inclusion, at translation phase itself. But dynamic include can have a dynamic filename. Here the file is getting included at runtime.

• Static include cannot accept a parameter (What this parameter will do even if are passing it?). But dynamic include can accept a parameter. (Here we have some one to do something on the parameter).

• Static includes are faster than dynamic includes.

I believe these are the differences between static include and dynamic include. I think I have covered all. If I missed anyone, please let me know.

A J2EE application will be bundled in an EAR (Enterprise Archive) file for the deployment. The EAR file can contain different modules like Web Module, Resource Adapters, Client application modules and EJB modules. The structure of an EAR file is a follows.

EAR file
|
| – META-INF
- application.xml (The deployment descriptor of an EAR file).

| – Resource Adapters (xyz.rar)
- META-INF
- ra.xml (Deployment descriptor for resource adapters)
|
| – Client modules (xyz.jar)
- META-INF
- application-client.xml (Deployment descriptor for client modules)
|
| – EJB Modules (xyz.jar)
- META-INF
- ejb-jar.xml (EJB deployment descriptor)
|
| – WAR Modules (xyz.war)
WEB-INF
web.xml (Deployment descriptor of web module)

The EAR file may or may not contain one or more modules.

How to use a LIKE clause with PreparedStatement object? I had this requirement and all the methods that I tried were not working. Java was not giving me any compile time nor run time errors. However the result was not coming as expected. I did some search on that and finally I got the solution. When we use PreparedStatement with LIKE clause, give the percentage sign in your setXXX method.

For eg:

	String firstName ="A";
	String query = "SELECT NAME, EMAIL FROM USER WHERE USERID LIKE ?";
	PreparedStatement stmt = con.prepareStatement(query);
	stmt.setString(1, "%"+firstName+"%");
	ResultSet rst = stmt.executeQuery();

The above code is tested in WebSpere Application Server + Oracle and Tomcat + MySQL environments and is working fine.

There is an easy an elegant way to convert or store an exception stack trace to a string variable. The following method takes an exception object as a parameter and returns the string representation of the stack trace.

public String getStackTrace(Exception ex) {
        java.io.StringWriter out = new java.io.StringWriter();
        ex.printStackTrace(new java.io.PrintWriter(out));
        String stackTrace = out.toString();
 
        return stackTrace;
    }

Defensive copying is used for protecting the field of an object from being changed by all non native class. Sometimes if we do not use defensive copying our object may hold incorrect data. For eg:

import java.util.*;
 
public class Test {
	private Date today;
 
	public void setToday(Date dt) {
		this.today = dt;
	}
 
	public Date getToday() {
		return today;
	}
 
	public static void main(String args[]) {
		Test t = new Test();
		Date dt = new Date();
 
		t.setToday(dt);
 
		System.out.println("Actual :: " + t.getToday());
 
		dt.setYear(2000);
 
		System.out.println("Current :: " + t.getToday());
	}
}

The output of the above program will be.

Actual :: Mon Jan 07 12:29:43 IST 2008
Current :: Sun Jan 07 12:29:43 IST 3900

In the above program changing the dt object changes t object data also. To prevent this we use defensive copying. The fix for this will be to create a defensive copy of the object in the setter. For eg:

public void setToday(Date dt) {
	this.today = new Date(dt.getDate());
}

Now if we run the program the output will be

Actual :: Mon Jan 07 12:29:43 IST 2008
Current :: Mon Jan 07 12:29:43 IST 2008