[commons, commons-logging, core-arch] New services API

[rs...@us.ibm.com]

One point, if not already made, regarding core-(re)architecture &
packaging:  please make a distinction between 'utility' classes in the
core, and 'services' such as logging.  Every 'service' must be packaged
separately.  I believe that the distinction is an offering of helpful
'function' versus 'service' described by a pluggable API.

And so, in that light, may I offer the following for consideration and
improvement by the community:

[see attached file services.zip]

(See attached file: services.zip)


So, what is going on here?  I wanted to remove the service locate/discovery
logic from the logger, as it seems generally useful in all to-many
different contexts.  The ServiceFinder.find(Class spi, Properties props,
String defaultImpl) is the main entry point, where spi is a Class that
represents the service (interface) for which an implementation is to be
found.  The class name of 'spi' is a property name, whose value (system
properties, props) is expected to be the name of a class that
implements/extends that class (hence we pass in the class, not a string).
JDK 1.3+ discovery is also used.  A default is passed in, as a last-effort
fall back.

I would welcome input from those who *KNOW* classLoader logic, particularly
in the context of J2EE, in loading resource files and classes.


I've adapted commons-logger to the services API, so that it's getFactory
methods now use the ServiceFinder.  I believe that I have preserved the
bootstrapping of LogFactory [even though I took some liberties with
implementation].

[see attached file logging.zip]

(See attached file: logging.zip)


<ras>

*******************************************
Richard A. Sitze            rsitze@us.ibm.com
CORBA Interoperability & WebServices
IBM WebSphere Development