|
<junit fork="true" forkmode="once" haltonfailure="">
...
</junit>
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
}
}
}
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.
List administrators = getAdministrators();
for (Iterator iter = administrators.iterator(); iter.hasNext();) {
Administrator administrator = (Administrator) iter.next();
//rest of the code block removed
}
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);
}
}
private void test() {
String str;
for (Iterator iter = list.iterator(); iter.hasNext();) {
str = (String) iter.next();
System.out.println(str);
}
}
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.
String weblogName = "Living Tao"; |
logger.debug("Saved order successfully. Order ID : " + order.getId() +
" items in order " + order.getItems().size());if( logger.isDebugEnabled()){
logger.debug("Before saving the order");
}private static final Logger logger = Logger.getInstance(TestAction.getClass());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());
}
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
<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:
|
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.