UIowa Commons
Any development shop has a suite of libraries, tools and utilities they have built over the years, and ours is no different. In fact, we are working on our second library. Our first generation is called shared-uiowa which compiles into a single uiowa.jar file that is included in all of our projects. This jar file contains the functions listed below. We try not to re-implement common tools that are provided by other open source toolkits (log4j, jakarta-commons, etc...). But in some cases (logging, db pools) we have setup facades or extended open source tools to better fit our needs.
Our second version (uiowa-commons) is under development, and is intended to clean up our current library which is about 10 years old. We also want to build in even more management hooks so that all of our applications can be monitored and managed in a consistent way. Whenever practical, we will retire our own versions of tools and move towards open source libraries that provide similar functionality (like jakarta-commons).
Features and Functionality
- uiowa.cics - class for connecting to CICS via a custom home grown socket application, these classes mostly serve as wrappers to their CICS counterparts on the mainframe.
- uiowa.config - configuration (dev/test/prod) classes for dealing with configuration values in simple .properties files
- uiowa.errors - common exceptions and utilities for dealing with all type of application errors
- uiowa.ldap - very frequently used classes that pull back information on People from our campus LDAP directory.
- uiowa.payment - facade around the PayPal library for taking credit card payments, also provides routines which will charge values to a student's university bill.
- uiowa.pool - database pool classes - we have created management interfaces to our pools which allow us to monitor them at run time, track down performance problems, reset pools, etc...
- uiowa.uip - client struts actions that are used by all programs which hook into our authentication service.
- uiowa.util - catch all, SSN parsers, date parsers, email utilities, CSV parsing utilities, and of course our StringUtil class.
There are more packages which contain specific functions to interface with various systems that you wouldn't care much about (uiowa.mfk, uiowa.nams, etc...)
Challenges and Lessons Learned
I don't think we came across any unique challenges in developing this library. It has evolved over time and contains remnants of bad decisions made along the way (our own ORM package for example).
Otherwise, the typical issues have come up; what goes in uiowa.jar?, how do we make new developers aware of existing tools?, how do we make changes when 50 applications all use a particular class in a particular way?, how do we handle multiple versions of Java, etc...