Credit card validator in JSF

If you have a JSF page with credit card information you might want to validate the credit card number the user is entering. Different credit card companies (VISA,Master & Amex) have credit card numbers that follow different validation rules. All major credit cards will satisfy a Cyclic Redundancy Check (CRC) called Luhn Algorithm.

Luhn Algorithm

Step1: Sum all odd digits of the credit card number
Step2: Take each even digit multiply it by 2 if the result is greater than 9 subtract 9 from it then add it to the Sum of Step1
Step3: If sum is divisible by 10 then CRC passed else failed

To implement this lets do the following
1.In your JSP page which has the credit card form add the validator to the the card number input text field

                <h:inputText label="Credit Card Number:"
                              id="inpCCnumber" required="true"
                              value="#{backing_ccbean.cardNumber}">
                  <f:validator validatorId="CreditCardValidator"/>
                </h:inputText>

As you can see the custom credit card validator is called CreditCardValidator. The value is stored in the backing_ccbean. Assume there is a drop down list from which the user selects the card type(Visa,Master or Amex) and this value is stored in the same backing bean backing_ccbean in the attribute cardType, however this value will be set to the model object only after the validation phase so we need to directly bind to the component

 <h:selectOneListBox label="Credit card type" value="#{backing_ccbean.cardType}"
      binding="#{backing_requestscope.cardTypeChoice}">  
     <f:selectItem itemValue="1" itemLabel="Visa" />  
     <f:selectItem itemValue="2" itemLabel="Master Card" />
     <f:selectItem itemValue="3" itemLabel="American Express" />
 </h:selectOneListBox> 

backing_requestscope.cardTypeChoice maps to a javax.faces.component.html.HtmlSelectOneListBox this way we get the users selection in the validation phase of the JSF life cycle.

2. The next step would be to define CreditCardValidator in faces-config.xml. Add the following XML element to your faces-config

  <validator>
    <validator-id>CreditCardValidator</validator-id>
    <validator-class>validators.MyCreditCardValidator</validator-class>
  </validator>

The XML element is simple there is an ID and a Class we have called it MyCreditCardValidator.

3. Now let us write the java class MyCreditCardValidator in the package validators

package validators;

public class MyCreditCardValidator implements javax.faces.validator.Validator{


 public void validate(FacesContext ctx,UIComponent component,Object value) throws ValidatorException{
    String ccnum=(String)value;
    // get the card type form the binding object instead of the model object
    HtmlSelectOneListBox cardChoiceComp= (HtmlSelectOneListBox) context.getApplication().createValueBinding("#{backing_requestscope.cardTypeChoice}").getValue(context);
    int cardType = ((Integer)cardChoiceComp.getValue()).intValue();

    boolean validCard = validateCard(ccnum,cardType);

    if (validCard==false) throw new ValidatorException(new FacesMessage(" Invalid credit card format!!!!"));

  }

  private boolean validateCard(String ccnum,int cardType){
     // visa cards always start with 4 and are either 13 or 16 digits in length
     final int VISA=1;
    // master cards are 16 digits in length and the first 2 digits range from 51 to 55
     final int MASTER=2;
// Amex cards are 15 digits in length and the first 2 digits range from 34 to 37
     final int AMEX=3;
     switch(type) {
       case VISA:
                if ((ccnum.length() != 13 && ccnum.length() != 16) ||
                      Integer.parseInt(ccnum.substring(0,1))!=4)
                    return false;
                break;
       case MASTER:
                if (ccnum.length() != 16 ||
                       Integer.parseInt(ccnum.substring(0,2)) <> 55)
                    return false;
                break;
       case AMEX:
                if (ccnum.length() != 15 ||
                      (Integer.parseInt(ccnum.substring(0,2)) != 34 &&
                       Integer.parseInt(ccnum.substring(0,2))) != 37))
                    return false;
                break;
     }

