OK then, let's see what happens:
I PROPOSE that the classes in commons logging be rearranged as follows:
no change:
org.apache.commons.logging.Log
org.apache.commons.logging.impl.Jdk14Loger.java
org.apache.commons.logging.impl.Log4JCategoryLog.java
org.apache.commons.logging.impl.LogKitLogger.java
org.apache.commons.logging.impl.NoOpLog.java
org.apache.commons.logging.impl.SimpleLog.java
rename package, and add JavaDoc to explain or confuse as appropriate:
org.apache.commons.logging.factory.LogFactory
org.apache.commons.logging.factory.LogSource (deprecate?)
org.apache.commons.logging.factory.impl.LogFactoryImpl
org.apache.commons.logging.factory.impl.LogConfigurationException
org.apache.commons.logging.factory.impl.Log4jFactoryImpl
Justification:
1. Provide a logging interface independent of (or
at least disassociated from) factory or other framework.
2. Make changes NOW before someone else invents yet another logging
interface to accomplish this "goal".
Cons:
1. Requires changes to user's code (minimal?).
Alternatives:
1. Leave as-is
2. use o.a.c.logFactory.* instead of o.a.c.l.factory, to further
distinguish/confuse.
<ras>
[Dang, where IS that ring when you need it!?!?!]
<ps>
If this exchange were by paper-mail, I'd be investing in more than one
logging enterprise...
</ps>
*******************************************
Richard A. Sitze [EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
"Geir Magnusson
Jr." To: Jakarta Commons Developers
List <[EMAIL PROTECTED]>
<geirm@optonline cc:
.net> Subject: Re: [logging] Need
interface...
04/04/2002 03:09
PM
Please respond
to "Jakarta
Commons
Developers List"
On 4/4/02 11:30 AM, "Richard Sitze" <[EMAIL PROTECTED]> wrote:
> I think we are circling around the same point.
Maybe.
>
> I don't see the value of the interface w/o framework as-per your comments
> below. You CANNOT use the interface for "totally generic code" without
> forcing a framework into the code also... SOMETHING has to attach an
> implementation to the logger, via pull (factory) or push (external
> dependencies) model. So, you are going to be subscribing to one or the
> other.
And SOMETHING has to be there anyway to use the
component/class/package/module that uses o.a.c.l, right? I just don't want
to be told exactly what has to be there...
>
> On the other hand, we could do a bit of disassociation here: move the
> factory and other elements of the "framework" into a separate package,
and
> introduce a new package for the push model:
>
> org.apache.commons.logging.pull
> org.apache.commons.logging.push
>
> (and no, I wouldn't vote for these for final names :-)
Nor would I.
I would hope though that in o.a.c.l lives the basic interfaces...
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Be a giant. Take giant steps. Do giant things...
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
