Struts Guidelines

Struts (or more correctly, the Struts Action Framework) is probably the most successful Java web-application framework to date. It enables organization of Java web-applications using a model-view-controller (MVC) approach that makes it easier to write and maintain non-trivial applications.

The framework comprises

  • A front controller servlet (ActionServlet) that accepts, processes, and routes all incoming HTTP requests in accordance with a configuration file (struts-config.xml)

  • RequestProcessor and Action classes that can be extended and customized with application logic.

  • A set of JSP tag libraries (html, bean, logic, tiles) to simplify building forms and displaying output.

  • Support for populating HTML form input into regular or dynamic beans (DynaBeans).

  • Support for validating input and displaying error messages (ActionErrors,

The version of Struts shipped with JDeveloper 10.1.2 was 1.1. A number of books have been written about this version, see the Apache Struts 1.1 Project Home Page. Using 1.2 should not be a significant problem, but it does not include compelling enhancements. Note Struts 1.1 includes Commons BeanUtils 1.6.


  • Organize applications into pages, eg. CustomerSearch.jsp, CustomerView.jsp, CustomerEdit.jsp.

  • Follow the Oracle Browser Look And Feel (BLAF) guidelines for all corporate applications, see the Oracle Browser Look and Feel (BLAF) Guidelines. Use the blaf.css provided with JDeveloper, do not modify it.  Use the icons from the BLAF icon repository.

  • Place all JSPs into the WEB-INF directory, where they cannot be invoked directly. Provide a start.jsp in the public web root directory that forwards to a Struts action to start the application. Set start.jsp as the welcome file in web.xml.

  • Refrain from adding scriplets to JSPs as far as possible: place code in the corresponding Java class and use Struts :bean tags to display results in the JSP.

Action Classes

  • For each JSP create a corresponding Java class that extends DispatchAction and which handles requests from the JSP.

  • Use DynaActionForms to capture form input. These are configured in struts-config.xml, eliminating the need to write Java bean classes for each input form.

  • Validate all input on the server side. Although JavaScript can be used on the client for added responsiveness, client side validation can always be bypassed or disabled.

  • Do not place database access code into JSPs or Action classes: factor out this code into separate data access objects (DAOs). Configure data sources using the servlet container, not the (deprecated) struts-config.xml option. Name data sources after the username or schema used for the connection, not the target database instance.

Error Handling

  • Write error diagnostic and tracing information to the servlet context log, do not simply print a stack trace.  This may be done by extending struts.action.RequestProcessor.

  • Declare error pages in web.xml to handle unexpected server errors (500) and missing resources (404).  It may be convenient to comment these out in development environments.

  • Review Ambysoft’s Coding Standards for Java

  • At a minimum use an initial capital for classes and an initial lower case for variables. Use all caps only for constants, ie. where ‘static final’ is used.

  • Do not declare global variables: at a minimum use singleton beans. Global constants are OK.


Insourcing vs. outsourcing

Reasons to outsource:

  • The business is growing rapidly and leveraging an existing third party infrastructure is quicker/less risky than building/scaling one’s own. In this case it is worth paying a premium for the infrastructure, which is more than offset by the value to stakeholders of growing the business rapidly with less IT risk. The key aspect here is, speed to market.
  • A third party has knowledge, skills, or some other limited resource that the business wants to leverage, and paying a premium to a third party makes more sense than acquiring the resource using internal staff. The key aspect here is non-core specialization.
  • A third party is able to subdivide a pool of resources between multiple clients and thereby deliver a service more cheaply than individual clients could do so on their own. This is economy of scale, and provided some of these economies are shared with clients it will never make sense for the business to insource.
  • Even if the above aspects do not apply management may lack clear visibility or confidence in internal processes, and may choose to outsource an IT service using a negotiated contract to a separate organization for financial discipline and control.

Reasons to insource:

  • Outsourcing requires more formal agreements between organizations and ongoing efforts to ensure goals are mutually aligned. Hence, if there is no compelling reason to outsource then insourcing requires less management overhead.
  • An IT process may be intimately related to an innovative business process or product that is a source of competitive advantage. In this case stakeholders may want this knowledge kept in house, and in any case it may be of limited value to a third party to acquire this knowledge on the business’s behalf: this is core specialization.
  • Third parties may be unwilling or unable to indemnify the business against certain risks, for example theft of sensitive customer data. More generally insourcing may be considered the most practical response to certain legal concerns.

Insourcing/outsourcing should not be confused with asset ownership, and in particular intellectual property rights and licences. It may make sense to outsource certain processes, while seeking to own related assets.

SUSE LVM and Oracle Database

One of the reasons I like deploying Oracle Database on SLES is that SuSE Linux includes LVM by default. Having become accustomed to LVM implementations on HP-UX and AIX I was disappointed to discover it was not a standard feature of all Linux distros. An extensive LVM guide is available at the Linux Documentation Project. Jeff Hunter’s site has some notes and a copy of a good early white paper on SuSE LVM

To list all volume groups, physical volumes and logical volumes

vgs lvs pvs

To initialize a blank disk and make it an LVM physical volume (PV):

pvcreate /dev/sdx 

To display the details of a physical volume:

pvdisplay /dev/sdx

To create a volume group containing a physical volume:

vgcreate vg01 /dev/sdx

To add a physical volume to an existing VG:

vgextend vg01 /dev/sdy

To display the details of the volume group:


To create an LVM logical volume:

lvcreate --size 2050m --name lv_sls_idx_128m00 vg01

To move physical extents from one PV to another in a VG. Requires LVs not in use.

pvmove /dev/hdb /dev/sdf

The SuSE white paper also discusses (pp.20+) how to map an LV to a raw device suitable as an Oracle datafile. On a properly tuned host this should result in better performance. More importantly, in my opinion, it reduces the need to allocate, resize and monitor host filesystems for Oracle data. The simplest approach is to use raw. Given that mappings are not persistent it is best to script them in /etc/init.d/boot.local.

/usr/sbin/raw /dev/raw/raw128 /dev/vg01/lv_sls_idx_128m00
chown oracle:dba /dev/raw/raw128

Once the device is mapped it can be added to a tablespace like this:


More readable device names can be created like this:

rm -f /dev/raw/raw131
mknod /dev/raw/rlv_sls_dat_4m00.dbf c 162 131
raw /dev/raw/rlv_sls_dat_4m00.dbf /dev/vg01/lv_sls_dat_4m00
chown oracle:dba /dev/raw/rlv_*.dbf 

Tablespaces can then be created like this:



Moving data files securely from one environment to another is a frequent business application requirement, so I was disappointed to learn scp doesn’t support a ‘least privilege’ approach ‘out-of-the-box’. The authors of O’Reilly’s book give an incomplete solution and note various issues, but that’s about it. Other solutions involve jailing SSH, a custom SSH shell like rssh or switching to WebDAV or ftps and using certificates. I thought these were overkill so I came up with this alternative to scp-wrapper

# scp-restricted
# 1.0  Piers C  Oct-07  Original
# Inspired by
# Tested with OpenSSH 3.x server and Putty client
integer argc=0
typeset command="exec /usr/bin/scp"
typeset filename
readonly SCRIPTNAME=$(basename $0)

function fail {
  print "$SCRIPTNAME: $2" >&2
  print "$SCRIPTNAME: SSH original command should be 'scp [-v] [-t|-f] filename'" >&2
exit $1
if [[ "$1" == "-T" ]]; then # see test-scp-retricted
  command="print "${command}

if [[ -z $SSH_ORIGINAL_COMMAND ]]; then
  fail 1 "environment variable SSH_ORIGINAL_COMMAND not set"

for arg in $SSH_ORIGINAL_COMMAND; do

if (( $argc == 4 )); then
  if [[ ${argv[1]} != "-v" ]]; then
    fail 6 "arg 2 of 4 not '-v'"
  command=${command}" -v"
elif (( $argc != 3 )); then
  fail 2 "wrong number of args"

if [[ ${argv[0]} != "scp" ]]; then
  fail 3 "arg[0] must be 'scp'"

# be very conservative with filenames that we'll accept
if print ${filename} | egrep -vs '^[a-zA-Z0-9][.a-zA-Z0-9]*$'; then
  fail 5 "bad filename: $filename 
(must be alphanum, may include but not start with period)"

if [[ ${argv[1]} == "-t" ||  ${argv[2]} == "-t" ]]; then
  cd $HOME/inbound || fail 7 "unable to cd ~/inbound"
  ${command} -t ${filename}
elif [[ ${argv[1]} == "-f" || ${argv[2]} == "-f" ]]; then
  cd $HOME/outbound || fail 8 "unable to cd ~/outbound"
  ${command} -f ${filename}
 fail 4 "args must include -t or -f"
# test-scp-restricted
integer succeeded=0
integer failed=0

function dotest {
  print "======================================"
  print "=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=="
  ./scp-restricted -T; rc=$?
  print "=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=="
  if (( $rc == $2 )); then
    print 'exited ('$rc') - test **SUCCESS**'
    print 'exited ('$rc') - test **FAILED**'
dotest "" 1
dotest "x" 2
dotest "x y z" 3
dotest "scp -p z" 4
dotest 'scp -t foo.dat' 0
dotest 'scp -t 7' 0
dotest "scp -t .." 5
dotest "scp -t a;ls" 5
dotest 'scp -t a*ls' 5
dotest 'scp -t a/ls' 5
dotest 'scp -t a�73ls' 5
dotest 'scp -f bar.dat' 0
print "Succeeded: $succeeded"
print "Failed: $failed"


I’ve been interested in computers since my mathematics teacher introduced me to Forth running on 8-bit microprocessors around 1980.

I studied physics at Oxford, which involved a lot of applied mathematics, but relatively limited access to computers. I bought an early IBM PC clone and learned C using the Whitesmiths compiler.

My first job was maintaining a forex arbitrage calculator for a banking software consultancy using Lattice C. After less than a year I moved to another financial software house and wrote a eurobond trading system in Microsoft C, first on DOS, then on the new OS/2 operating system. Having learned OS/2 GUI programming I was hired by GE to work on applications using CUA, then I was contracted by IBM to work on OS/2 2.0 in Austin, Texas. After that I consulted on OS/2 related projects for several years using VisualAge C++ and IBM Open Class until IBM announced eventual abandonment of OS/2 after release 4.0.

Wanting a break from programming I learned Oracle Database, moved to California, and switched career to database and Unix administration. Within eighteen months, however, I was at a dot-com designing a B2B marketplace, using IBM Websphere Commerce and learning Java. The project bombed and I went back to database administration and implementing Oracle Financials, then directing systems development for a retailer, where I specialize in PL/SQL


Here are my experiences building an HTPC with MythTV.

Installation. You can start with a common Linux distro like Fedora or Ubuntu and install MythTV on top of the distro, or you can use a specialized distro like KnoppMyth. As of June ’06 I had trouble finding stable MythTV packages to install or figuring out all the dependencies needed to compile from source. I finally gave up and used KnoppMyth R5C7, which is easiest if you let it take over the machine and delete all other partitions on the boot drive, otherwise you have to know what you are doing with lilo.

Hardware. I have a couple of HDTV tuners: fortunately support for them had been added into the kernel during early ’06, but otherwise I would have been faced with applying kernel patches. Even so, it took me a while to figure out I needed the latest kernel. Decoding HDTV signals takes significant processing power: I have a 2.4GHz Celeron CPU and originally output stuttered badly. Fortunately I had an nVidia video card and selecting the XvMC option allowed the card to assist with MPEG-2 decoding and eliminate the stutter (in MythTV’s frontend menus, navigate to: Setup -> TV Settings -> Playback). To take advantage of the 16:9 aspect ratio of my Sharp Aquos display I had to manually customize my /etc/X11/XF86Config file. I’m not sure I did it right but it seems to work.

Noise. To record and play programs the HTPC has to be left switched on for extended periods of time. Even though I already had a Zalman CPU cooler the whine of the small northbridge cooler drove me to distraction: I had to special order a Zalman northbridge heatsink with an epoxy binding as the motherboard had no mounting holes for anything else. I was able to quieten my disk drive by using ‘hdparm -M128 /dev/hda’ to set its acoustic management feature.

Power. To get my HTPC to power off between recordings I had to figure out how to configure /etc/nvram-wakeup.conf for my motherboard. My motherboard (a FIC Dynasty) did not appear supported and I was unable to get it to work.

Posts navigation

1 2 3 9 10 11 12