    // luhn validate
    char[] charArr = ccnum.toCharArray();
    int[] num = new int[charArr.length];
    int total =0;
    for(int i=0;i -1; i--){
        if (alternate){ // multiply each even digit by 2 then add it to total
           num[i] *=2;
           if (num[i] > 9) num[i] -=9;
        }
        total +=num[i];
        alternate = !alternate;

    } 
    if (total % 10 != 0) return false;

     return true;

  }


}

In the MyCreditCardValidator class the most important thing to notice is how the value of card type is got since the validate method is called in the validation phase of a JSF life cycle the model objects are not set with the value hence the only way to get the value of a component other than the component that is being validated is thru the component binding.

Rollback JMS transactions in MDB Vs MDP

If you are writing an application which has a message driven bean or a message driven POJO you might want to put back the message in JMS destination if there is an exception in your application logic. In other words rollback the JMS transaction if there is an exception in onMessage. On a side note the acknowledgement mode of the message is considered to be AUTO_ACKNOWLEDGE instead of CLIENT_ACKNOWLEDGE as in the AUTO mode the messages are automatically removed from the queue unless a rollback is issue. Let us discuss how to issue a rollback in the case of an MDB first and then in a MDP.

Issuing a rollback in a Message Driven Bean (MDB)

A sample MDB implements MessageDrivenBean and MessageListener as follows

public class ExampleMDB implements javax.ejb.MessageDrivenBean, javax.jms.MessageListener{

javax.ejb.MessageDrivenContext context;

    public void setMessageDrivenContext(javax.ejb.MessageDrivenContext aContext) {
        context = aContext;
    }
// ejbCreate and ejbRemove methods go hear.

// onMessage needs to be implemented here
public void onMessage(javax.jms.Message inMessage) {

  // do your business logic here
 // if error in business logic rollback by calling
 context.setRollbackOnly();


}

}

The message driven context is set by the container in a container managed bean. The rollback is achieved by calling the context.setRollbackOnly() when this happens the message is put back in the queue. One should be carefull as the onMessage will be called repeatedly until the processing is fine and the rollback is not issued.

Issuing a rollback in a Message Driven POJO (MDP)

In a Spring MDP the task of issuing a rollback is as straightforward as just throwing a RunTimeException.

public class ExampleMDP implements javax.jms.MessageListener{


public void onMessage(Message message) throws RuntimeException{

   // if error in business logic throw a RuntimeException
}
}

When the MDP is configured in the application context xml file make sure it is sessionTransacted, by setting it's value to true. Refer to my earlier article
how-to-write-message-driven-pojo

IllegalStateException in Spring's JmsTemplate

I have been using Spring's JmsTemplate to send messages to Queue's and Topic's in SUN Java Message Broker. The code to implement this was really simple you just configure a bean in your context called jmsTemplate with points to class org.springframework.jms.core.JmsTemplate, autowire this bean in your code and there you have all the methods to send all kinds of objects to your JMS destination.

Every thing worked fine, but now and then the jmsTemplate.convertAndSend method used to throw an org.springframework.jms.IllegalStateException: Session closed; nested exception is javax.jms.IllegalStateException: Session closed. Now I am not sure if this is very specific to my version of JMS broker, but some more reading in the spring forum showed that it happens in other JMS brokers aswell. There seems to be a bug with the JmsTemplate spring code especially when it is multithreaded. It seems that the JMS session is shared across multiple threads and at times one thread gets hold of a closed JMS session.

I had to find a way around this issue till the bug is fixed by handling the exception and using a custom boilerplate code for sending JMS messages,which I agree sucks big time.

How to write a message driven pojo (MDP)

MDP is very simple to write in spring. There are quite a few examples out there. Follow these simple steps

Step1: Write a java class which implements javax.jms.MessageListener interface and implement the onMessage method

public class MyMessageListener  implements javax.jms.MessageListener{


