A development team from an Oklahoma City-based company, International Environmental
Corporation (IEC), recently donated a JSF component
they had developed to the open source Mojarra (JSF Reference Implementation) Scales effort. Jason Lee, a Mojarra team member and a Senior Software Engineer, was part of the team that
developed the component.
IEC manufactures fan coil HVAC units. Lee said that the component was part
of an application the team developed for the Technical Data Management (TDM)
department. "When a unit configuration is ordered that we've never built
before, the order is sent to engineering where the drawings are made and a bill
of materials, or BOM, is produced. Once the BOM is available, our TDM department
needs to upload it to our manufacturing system. They do this using our BOM Upload
system, a web application that allows the user to upload one or more BOM files,
which are then analyzed for correctness. If the BOM is correct, the user can
finish the upload to the manufacturing system, or, in the event of an error,
the file can be fixed and reuploaded." (See Figure 1.)
Figure 1: This user has selected four bill of material files, and is able to review his selection before uploading.
The application is currently in production. The TDM department is fairly small,
so the user base is less than five. The development team, at its peak, had three developers.
It originally consisted of one developer, Brent Vaughn, working on the project
full time, along with the IT manager, Mitch Blevins, adding occasional assistance.
Lee became involved when it was time to tackle an issue with regard to file
uploads. He explained, "While the application itself is not too exciting,
what makes it interesting is the custom component we wrote to work around an
HTML limitation. When the TDM group uploads these BOMs, there can easily be
20-30 at a time that they need to upload. With the plain HTML file input widget,
the user can only select one file at a time. While there are some pretty slick
and clever ways to make that more palatable,
the requirement that the user click a button before selecting each file -- over
and over -- was quickly dismissed as unacceptable. To work around this, we looked
at projects like JUpload, but they did not work exactly
how we'd like, and setting it up on the page was more work than we wanted to
Given all of that, the team set out to encapsulate this behavior in a JSF
component that would allow a developer to drop a single line of markup on the page,
easily getting the functionality they needed. They chose an applet since they
needed to allow the user to be able to select multiple files at one time. Lee
said, "Ajax would allow us to upload the files in a pretty slick manner,
but the user would still have to select each file individually, which would
have killed the project once the users got wind of that." The team found
that after just a few days of development, the component, complete with Swing-based
GUI applet, could completely replace JUpload on the pages.
The team then decided to open-source the component, so they donated it to the
Mojarra Scales effort (formerly the JSF Reference Implementation Sandbox). Scales
shares the CDDL/GPLv2 license with Mojarra itself.
When asked what they used for support, Lee said, "We have a couple of
books that we tend to share quite a bit. Long one of our standards is David
Geary and Cay Horstmann's Core JavaServer Faces. While we still refer
to it, the release of Ed Burns' and Chris Schalk's JavaServer Faces: The
Complete Reference gave us a new standard reference. Since I am a developer
on the reference implementation, we've been able to leverage the relationships
with the other team members to get some really good help from the likes of Ryan
Lubke, Ed Burns, Roger Kitain, as well as many others."
All of the development was done on Windows boxes using JDK 5, Eclipse, and
Ant. The team used Subversion for source control and Hudson for continuous integration.
The workstations they used were Windows XP Professional, but they deployed
to Windows Server 2003 SP2 (dual P4 2.4GHz, 2GB ram) servers running the GlassFish
(v1 ur1 p01) application server. The Eclipse installs were pretty basic. They
used Eclipse 3.2+ with WST 1.5. Lee said that he hand coded his views, using
Eclipse as a giant text editor with syntax highlighting and code completion.
The team attached to the local GlassFish servers for debugging the applications, but
did not use any special plugins for that -- just the regular remote process
debugging from Eclipse proper.
All of the views were written using Facelets 1.1. They still have some older
JSP-based applications, but all new development and any major rework were done using
Lee gave some more details of the application. "Packaging the applet in
the component wasn't too terribly difficult. We had to make sure the build system
ignored the applet classes when packaging things. We would then package those
classes separately in their own jar, sign that and any dependent jar files,
and move them all to the location we had chosen in /META-INF/ in the component
libs' jar file. We could then reference these jars in the renderer, allowing
(in our case) Shale Remoting to create a URL that could be used by the browser
plugin to retrieve all the jars necessary to run the applet."
The team also developed a download component that allowed them to download
content of arbitrary type to the client, either embedding it in the web page
(useful for things like PDFs or dynamic images) or prompting the user to save
the file. The latter is how they used the component in this application, as the service/business
layer generates a Microsoft Excel spreadsheet showing any validation errors,
which is then returned to the user via the calling managed bean and this download
They also utilized Ajax4Jsf, specifically, the <a4j:poll> component
to give the user feedback on the progress of BOM validation.
The company currently has about 18 JSF applications deployed. When appropriate,
all of them make use of EJB3 session beans and use JPA for persistence. They
also use Acegi Security to restrict access to the applications.
Lee said that the Acegi integration was not too difficult from a JSF perspective.
"We had to write some custom Acegi classes to handle splitting our authentication/authorization
with users in Active Directory and roles in a JDBC source, but the actual resource
protection was done with either a URL regular expression to protect a whole
page, or Cagatay Civici's acegi-jsf components
to protect particular sections on a page."
The feedback from the Technical Data Management department has been mostly
positive. The users have reported that it meets all their needs. After several
months in production, the application has been so stable, that there have been
no reports of issues from the users.