The configuration framework is a very small framework which tries to insulate developers from environment configuration. With this layer, hopefully developers will not need to worry about where property files are deployed. They also won't have to special case their code if running inside or outside a J2EE container, or which J2EE container they are running in. This framework wraps that complexity.
The logging framework is a small framework which wraps different "logging mechanisms," so developers do not have to put special cases in their code to log to, for example, standard error (System.err) during development but a file and a paging mechanism for critical errors in production. This framework works in conjunction with the configuration framework to isolate the developers from logging environment changes. It also makes sure to put time stamps in each log entry, can log to multiple logging mechanisms at the same time, and more importantly, it logs each message at a criticality that can be handled according to the environment the code is running in. For example, for critical errors in a QA environment, we may want to email someone to take a look at these. But in production we want to page someone immediately to correct the situation.
The utility library contains miscellaneous methods, classes, and framework extensions that other JLF layers find reusable but have no better place to go. They aren't entire components or frameworks, so to be reused they go here. Examples are proper implementations of difficult hashing and cloning operations and a class instance variable ala Smalltalk.
The Vital Sign framework tries to help you collect information about how well things are running in your Java virtual machine and send out alerts if things are not running well, hopefully in time for you to correct the situation before your production application goes down. The framework comes out of the box with a few vital signs for monitoring things like virtual machine memory and BEA WebLogic threads and connection pools, but can be extended to monitor custom code. It hooks into the JDK 1.4+ logging framework so this framework currently requires the java.util.logging package.
The proprietary JLF logging framework, above, is being replaced by a standard logging framework embedded in JDK 1.4 and above. Unfortunately, it doesn't have many of the good things in the JLF logging framework (like a JSP interface to manipulate logging levels, a concise but meaningful output formatter, and the AppError and AppInstrument classes), nor does it use the Vital Sign framework above. This add-on package brings a lot of the good things from the proprietary JLF logging framework for use in the new standard framework, plus instruments errors and events in conjunction with the Vital Sign framework.
The Data Mapping Framework abstracts the Java code designer from the details of mapping the data in a Java class to a data source/sink. Each data source/sink has a data mapping property file that tells the mapping framework how to map data to and from that data source/sink. Currently, relational databases are supported via a JDBC data mapping mechanism, and output to XML sinks are supported via a Xerces XML Parser mapping mechanism. XML sources (parsing from an input XML Document) is not yet supported.
Here is a presentation on the Data Mapping Framework.
The HTTP Request Processing Framework sits on top of the Data Mapping Framework to map data from HTML input forms to Java objects. It then routes an HTML input form request through a workflow servlet to Java code you write to process the request. Once the request is processed in Java code, it forwards the request to an output page, which could be an external web page or an internal JSP or servlet, to display the results of the processing.