Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Struts best practices

Build the best performing large applications

By Puneet Agarwal, JavaWorld.com, 09/13/04

Page 2 of 5

Struts best practice

The possible solutions to this problem:

• Do not let users access any JSP page directly. The starting page can be an HTML document. Add the following lines to the web.xml file to prevent users from accessing any JSP page directly:
  
  

  <web-app>
     ...
    <security-constraint>
      <web-resource-collection>
        <web-resource-name>no_access</web-resource-name>
        <url-pattern>*.jsp</url-pattern>
      </web-resource-collection>
      <auth-constraint/>
    </security-constraint>
    ...
  </web-app>
  

• The most popular option is to keep JSP pages behind the WEB-INF folder. This has a few tradeoffs. For example, you cannot take the JavaScript/CSS (Cascading Style Sheets) files behind WEB-INF, and if using Struts modules, you may encounter some context-related problems. Refer to the section "Context-Related Problems," which appears later in this article, to circumvent such issues.

The second approach allows some JSP pages (which are not behind WEB-INF) to be visible directly. It does not require a descriptor file entry, therefore the best practice is to keep the pages behind WEB-INF.

Error categorization

Problem

Error handling becomes complex for an n-tiered application. In a browser-based application, the errors can be handled in the client layer using JavaScript and in the Web tier or EJB (Enterprise JavaBeans) tier using custom Java methods. Building an infrastructure for consistent error reporting proves more difficult than error handling. Struts provides the ActionMessages/ActionErrorsclasses for maintaining a stack of error messages to be reported, which can be used with JSP tags like <html: error> to display these error messages to the user. The problem is reporting a different category/severity of the message in a different manner (like error, warning, or information). To do that, the following tasks are required:

1. Register the errors under the appropriate category
2. Identify these messages and show them consistently

Struts best practice

Struts' ActionErrors class comes in handy in resolving the first issue of stacking messages of different categories. To display the error messages of different categories, define these categories such as FATAL, ERROR, WARNING, or INFO, in an interface. Then, in the Action or form-bean class, you can use:

errors.add("fatal", new ActionError("....")); or 
errors.add("error", new ActionError("....")); or 
errors.add("warning", new ActionError("....")); or 
errors.add("information", new ActionError("....")); 
saveErrors(request,errors);

Having stacked the messages according to their category, to display them according to those categories, use the following code:

<logic:messagePresent property="error"> 
<html:messages property="error" id="errMsg" >
    <bean:write name="errMsg"/>
</html:messages>
</logic:messagePresent >

Or use:

<logic:messagePresent property="error"> 
<html:messages property="error" id="errMsg" >
    showError('<bean:write name="errMsg"/>'); // JavaScript Function
</html:messages>
</logic:messagePresent >

Validation of service requester: Login-check

Problem

Authentication in a Web-based application can be done in any class, depending upon whether an SSO-based (single sign-on) or a JAAS-based (Java Authentication and Authorization Service) mechanism is being used. The challenge is identifying the placeholder for checking the service requester's authenticity and the user session's validity.