On 4/5/02 5:59 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:
> 

>> 2) If Log and LogFactory interfaces were separated from the .impl that is in
>> commons now, into two separate packages,
>> 
>>     o.a.c.l -> commons-logging.jar (contains the interfaces)
>>     
>>     o.a.c.li -> commons-loggingimpl.jar (contains the impl)
>> 
>> then 
>> 
>> 
>>   b) Alternative LogFactory implementations are easy to deploy as it just
>> means dropping the lightweight interface jar into the classpath, and the
>> alternative factory impl jar.
> 
> It doesn't matter where the LogFactory sits - if we define the helper
> ( org.apache.foo.LogFactory ) and it uses a static method it can't be
> reimplemented.

I see now - because the discovery functionality (the static method) and the
interface you are trying to discover (LogFactory) are combined, via
o.a.c.LogFactory being an abstract class with the static method, rather than
an interface, we're screwed if you want to replace LogFactory.

Is that it?  That's why I would have to remove o.a.c.LogFactory from the jar
and replace with my own?

So the LogFactory itself isn't really generic, as it presumes the helper?
And everyone who writes to this does

 import o.a.c.l.LogFactory;

 ...

  Log logger = LogFactory.getLogger();


Ok - so there's no point in continuing.  It seems like the only way to offer
a generic set of interfaces for logging is to do a different package...

Otherwise, the the basic interfaces (Log, LogFactory) can't be implemented
freely?

Hm....

-- 
Geir Magnusson Jr.                       [EMAIL PROTECTED]
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to