For more details, see the using document/
Chainable exceptions are implemented by using a helper class to contain the logic behind the standard exception methods. This allows for creating a new exception or extending one with the chainable property fairly easy.
Service Provider Interface Loading
The SPI framework is used by applications to, at run-time, discover implementation classes of a service. These implementation classes implement a service class or interface, and are dynamically loaded and instantiated to fulfill a role that the application requires.
The SPILoader class knows how to parse a class loader for references to files under META-INF/services/classname. Multiple of these files may be defined per JAR file or directory in the classpath, so the SPILoader iterates through all references of this file.
Each service file is a text file describing the class names that provide an implementation of the service class. Each service class must be on its own line (whitespace is ignored), and must be declared with the fully-qualified class name that implements the service. Empty lines and lines beginning with a hash mark ("#") are ignored.
The Throwable Parsing classes are a wrapper around the stack trace listing methods introduced to the java.lang.Throwable class in JDK 1.4. The GroboUtil classes will either use the JDK 1.4 methods (if running in JDK 1.4), or revert to parsing the output from printStackTrace().
Class Load Helper
The Class Load Helper class is a collection of utilities that contain logic to aid the developer in writing dynamic class loading code. There exist many neuances behind the particulars for this, especially when dealing with different JDK versions, and this class attempts to isolate the developer from many of these headaches.
There comes a time when applications need the use of a singleton. The problem with static access to a singleton (or worse - a class with static methods) is that it can be difficult to extend the functionality of said singletons, or to swap them out with different ones. Such a situation may be where one process discovers an optimization that could be used, and so the singleton could be swapped out with another to allow for faster run times. Another situation may be where old software references a utility, but new or different functionality may be required by add-on software; in order for the old software to gain this new functionality (say, additional logging), the original singleton will need to be swapped with the new one.
In order to support this kind of behavior, the Singleton Stores classes were created.
This space graciously provided by the SourceForge project
2002-2004 GroboUtils Project.|
All rights reserved.