commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rsi...@us.ibm.com
Subject RE: [commons-logging] New services API
Date Tue, 25 Jun 2002 23:21:20 GMT
Any objection to checking the 'service' package in under logging and making
changes to the logger as described?

*******************

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 extract 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)

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