    public void onMessage(Message message) throws RuntimeException{
 try{
  // do what you have to here
 }catch(Throwable ex) {
           throw new RuntimeException(ex);
        }
    }
}

Step2: Add the bean to your spring context.
In your spring context XML file that you have defined add the following entry. if you are using anotation then this is optional

<bean id="myListener" class="MyMessageListener"/>

Step3: Add a jms connection factory
Connection factories can been directly defined in the spring context in which case you need to also define the connection pooling. If your application is going to reside in an
application server then you can use JNDI to get the connection factory. If you are using the second approach you define the jndiTemplate then the connection factory

<bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate"/>
<bean id="jmsQueueConnectionFactory"  class="org.springframework.jndi.JndiObjectFactoryBean">
 <property name="jndiTemplate">
 <ref bean="jndiTemplate"/>
 </property>
 <property name="jndiName">
 <value>jms/QueueConnectionFactory</value>
 </property>
</bean>

Where jms/QueueConnectionFactory is defined as a resouce in the application server along with connection pool settings.

Step4: Add the jms container to your spring context XML file.
This step attaches your POJO to a specific JMS resource (Queue/Topic)

    <bean id="myJmsContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
        <property name="connectionFactory" ref="jmsQueueConnectionFactory"/>
        <property name="destinationName" value="MyExampleQ"/>
        <property name="sessionTransacted" value="false"/>
        <property name="messageListener" ref="myListener" />
        <property name="concurrentConsumers" value="1" />
        <property name="receiveTimeout" value="30000" />
    </bean>

And there you have it a simple message driven POJO called myListener mapping to the class MyMessageListener. It listens to messages in the queue named MyExampleQ
this is mentioned in the property destinationName. In this example sessionTransacted is set to false which means that if an exception occurs in onMessage method
the message will not be rolledback i.e. the message will be removed from the queue even if onMessage method failed. In most cases you might want the message to remain
in the queue if your operations in onMessage failed, in which case you need to set the value to true.

In this example concurrentConsumers is set to one you can use this property to better your performance by increasing this value.

Protecting your pages using servlet filtering

At some point in your web application development you will need to restrict access to certain pages based on login. In other words if a user goes to a protected page without logging in he/she needs to be redirected to the login page and thus enforcing security. This can be achieved using servlet filters. A servlet filter gets executed first before any JSP page is rendered and so we can check for a value of a session variable in this filter. The value is set in the login action so if a user skips login this value will not be set and so the servlet filter will throw them back to the login page. With this basic idea the implementation will be as follows.

Step1 Create a java class which implements javax.servlet.Filter

