Changing View JSP In doView Of A Portlet With JSF

I'm playing around with JBoss portal server, Portlets and JSF these days and I had to change the view of a portlet when a value in database changed. The value is changed from another portlet and the portlet I was developing had to look for the change every time it was rendered and reset it self if the value had changed. Looked simple enough but I had to waste a good part of a day to find a good solution.

I'm new to all these technologies and depend on Google to find me solutions but I couldn't find anything that helped me to do this with Sun Reference Implementation of JSF. I found one that described how to do it in IBM implementation of JSF which obviously didn't work on Sun RI. The problem is you just can't redirect to a JSP in the doView method if you are using JSF. I tried to do it by overriding the doView method in FacesPortlet.

Then I found this article on JSF Central which described how to redirect a user to a login page if the user is not logged in and that's exactly what I wanted. All I had to do was

1. Write a PhaseListener and in the beforePhase method do my database check and set the view ID to my start page view id if the value had changed.
   
2. Change the getPhaseId method to return PhaseId.RENDER_RESPONSE which makes the PhaseListner fire every time a page is rendered. The PhaseId.RESTORE_VIEW event is not fired every time a portlet is rendered.
3. Configure the PhaseListener in faces-config.xml

That was it, pretty easy and would have been if I knew a little bit more about JSF :)

