a cup of java

And we now have Firefox 3.5, which they claims to the better, faster, safer & smarter one yet, with lot of new features like private browsing, improved awesome bar, cross site XHR.

Features
Tips n’ Tricks
Download

It’s a very good article – 12 tips for designing an excellent checkout process – for those who involved in e-commerce related product design and development.

Building a good checkout experience is about several things. It’s about eliminating distractions to help the user focus at the task at hand. It’s about providing all the necessary information and help so that the customer understands all the stages of the process. Most important, it’s about making it easy, because after all, the quicker a customer can check out, the happier they will be and the quicker you’ll close the sale.

You can also try this article too – Shopping Carts: Examples And Best Practices – from Smashing Magazine.

Read the article here: http://www.smashingmagazine.com/2009/05/28/12-tips-for-designing-an-excellent-checkout-process/

Have a nice read.

In one of my previous posts I mentioned about building a JAR using ANT.  This post – building a WAR (Web Application Archive) – is just an add-on to that.

Structure of a WAR file

Application.war
|-- META-INF
|  |-- manifest.mf
|-- WEB-INF
|  |-- web.xml   - deployment descriptor
|  |-- classes   - class files organized in packages
|  |-- lib       - other libraries
|
|-- <other files, directories etc.>

Deployment descriptor
This is a sample deployment descriptor from Java Servlet Specification version 2.4. Get the descriptor (.pdf)


Build file

<project name="my.enterprise.project" default="build.my.war">
<property name="deploy.dir" value="/my/deploy/dir" />
<property name="file.name" value="Application.war" />
  <target name="build.my.war">
    <fileset dir="contents">
      <include name="**/*"/>
    </fileset>
    <war destfile="${file.name}" webxml="conf/web.xml">
      <classes dir="bin" />
    </war>
    <echo>Copying ${file.name}...</echo>
    <copy file="${file.name}" todir="${deploy.dir}" />
    <delete file="${file.name}" />
  </target>
</project>

The above build file assumes that all the non-java resources and JSPs are within the “contents” directory. The build file will pick the class files from the “bin” directory within the base. Here the build file is not compiling existing source files. To compile Java files there is another ANT task -  javac.

<javac srcdir="src" destdir="bin" classpathref="application.classpath"/>

Add the javac task before the war task in the build file.

Defining the class path

<path id="application.classpath">
   <fileset dir="/path/to/my/lib">
      <include name="javax.servlet.jar"/>
   </fileset>
</path>

Define the path before the target – build.my.war.

Read more
http://ant.apache.org/manual/CoreTasks/war.html
http://ant.apache.org/manual/CoreTasks/javac.html
http://ant.apache.org/manual/dirtasks.html

Venu had another JBoss hack and he was able to fix one more issue that may bubble up during the migration from JBoss 4.x to 5. This time found out how solve “Adding multiple last resources is disallowed. Current resource is ….” exception which happens while trying to access an EJB from a different EAR with in a transaction and trying to commit that transaction.

Read the article here

What is a filter?
From the JSR 154 specification,

A filter is a reusable piece of code that can transform the content of HTTP requests, responses, and header information. Filters do not generally create a response or respond to a request as servlets do, rather they modify or adapt the requests for a resource, and modify or adapt responses from a resource.

How to write a filter?
We can create a filter by writing a new class which implements javax.servlet.Filter. We need to specify the filters in the deployment descriptor so that the container can create a filter chain to process the request/response.

The filters in deployment descriptor:

<web-app>
	<filter>
		<filter-name>MyFilter</filter-name>
		<filter-class>subin.rnd.enterprise.filter.MyFilter</filter-class>
	</filter>
	<filter-mapping>
		<filter-name>MyFilter</filter-name>
		<url-pattern>/*</url-pattern>
	</filter-mapping>
	<filter-mapping>
		<filter-name>MyFilter</filter-name>
		<servlet-name>MyServlet</servlet-name>
		<dispatcher>REQUEST</dispatcher>
	</filter-mapping>
</web-app>

We can have a filter (or a chain of filters) processing the request/response. In the above descriptor, we are linking a filter for a URL pattern as well as for a specific servlet. So in the above case, for MyServlet, the filter will get executed twice as we have mapped the filter MyFilter to all URLs and for MyServlet. So the order of execution will be MyFilter.doFilter() > MyFilter.doFilter() > MyServlet.doGet().

MyServlet.java

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class MyServlet
extends HttpServlet
{
  @Override
  public void doGet(HttpServletRequest request,
    HttpServletResponse response)
  throws ServletException
  {
    System.out.println("doGet()");
    response.setContentType("text/plain");
    ServletUtility.write(response, "Hello world!".getBytes());
  }
}

MyFilter.java

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletResponse;

public class MyFilter
implements Filter
{
  public void destroy()
  {
  }

  public void doFilter(ServletRequest request, ServletResponse response,
     FilterChain filterChain)
  throws IOException, ServletException
  {
     System.out.println("doFilter()");

     ByteStreamResponseWrapper responseWrapper = null;
     byte[] responseAsBytes = null;
     String processedResponse = null;

     // Creating a response wrapper
     responseWrapper = new ByteStreamResponseWrapper(
        (HttpServletResponse) response);
     filterChain.doFilter(request, responseWrapper);

     // Process the response
     processedResponse = responseWrapper.toString();
     if (null != processedResponse)
     {
       processedResponse = processedResponse.toUpperCase();
       responseAsBytes = processedResponse.getBytes();
     }

     // Writing the response (as bytes) to the servlet output stream
     ServletUtility.write(response, responseAsBytes);
  }

  public void init(FilterConfig filterConfig)
  throws ServletException
  {
    // We can initialize a filter using the init-params here
    // (which we defined in the deployment descriptor - web.xml)
  }
}

Other files
There are two more Java files – ByteStreamResponseWrapper & ServletUtility. ByteStreamResponseWrapper is an extension of javax.servlet.http.HttpServletResponseWrapper with some methods – toString(), getOutputStream() & getWriter() – overriden. ServletUtility is a utility class to write a byte stream to the servlet output stream.

Output
The “Hello world!” from MyServlet is filtered to “HELLO WORLD!”  by MyFilter.

Fig: Output in browser

Fig: Jboss console output

Note:
I wanted to put above XML in syntax-highlighted mode; but the WordPress plug-in failed miserably. Tough luck.