class  SecurityCheckFilter implements Filter {
{
private final static String FILTER_APPLIED = "_security_filter_applied";
private List nonRestrictedPages;

/**
* This method returns true if the page is not restricted like the landing page
*/
public boolean isNonRestrictedPage(String page){
  Iterator it = nonRestrictedPages.iterator();
  boolean result = false;
  while (it.hasNext()) {
     String nonrestrictedPage = (String)it.next();
     if (page.endsWith(nonrestrictedPage)) {
         result = true;
         break;
     }
  }
  return result;
}

public void init(FilterConfig conf) throws ServletException {
  nonRestrictedPages = new ArrayList();
  // index.jsp is the landing page of the application
  // and needs no logging in
  nonRestrictedPages.add("index.jsp");
}
/**
* This method gets called for every jsp page before the page gets rendered
*/
public void doFilter(ServletRequest request,
  ServletResponse response, FilterChain chain)
  throws IOException, ServletException {
  HttpServletRequest hreq = (HttpServletRequest)request;
  HttpServletResponse hres = (HttpServletResponse)response;
  HttpSession session = hreq.getSession();
  String requestedSession =   hreq.getRequestedSessionId();
  String currentWebSession =  hreq.getSession().getId();
  String currentpage = hreq.getPathTranslated();

  // if currentpage is null or is not a jsp page don't do any filtering
  if (currentpage == null || !(currentpage.endsWith(".jsp")) ) {
      if (chain != null) chain.doFilter(request, response);
      return;
  }

  // if the page is restricted and this filter is not
  // already applied do this block
  if ((isNonRestrictedPage(currentpage)==false) &&
      (request.getAttribute(FILTER_APPLIED) == null){

      request.setAttribute(FILTER_APPLIED, Boolean.TRUE);
      //If the session bean is not null get the session bean property username.
      String user=null;
      // This LoggedInBean is has the login information
      if(((LoggedInBean)session.getAttribute("backing_loggedin_bean"))!=null) {
          user = ((LoggedInBean)session.getAttribute("backing_loggedin_bean")).getUserName();
      }
      // if the user is not set and the current page is not
      // the login page then redirect back to login page
      if (user==null && (!currentpage.endsWith("login.jsp")))
      {
          hres.sendRedirect("login.jsp");
          return;
      }
  }

  //deliver request to next filter
  if (chain!=null)
      chain.doFilter(request, response);

}
}

Step2 Register your custom servlet filter class in the web.xml

<filter>
   <filter-name>Security Page Filter</filter-name>
   <filter-class>SecurityCheckFilter</filter-class>
</filter>
<filter-mapping>
   <filter-name>Security Page Filter</filter-name>
   <url-pattern>*.jsp</url-pattern>
</filter-mapping>

Catch All exception page for a JSF web application

If your application wants to display a generic error page if an internal exception occurs in your web application then all you have to do is register an action listener in your faces config, under the application as follows

<faces-config>
<application>
<default-render-kit-id>oracle.adf.core</default-render-kit-id>
<action-listener>
view.faces.GlobalActionListener
</action-listener>
</application>
<navigation-rule>
<navigation-case>
<from-outcome>exceptionNavigation</from-outcome>
<to-view-id>/global_exception.html</to-view-id>
<redirect>
</redirect>
</navigation-case>
</navigation-rule>
</faces-config>

Once you have configured your faces config with the action listener you create your java class called GlobalActionListener

import com.sun.faces.application.ActionListenerImpl;
import javax.faces.application.Application;
import javax.faces.application.NavigationHandler;
import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;
import javax.faces.event.ActionEvent;
import javax.faces.event.ActionListener;
import javax.servlet.http.HttpSession;

public class GlobalActionListener extends ActionListenerImpl implements ActionListener{
    public GlobalActionListener() { 
        super();
    }
    public void processAction(ActionEvent event){
        try{
            super.processAction(event);
        }catch(Throwable exception){
//This part of the code is reached if any of your pages throw an exception and if it is not handled
            FacesContext fc = FacesContext.getCurrentInstance();
            Application app = fc.getApplication();
        // goto this error page
            NavigationHandler nhandler = app.getNavigationHandler();
            nhandler.handleNavigation(fc, null, "exceptionNavigation");
            // invalidate the session
            ExternalContext ectx = FacesContext.getCurrentInstance().getExternalContext();
            HttpSession session = (HttpSession)ectx.getSession(false);
            session.invalidate();               
            fc.renderResponse();
        }
    }
}

Our GlobalActionListener implements the interface ActionListener and implements processAction method. It also extends the default Implementation from sun's class ActionListenerImpl. All that we have to do is call the base class's process Action and if an exception is throw catch that and redirect it to an exception page. In addition to redirecting to the exception page we also invalidate the http session.

The NavigationHandler class navigates to the exception page defined in faces config.

Using Client Acknowledge mode to expose a JMS topic as a Web service

A JMS session has three acknowledge modes AUTO, CLIENT and DUPS_OK, messages are removed from the JMS destination (Queue or Topic) only when the session has acknowledged that the client has received the message. In AUTO acknowledge mode the message is acknowledged as soon as the receive method has been completed. In DUPS_OK acknowledge the message is acknowledged lazily which means the message could be sitting in the destination for some time before the broker removes it at its will. In CLIENT acknowledge mode the client after receiving the message acknowledges it by calling its acknowledge method.This mode is key when you want to expose your JMS destination as a web service.

The one problem that needs to be solved when exposing a JMS destination as a web service is reliability. How do we make sure that the web service client has successfully received the message. In other words how do we support distributed transaction. The following example demonstrates this.

Target is to expose a JMS topic called yahoonews as web service.

Step1. Create a durable subscriber with CLIENT acknowledge mode

public Class DurableSubscriber{
  Context jndiContext = null;
  TopicConnectionFactory topicConnectionFactory = null;
  TopicConnection topicConnection = null;
  TopicSession topicSession = null;
  BasicTopic topic = null;
  TopicSubscriber topicSubscriber = null;

  public DurableSubscriber(){
      try {
          topicConnectionFactory =  new com.sun.messaging.TopicConnectionFactory();
          topicConnectionFactory.setProperty("imqBrokerHostName",brokerHost);
          topicConnectionFactory.setProperty("imqBrokerHostPort",brokerPort);         
       
          topicConnection = (com.sun.messaging.jms.TopicConnection)
          topicConnectionFactory.createTopicConnection();
          topicConnection.setClientID("yahoouserid1001");

          topicSession =
          topicConnection.createTopicSession(false,
          Session.CLIENT_ACKNOWLEDGE);
          topic = (com.sun.messaging.BasicTopic)topicSession.createTopic("yahoonews");
      } catch (Exception e) {
          e.printStackTrace();
          if (topicConnection != null) {
              try {
                  topicConnection.close();
              } catch (javax.jms.JMSException ee) {}
          }
      }
  }// end constructor

  public void startSubscriber(){
      try {

          topicConnection.stop();
          topicSubscriber =
          topicSession.createDurableSubscriber(topic,
          "finanancialnewsSubscriber");
       
          topicConnection.start();
      } catch (javax.jms.JMSException e) {
          System.err.println("Exception occurred: " +
          e.toString());
      }

  }

  public javax.jms.Message getMessage(int timeout) throws Exception{
  
     javax.jms.Message m = topicSubscriber.receive(timeout);
     return m;
  }
}

Step2. Create a wrapper class that will exposed as web service using REST or SOAP.
The web service should have two functions getMessage and ackMessage.
The class should also store the message that needs to be acknowledged.

public class JMSWebService{

