commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: [commons-logging] New services API
Date Wed, 26 Jun 2002 00:06:42 GMT

On Tue, 25 Jun 2002 wrote:

> Date: Tue, 25 Jun 2002 18:21:20 -0500
> From:
> Reply-To: Jakarta Commons Developers List <>
> To: commons-dev <>
> Subject: RE: [commons-logging] New services API
> Any objection to checking the 'service' package in under logging and making
> changes to the logger as described?

I like the concept of abstracting out this logic (mabye we could call it
"discovery" to avoid name conflict with the "services" package already in
the sandbox?).  The design pattern is definitely useful and reusable.

I think making commons-logging depend on it would need a 1.1 release, with
release notes that prominently highlighted the new dependency.  And that
would need to wait for a 1.0 release of the discovery thingie.

You can put the code into the sandbox without a vote (I'll make sure you
have appropriate karma - every Jakarta committer gets that if they want
it).  You can add me as a maintainer on your status file.  To get into
commons proper, though, it'll need a formal vote.  I'd suggest doing the
grunt work in the sandbox first.


> *******************
> And so, in that light, may I offer the following for consideration and
> improvement by the community:
> [see attached file]
> (See attached file:
> 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]
> (See attached file:
> *******************************************
> Richard A. Sitze  
> CORBA Interoperability & WebServices
> IBM WebSphere Development

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message