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 see."

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 Facelets.

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 component.

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.