  private static DurableSubscriber ds = new DurableSubscriber();
static{
   ds.startSubscriber();
}
  private javax.jms.Message ackMessage;

  public String getMessage(){
      if (ackMessage==null)
          ackMessage = ds.getMessage(1000); // 1 sec blocking call to get messages
      String str = ackMessage.getText();
      return str;
  }

  public void ackMessage(){
      if (ackMessage!=null)
          ackMessage.acknowledge();
      ackMessage = null;
  }
}

In this example reliability is achieved by having the ackMessage service along with getMessage, the client has to call the ackMessage function to indicate that all is well at the client side and that the client has commited the transaction at his end. If the ackMessage call is never made and the client keeps calling the getMessage function the transaction will not be commited and so the same message is returned to the client.

Traversing a large database result set using toplink

If you are developing a web application at some point you would have to deal with database queries that return large result sets, your web site might not give the best user experience if it takes several minutes to display your result set with thousands of rows in it. There are several patterns that address this, if you are using plain JDBC then there is the rowid pattern to traverse large result sets. Oracle toplink makes this pattern really simple using "Scrollable Cursors", combine this with some basic pagination logic will make users traversing through thousands of records in your web application very happy.

Here is a basic example that makes traversing an email database a breeze.

Using workbench generate your Email class from your sample Email table, work bench will also generate the database session file which have connection pool information.

Lets call our data access class EmailDAO

public class EmailDAO{
 private static Server dbServer;

class EmailResultSet{
   String mymail;
   Integer totalEmails;
   Integer pagesize;
   Integer pagenumber;
   Vector emails;
};