public class DBPhaseListener implements PhaseListener { public void beforePhase(PhaseEvent event) { FacesContext fc = event.getFacesContext(); System.out.println("Current View ID" + fc.getViewRoot().getViewId()); if (changed()) { System.out.println("Changing view"); NavigationHandler nh = fc.getApplication().getNavigationHandler(); nh.handleNavigation(fc, null, "main"); } } private boolean changed() { // code to check db changes } public void afterPhase(PhaseEvent event) { } public PhaseId getPhaseId() { return PhaseId.RENDER_RESPONSE; } }

And the faces-config.xml

<faces-config>
<lifecycle>
<phase-listener>com.test.DBPhaseListener</phase-listener>
</lifecycle>

<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>main</from-outcome>
<to-view-id>/WEB-INF/jsp/index.jsp</to-view-id>
</navigation-case>
</navigation-rule>

<!-- rest of the faces-config -->
</faces-config>

Testing HTTPS Secured Actions with StrutsTestCase

If you have secured some Struts actions using SSLEXT's Struts plugin (org.apache.struts.action.SecurePlugIn) you will have to invoke the action over https, else SSLEXT will redirect to the configured HTTPS port.

So in order to test secured actions using MockStruts test cases you need to inform SecurePlugIn that the request came over https. This is quite easy as the HttpServletRequestSimulator class that's used by MockStruts has a setScheme method. All you have to do is set the scheme to HTTPS in the inherited request object before calling the actionPerform method in the test class.

e.g.

public class LoginTest extends MockStrutsTestCase { public void testlogin() { setConfigFile("/WEB-INF/struts-config.xml"); setRequestPathInfo("/login"); addRequestParameter("username", "test"); addRequestParameter("password", "test1234"); //set the request's scheme to HTTPS request.setScheme("HTTPS"); //invoke action actionPerform(); verifyNoActionErrors(); verifyForward("success"); } }

Speed up MockStruts Test Execution by Caching Spring Context

If you are using MockStruts to test your Struts/Spring application most of your test execution time would be spent on initializing or trying to initialize the Spring context for each test method.

This is true if you use Spring's ContextLoaderPlugIn, where it tries to initialize a custom spring context using the parent context.

Spring will look for the parent context in the ServletContext object where it store it. Since MockStruts will create a new ServletContext for each test method Spring will try to create the context each time. This results in addition of about 4 second per test method (on my workstation).

Note: I'm using MappingDispatchAction with multiple actions in a single Action class, therefore I have mutiple test methods in a single test class too.

The above 4 second penalty per test method can be removed by simply caching and storing the Spring context in ServletContext object before each test execution. This reduced the execution time of the whole test suite drastically in the application I was working on.

In order to achieve the above I used a base class extending MockStrutsTestCase as shown below and used it as the parent class for all the Struts test cases

import org.springframework.context.ApplicationContext; import org.springframework.web.context.ContextLoader; import org.springframework.web.context.WebApplicationContext; import servletunit.struts.MockStrutsTestCase; public abstract class BaseStrutsTestCase extends MockStrutsTestCase { /** Spring context */ private static ApplicationContext applicationContext; /** * Setup Spring context * * @throws Exception * exception */ protected void setUp() throws Exception { super.setUp(); if (applicationContext == null) { // this is the first time. Initialize the Spring context. applicationContext = (new ContextLoader()).initWebApplicationContext(getRequest().getSession() .getServletContext()); } else { // Spring context is already initialized. Set it in servlet context // so that Spring's ContextLoaderPlugIn will not initialize it again getRequest().getSession().getServletContext().setAttribute( WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, applicationContext); } } /** * Returns the Spring application context * * @return initialized Spring application context */ public ApplicationContext getApplicationContext() { return applicationContext; } }

Also remember to set forkMode to perBatch or once in ants junit task as shown below if you have set the fork attribute to true.

<junit fork="true" forkmode="once" haltonfailure="">
...

</junit>

Unit Testing with Junit, Spring and Hibernate - Part 2

This is a continuation from my previous post on Spring and MockStrutsTestCase and focus on testing Hibernate DAO's. As I mentioned in the previous post, Spring framework provides a nifty base class (AbstractTransactionalDataSourceSpringContextTests) that provides automatic transaction rollback, exposing a JDBC template to interact with the DB and auto wiring of beans.

Lets take a simple DAO class that save a User object to the database:

public class UserDaoImpl extends HibernateDaoSupport implements UserDao { public void save(User user) { getHibernateTemplate().save(user); } }

Now in order to test this you would write a test class as below extending from AbstractTransactionalDataSourceSpringContextTests class.

public class UserDaoTest extends AbstractTransactionalDataSourceSpringContextTests { private UserDao userDao; private SessionFactory sessionFactory = null; protected String[] getConfigLocations() { return new String[]{"test-spring-config.xml"}; } /** * Spring will automatically inject UserDao object on startup * @param userDao */ public void setUserDao(UserDao userDao) { this.userDao = userDao; } /** * Spring will automatically inject the Hibernate session factory on startup * @param sessionFactory */ public void setSessionFactory(SessionFactory sessionFactory) { this.sessionFactory = sessionFactory; } /** * Test the save method * */ public void testSave(){ String query = "select count(*) from user where first_name = 'Firstname'"; int count = jdbcTemplate.queryForInt(query); assertEquals("A user already exists in the DB", 0, count); User user = new User(); user.setFirstName("Firstname"); userDao.saveUser(user); // flush the session so we can get the record using JDBC template SessionFactoryUtils.getSession(sessionFactory, false).flush(); count = jdbcTemplate.queryForInt(query); assertEquals("User was not found in the DB", 1, count); } }

The test class has to implement the protected String[] getConfigLocations() method from the base class and return a String array of Spring config files which will be used to initialize the Spring context.

UserDao and SessionFactory properties are defined with the setter methods and the base class will take care of injecting them automatically from the Spring context. Auto wiring will not work if there are multiple objects implementing the same interface. In such a case you can remove the setter method and retrieve the object using the exposed applicationContext as below.

/** * Overridden method from base class which gets called automatically */ protected void onSetUpBeforeTransaction() throws Exception { super.onSetUpBeforeTransaction(); userDao = (UserDao) applicationContext.getBean("userDao"); }

The base class also exposes a JDBC template object (jdbcTemplate) that can be used to query data or setup test data in the database. Note that you need to have a data source and a transaction manager defined in your Spring config in order to use the AbstractTransactionalDataSourceSpringContextTests base class. The data source defined in the config file will be bound to the exposed JDBC template.

In the testSave method first we verify there is no record in the User table where first name equals to 'Firstname' using the jdbc template object. Then we call the save method on the UserDao passing it a User object.

Now we simple verify there is a record in the table where first name equals to 'Firstname'. Before running the query we flush the current Hibernate session to make sure jdbcTemplate can see the newly added record.

Thats it and when the testSave method exits the current transaction will be rolled back and the record inserted to the User table will not be saved. This is great as your test database will always be at a know state at the start and end of a test method.

The spring config file will like below (test-spring-config.xml) :

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> <beans> <bean name="userDao" class="com.dao.UserDaoImpl"> <property name="sessionFactory"> <ref bean="sessionFactory"/> </property> </bean> <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean"> <property name="dataSource"> <ref bean="dataSource"/> </property> <property name="mappingResources"> <list> <value>hibernates/User.hbm.xml</value> </list> </property> <property name="hibernateProperties"> <props> <prop key="hibernate.query.factory_class">org.hibernate.hql.classic.ClassicQueryTranslatorFactory</prop> <prop key="hibernate.dialect">org.hibernate.dialect.OracleDialect</prop> </props> </property> </bean> <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/> <property name="url" value="jdbc:oracle:thin:@localhost:1521:ORCL" /> <property name="username" value="test" /> <property name="password" value="test" /> </bean> <bean id="txManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager"> <property name="sessionFactory"><ref local="sessionFactory"/></property> </bean> </beans>

How to Properly Iterate a Collection in Java

There are multiple ways to iterate a collection in Java among many other things but that doesn't mean all are equally elegant or easy on the eyes. Just as some ways to skin a cat are messier than others (Not that I have ever skinned a cat or any other animal for that matter). Anyhoo I'm making this post in hopes of at least few developers starting on Java will see it before starting to write code in a commercial project.

I came across a code base of a project that was developed mostly by a bunch of junior developers and most of the code that iterates a collection was in the following format

List administrators = getAdministrators();

if (administrators.size() > 0) {
    Iterator administratorsItr = administrators.iterator();
       Administrator administrator = null;
       while (administratorsItr.hasNext()) {
          administrator = (Administrator) administratorsItr.next();
          //rest of the code block removed
       }
    }
}

Just looking at that piece of code made my head spin :). The worst part was that this is the style most of the junior developers had adopted and could be seen all over the code base.

Just for the record I would have written it in the following way (actually would have let the IDE write it for me)

List administrators = getAdministrators();

for (Iterator iter = administrators.iterator(); iter.hasNext();) {
   Administrator administrator = (Administrator) iter.next();
   //rest of the code block removed
}

The above two code blocks achieve the same thing, the difference been, first is 9 lines long and the second is 4 lines. Most importantly you can figure out whats going on easily by looking at the second code block.

The worst part is IDEs like IntelliJ IDEA will write it for you. All you have to do is type itco and press ctrl + space keys just after the List administrators = ... line.

I don't know if there is something similar on Eclipse but you can import all these nifty IDEA Live Templates into Eclipse. Just head over to this page where you can find the xml file and instructions on how to import the file.

Achieve Automatic Transaction Rollback with MockStrutsTestCase and Spring

Spring provides a convenience base class (AbstractTransactionalDataSourceSpringContextTests which extends the TestCase class from Junit) to automatically rollback any updates made to the database at the end of a test method. This works great when integration testing Service and DAO beans but it wont help when integration testing the Struts layer with MockStrutsTestCase.

Spring does not provide a class such as AbstractTransactionalDataSourceSpringContextTests that extends from the MockStrutsTestCase. This might be due to practical issues with the way Spring context initialization works when using MockStrutsTestCase. I tried achieving the transaction rollback in the same way as was done in the AbstractTransactionalDataSourceSpringContextTests class but it didn't work out as the application code started a new transaction and commited as usual without using the transaction I started in my own subclass of MockStrutsTestCase.

Another option left for me was to go down to the Transaction Manager level and achieve the rollbacks there. The application uses Hibernate at the DAO level and it was using HibernateTransactionManager as the transaction manager implementation when running test cases . Therefore I had to write a new class extending from HibernateTransactionManager which overrides the doCommit() method. The overridden method will call doRollback() method in the super class. This would rollback the current running transaction even if the declarative transaction handling code in Spring calls doCommit on the transaction manager.

package com.xyz.txn;

import org.springframework.orm.hibernate3.HibernateTransactionManager;

public class HibernateRollbackTxnManager extends HibernateTransactionManager {

 /*
  * doCommit method that calls the doRollback method of the super class.
  *
  */
 protected void doCommit(DefaultTransactionStatus txnStatus) {
     super.doRollback(txnStatus);
 }
}

Finally override the default transaction manager in your test spring bean configuration with the rollback only implementation.

  <bean id="txnManager" class="com.com.xyz.txn.HibernateRollbackTxnManager">
      <property name="sessionFactory"><ref local="sessionFactory"></property>
  </bean>

The same strategy would work with other transaction managers such as DataSourceTransactionManager too.

Save Time Fixing Ant Errors With -verbose Switch

Resolving ant errors can be a pain sometimes because of the vague error messages you get on the console. Yesterday I was getting a "Process fork failed." error on my Junit task and all I got on the console was

BUILD FAILED
C:\work\builds\build.xml:58: Process fork failed.

I wasted a couple of hours on google looking for an answer and after failing to fix the issue with several suggested solutions, I stumbled upon one post that suggested enabling the verbose output of Ant. All you had to do was pass -verbose as a command line parameter to ant

ant -verbose <target>

That made ant display lot of details including the actual exception. In my case it was:

C:\work\build\build.xml:58: Process fork failed.
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(JUnitTask.java:871)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:679)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1413)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:633)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
Caused by: java.io.IOException: CreateProcess: C:\bea92\jdk150_04\jre\bin\java.exe ...


I found the issue a little bit above the exception on the console and it was the massive classpath value passed into the java.exe. Obviously the Windows command line has a limitation on the length of command line arguments and the value for classpath was exceeding it.

When I checked the build file I found the error, where it was adding the files in a directory instead of the directory into the classpath. Fixed that small error and all was fine again.

Anyway glad I got to know about the verbose switch in Ant and hopefully I wouldn't have to waste a lot of time again fixing ant issues again.

Why would anyone want to buy a commercial JDBC driver?

In all the projects that I worked on over the last 5 to 6 years, nobody even thought about using a commercial JDBC driver. When I started on J2EE development you had to buy a JDBC driver for MS SQL server. This was around 2000-2001 when Microsoft didn't have an implementation.

We bought a driver from i-net software (Opta if I remember correctly) which I guess was the best commercial driver available at that time. Later on the application was ported to Oracle and we were happy to use the Oracle thin driver instead of bothering to buy another commercial implementation.

Since then I have worked for several big enterprise clients, developing Java web applications that connected to Oracle, MS SQL Server and DB2 (ver 7.2) databases. All these applications were using the database vendor provided drivers and all was well except for the DB2 driver (net driver).

I used to visit i-net software web site frequently as their Crystal Clear reporting tool was used in some earlier projects. Today I stumbled upon their site again after a long time and I started wondering why no one even considers using commercial drivers anymore including myself.

I could think up of a few possible reasons to shell out few bucks for a JDBC driver.

1. Performance
2. Reliability
3. Available features (JDBC 3.0, XA support etc...)

Now if we take Oracle thin driver and the above list, I don't see how a third party driver can provide significant performance and reliability over the thin driver.

As for features, thin driver has every thing you would need on an average project. Commercial implementations usually have few additional bells and whistles (e.g. i-net Opta driver supports SSL encryption and implements JDBC 4.0 API) which usually are not that important.

I guess same could be said for the SQL Server drivers from Microsoft and hopefully the new DB2 drivers from IBM, that is they does the job for your average project.

Also given the fact that application servers like BEA Weblogic includes its own drivers for all major databases including SQL Server, DB2, Sybase and Informix, I really don't see a reason to buy a JDBC driver from a third party.

Having said that, I would love to know about instances where a commercial driver was used and the reasons behind it.

P.S. Elaborating on the issue with the older DB2 driver:

DB2 v7.2 didn't come with a type 4 JDBC driver and we had to use what was called the net driver. There was this funny problem where it failed to see some records in a table. Select queries would not return these records when connected through the net driver. We never figured out why and only solution was to delete the record and insert them back. Luckily for us it only happened in the QA server :). Anyhoo the database was upgraded to DB2 version 8 and the driver to the type 4 version that came with it.

Myth - Defining loop variables inside the loop is bad for performance

I like to define loop variables inside the loop on the line where the assignment is happening. For example if I was iterating through a String collection I would do it like below

private void test() {
   for (Iterator iter = list.iterator(); iter.hasNext();) {
       String str = (String) iter.next();
       System.out.println(str);
   }
}

The other day a colleague of mine was doing a peer review and he said this was bad and I should have defined the String variable str outside the loop. What he suggested was something like below.

private void test() {
   String str;
   for (Iterator iter = list.iterator(); iter.hasNext();) {
       str = (String) iter.next();
       System.out.println(str);
   }
}

When I questioned the logic behind it he said something like:

If you define str inside the loop it will get initialized in each iteration and that’s bad for performance.

Or something like that… and so the argument started. I mean str is a frigging variable not an object that would get initialized or anything. The compiler wouldn’t go allocating memory to str in each iteration and my belief was that it didn’t matter whether you declare str inside the loop or outside the loop. The compiler wouldn’t care and would generate the same byte code in either case.

I did some googling around and came across this blog which discusses the same thing though his preference was to declare the variable outside the loop. The first example was very similar to what I had in mind but it was with primitives. The second example with StringBuffer is a totally different story from mine.

So I had to do my own test, I wrote another class with the str declared outside the loop and compiled them both. Then using javap utility that comes with the JDK printed the byte code for both implementations (ie. javap –c –private <classname>)

Byte Code genarated when the variable is declared inside the loop:

private void test();
Code:
0: aload_0
1: getfield #15;
4: invokevirtual #22;
7: astore_1
8: goto 28
11: aload_1
12: invokeinterface #26,
17: checkcast #32;
20: astore_2
21: getstatic #34;
24: aload_2
25: invokevirtual #40;
28: aload_1
29: invokeinterface #46,
34: ifne 11
37: return
}

Byte Code genarated when the variable is declared outside the loop:

private void test();
Code:
0: aload_0
1: getfield #15;
4: invokevirtual #22;
7: astore_2
8: goto 28
11: aload_2
12: invokeinterface #26,
17: checkcast #32;
20: astore_1
21: getstatic #34;
24: aload_1
25: invokevirtual #40;
28: aload_2
29: invokeinterface #46,
34: ifne 11
37: return
}

Basically it’s the same byte code except the variable numbers are switched (ie. line 11 aload_1 become aload_2). So it really doesn't make a difference and where you declare the variable is a just a matter of taste.

How to notify JavaBlogs.com about blog updates with XML-RPC

Javablogs supports notification of blog updates with a remote API, which enables new blog post to appear on Javablogs immediately (javablogs API). I use blogger and as far as I can tell it doesn't support pinging javablogs.com. So i set out to write my own XML-RPC client to make my posts appear quickly (Yes I'm the impatient type).

Did a search for XML-RPC clients on the web and I found this open source Java library from Redstone. Downloaded the jar file and followed the instructions on Redstone page and the page describing the Weblogs API. I have to say when I started on this I didn't think it would be this easy but after about 10 minutes I had it working :).

Just add the following lines inside a main method and execute:

String weblogName = "Living Tao"; String weblogUrl = "http://livingtao.blogspot.com/"; //create a client pointing to the rpc service on javablogs XmlRpcClient client = new XmlRpcClient("http://javablogs.com/xmlrpc", true); //invoke the method to queue the blog for an update Object token = client.invoke("weblogUpdates.ping", new Object[] { weblogName, weblogUrl} ); System.out.println(token);

The code will out put the following result on successful execution:

{flError=0, message=Success. 1 blogs have been queued for update}

final - Least used keyword in Java development?

I've been writing Java code for a long time and I never thought about making a class or a method final until recently. Actually the only place the final keyword was used was when declaring constants. I still don't think you will gain much on performance by using final but the biggest selling point is the correctness it brings to the code.

So far our development team has not looked at the correct usage of final keyword during peer reviews, but going forward it will be added to the peer review guideline document. Hope I'll see more finals in our code after that [if anyone follows the guideline that is :) ]

Anyway here is a link to a good explanation on final keyword: The Final Word on the final Keyword

Testing application generated emails with Apache James server

Most of our applications send out emails to customers, different groups of people within the organization etc... Most of these emails were in HTML and had all sorts of fancy formatting in them. It was a pain developing and testing these emails and they took too much developer time.

We needed an easy way to test them locally in developer machines without using an external SMTP server.

The plan was to run a James server in every developer machine which forwarded all the emails it receives to an email account on the same server.

Following were the steps followed to achieve this:


1. Download and Run James Server

Downloaded the latest zip bundle from apache site (ver 2.3.1). Extracted to a folder and executed run.bat in the bin directory to start the server for the first time. This will extract the james.sar file in apps directory to the apps/james directory. Now you will be able to modify the configuration file (config.xml) in apps/james/SAR-INF.


2. Create a local email account.

Open a command window and type telnet localhost 4555. When asked for the user name and password type root for both. Now you will be in the admin console and create a email account by typing adduser test test. This will create an email account named test with the password set to test.


3. Delete remote delivery mailet.

Open up the config.xml and locate the RemoteDelivery mailet section <mailet match="All" class="RemoteDelivery">...</mailet> and remove the tag including all its content.


4. Add a forward mailet to forward all mails

Insert the following mailet in the place where the RemoteDelivery mailet was.
<mailet match="All" class="Forward">
<forwardto>test@localhost</forwardto>
</mailet>


5. Save config.xml and Restart the James Server


Now all emails generated by the application (which is configured to use the SMTP server on localhost) will be handled by the James server running in the local machine and it will forward all emails to the test@localhost email account regardless of recipient addresses in email messages.

You can configure Outlook Express or any other client to read the mails sent to test@localhost.

When to call isDebugEnabled() before writing debug messages

When using a logging framework like log4j most developers never check whether debug is enabled before writing a debug message or always makes the check. The theory behind it is to prevent unnecessary string concatenations if debug messages are disabled, which is the case most of the times on production environments.

logger.debug("Saved order successfully. Order ID : " + order.getId() +
" items in order " + order.getItems().size());

In the above case there is a new string object created by concatenating all the parameters before making the call to debug method. This is done regardless of debug is enabled or not which will be a unnecessary performance overhead if debug is disabled.

if( logger.isDebugEnabled()){
logger.debug("Before saving the order");
}

In the above code section the if condition is not necessary as there is no String concatenations involved and ends up adding two redundant lines of code.

Therefore the rule would be to do a isDebugEnabled check only if there is any String concatenation involved in the call to debug. This seems to be obvious but developers somehow keep getting this wrong.

Reduce logger initialization code in your Java applications

You might have logger initialization code in most of the classes in an application (e.g. Action, Service and DAO classes). This is actually unnecessary if these types of classes extend from your own base classes.

An application using log4j logging framework will initialize the logger in a class as

private static final Logger logger = Logger.getInstance(TestAction.getClass());

This is done in each and every class which needs to use a logger. Now if we use a base class for lets say all Struts Actions called BaseAction, it can contain the logger initialization code as below.

package com.test.web;

import org.apache.log4j.Logger;
import org.apache.struts.action.Action;

public abstract class BaseAction extends Action{
//initializes the logger object
protected final Logger logger = Logger.getInstance(this.getClass());
}

Now all sub classes that extends from BaseAction (implementation action classes) will have the logger object created on initialization with the proper class name. Even though in theory this creates a new logger object per instance of TestAction class, it wont be an issue since Struts will maintain only a single instance of TestAction to serve all requests mapped to it.

This could be applied to all Service, DAO classes as well if you are using a framework like Spring to manage them, where only one instance per implementation class will be created.

P.S. This post was modified as per comments by fabien...

Global Exception Handling for Struts and Tiles Applications

Update: The solution explained in this post has been tested only on Weblogic 8.1 and 9.2. On Tomcat 5.x this will not work and please post a comment with the results if you happen to test this on any other server or find a work around for the Tomcat issue.

I was looking at implementing a global error page for unhandled exceptions in a Struts / Tiles application. Normally this was achieved by adding a section in struts-config.xml with a custom exception handler to log the exceptions and the url to the global error page.

This would forward to the error page if an unhandled exception was thrown from the Struts action but will not do so if the exception occurred in one of the tiles JSPs. An exception in a tile would result in a partly rendered page but this was fine in previous app as there were hardly any logic in JSP files and it was very rare to have an exception at the JSP level in production.

In the new app though this wasn’t the case as there were lot of logic that went in to JSPs in the form of custom tags etc… that could potentially throw all sorts of exceptions at run time and I wanted to handle all these exceptions in a unified manner.

New Solution

I abandoned the global-exceptions approach in struts-config altogether and added a <error-page> section to the web.xml file which instructed the app server to forward the request to the specified URL on all unhandled exceptions.

<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/error </location>
</error-page>

Then added a servlet and a servlet mapping to the /error URL

<servlet>
<servlet-name>exceptionHandler</servlet-name>
<servlet-class>com.test.ExceptionHandlerServlet</servlet-class>
<init-param>
<param-name>errorPageURL</param-name>
<param-value>error.html</param-value>
</init-param>
<load-on-startup>3</load-on-startup>
</servlet>


<servlet-mapping>
<servlet-name>exceptionHandler</servlet-name>
<url-pattern>/error</url-pattern>
</servlet-mapping>

The ExceptionHandlerServlet would log the exception and redirect the browser to the URL defined in the servlet configuration (error.html).

ExceptionHandlerServlet Code:

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { try { logger.debug("Handling exception in ErrorHandlerServlet"); Throwable exception = null; // Check if struts has placed an exception object in request Object obj = request.getAttribute(Globals.EXCEPTION_KEY); if (obj == null) { // Since no struts exception is found, // check if a JSP exception is available in request. obj = request.getAttribute("javax.servlet.jsp.jspException"); } if ((obj != null) && (obj instanceof Throwable)) { exception = (Throwable) obj; } if (logger.isDebugEnabled()) { logger.debug("Request URI: " + request.getAttribute("javax.servlet.forward.request_uri")); } // request uri containing the original URL value will be available // only on servers implementing servlet 2.4 spec String requestURI = (String) request.getAttribute("javax.servlet.forward.request_uri"); logger.error("Exception while handling request: " + requestURI, exception); response.sendRedirect(errorPageURL); } catch (Exception e) { // Throwing exceptions from this method can result in request // going in to an infinite loop forwarding to the error servlet recursively. e.printStackTrace(); } }

Now on all unhandled exceptions the servlet will log the exception. Yet on some occasions where the exception was thrown in one of the tile JSPs the browser would display a partially rendered page and would not redirect to the error page.

This was due to tiles flushing content to the response buffer before the whole page was rendered. In such a situation the browser will happily display what it received and the redirect to the error page will have no effect.

In order to prevent or minimize the flushing of response buffer:

1. Set flush attribute to false in all tiles insert tags
2. Increase the response buffer size to minimize auto flushing

This was achieved by modifying the tiles layout jsp page.

<!-- sets the response buffer size to 64kb -->
<%@ page buffer="64kb"%>
<%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles"%>
…
<tiles:insert attribute="header" flush="false" />
<tiles:insert attribute="leftnav" flush="false" />
<tiles:insert attribute="body" flush="false" />
<tiles:insert attribute="footer" flush="false" />

In the above code segment all html formatting was removed for clarity. The response buffer was set to 64 kilobytes and this value should be decide based on the average page size of the application and the performance impact of the increased memory usage.