 static{
             // in 3 tier there needs to be one server instance and multiple client instances
                 // db-session.xml contains the database connection information and should be in classpath
                 XMLSessionConfigLoader loader = new XMLSessionConfigLoader("db-session.xml");
               SessionManager mgr = SessionManager.getManager();
                   dbServer =  (ServerSession)mgr.getSession(loader, "DBSession",
                         Thread.currentThread().getContextClassLoader());
 }

/*
  * mymail is the email address whose email we need to return
  * pagesize is the number of emails to be returned.
  * pagenumber
  */
 public EmailResultSet getMails(EmailResultSet emset){
         // Step 1 Establish connection using toplink 3 tier architecture
         Session clientSession = establishConnection();
     
        // Step2 construct the query
         ExpressionBuilder exbuilder = new ExpressionBuilder();
         Expression whereclause= exbuilder.get("emailaddress").equal(emset.mymail);
         ReadAllQuery rquery = new ReadAllQuery(Email.class,whereclause);
        rquery.addDescendingOrdering("time"); // sort by time column

         // Step3 tell the read query you want the result set split into chuncks of emails each chunk has pagesize number of emails in them
        rquery.useScrollableCursor(emset.pagesize);
      
        // Step4 execute the query
         ScrollableCursor cursor = (ScrollableCursor)  clientSession.execute(rquery);
         // instead of returning a ResultSet as in a conventional execute call a cursor is returned.

   // Step 5 find total emails
         cursor.last();
       // find the total number of email records by going to the last records position      
       emset.totalEmails = new Integer(cursor.getPosition());

   // Step 6 position the cursor
   // If pagenumber is greater than zero it means the caller knows which page he wants else position it to the first page
   if (emset.pagenumber>0)
       cursor.absolute(pagenumber); //point the cursor to the wanted page
   else
        cursor.first();
              
   // Step 7 get the result set
   Vector results = new Vector(emset.pagesize);
   for (int i=0; i<emset.pagesize && cursor.hasNext(); i++)
    {
               results.add(cursor.next());
 
     }
   emset.emails=results;
   return emset;

 }

 public Session establishConnection(){
                      ConnectionPolicy connectionPolicy = new ConnectionPolicy();
                 // Use an exclusive connection for the session
                 connectionPolicy.setShouldUseExclusiveConnection(true);
                     Session clientSession = dbServer.acquireClientSession(connectionPolicy);
                    return clientSession;

 }

}

JPA Entities with composite keys

EJB3 spec has made a real come back with JPA. Very often when we need to create a POJO with a composite primary key. JPA makes this very simple. If you want to create an Employee POJO with a composite primary key as first name and last name this is how you do it.

@IDClass(EmployeePK.class)
@Entity(name="EMPLOYEE")
public class Employee implements Serializable{
 
   @ID
   private String firstName;
   @ID
   private String lastName;
   private String qualification;
   private String speciality;
 
   // getters and setters go here

}

Now create a class called EmployeePK in the same package as Employee class with attributes firstName and lastName.

public class EmployeePK implements Serializable{
   private String firstName;
   private String lastName;

   // getters and setters for firstName and lastName go here...

}

REST vs SOAP

REST or Representational State Transfer has becoming more popular in the SOA world due to its simplicity compared to SOAP. Using SOAP it is definitely possible for different kinds of clients (java, .net etc) to call a SOAP service, but the style of the service does play a role in what the client can and cannot do. For instance .net client will have trouble calling a JAX-RPC style service. With document literal style all bean mappings in the WSDD should have name spaces which is not required in JAX-RPC. REST has made this very simple by dealing with XML or JSON instead of marshalled objects. The disadvantage being that the client will be getting back an XML or JSON.